C(++) vraagje

Op vrijdag 26 april 2024 11:41:23 schreef SparkyGSX:
[...]Dat ben ik helemaal met je eens, daar heb ik ook een bloedhekel aan, zeker als het ingewikkelde code is met meerdere dergelijke variabelen.

Sommigen maakten het nog bonter.
Omdat de keuze met 26 letters beperkt is, gebruikten ze ook nog case sensitivity om het aantal te vergroten.

Zo hadden ze verschillende variabelen 'a', 'A' ... 'z', 'Z'... :+

die 80 chars regel lengte was ook leuk voor een 4:3 monitor.
Die regel had ik bij een eerder project ook, Ja dat was handig voor als ze op 1 monitor in bitbucket een side by side comparison wilden doen.
Pff als je dan een functie met wat argumenten over 3 regels moet verdelen, dat was pas lelijk.
(vond ik dan ;) )

Op vrijdag 26 april 2024 13:03:49 schreef Arco:
Dialogic sloeg in hun source weer te ver door met naamgeving, ook ergerlijk... (probeer dat maar eens te onthouden :( )
Constante namen:


%IPEC_Q931Cause42SwitchingEquipmentCongestion                                   = 3042  '0xbe2
%IPEC_Q931Cause43AccessInformationDiscarded                                     = 3043  '0xbe3
%IPEC_Q931Cause44RequestedCircuitChannelNotAvailable                            = 3044  '0xbe4
%IPEC_Q931Cause47ResourceUnavailableUnspecified                                 = 3047  '0xbe7
%IPEC_Q931Cause57BearerCapabilityNotAuthorized                                  = 3057  '0xbf1
%IPEC_Q931Cause58BearerCapabilityNotPresentlyAvailable                          = 3058  '0xbf2
%IPEC_Q931Cause63ServiceOrOptionNotAvailableUnspecified                         = 3063  '0xbf7
%IPEC_Q931Cause65BearerCapabilityNotImplemented                                 = 3065  '0xbf9
%IPEC_Q931Cause66ChannelTypeNotImplemented                                      = 3066  '0xbfa
%IPEC_Q931Cause69RequestedFacilityNotImplemented                                = 3069  '0xbfd
%IPEC_Q931Cause70OnlyRestrictedDigitalInformationBearerCapabilityIsAvailable    = 3070  '0xbfe
%IPEC_Q931Cause79ServiceOrOptionNotImplementedUnspecified                       = 3079  '0xc07
%IPEC_Q931Cause81InvalidCallReferenceValue                                      = 3081  '0xc09
%IPEC_Q931Cause82IdentifiedChannelDoesNotExist                                  = 3082  '0xc0a
%IPEC_Q931Cause83AsuspendedCallExistsButThisCallIdentityDoesNot                 = 3083  '0xcob
%IPEC_Q931Cause84CallIdentityInUse                                              = 3084  '0xc0c
%IPEC_Q931Cause85NoCallSuspended                                                = 3085  '0xc0d
%IPEC_Q931Cause86CallHavingTheRequestedCallIdentityHasBeenCleared               = 3086  '0xc0e
%IPEC_Q931Cause88IncompatibleDestination                                        = 3088  '0xc10

Dat heb ik ook wel eens gedaan. En daar waren toen goede argumenten voor. Je hoeft ze niet te onthouden met een IDE, want dan kies je ze uit een lijst.

En met deze notatie kun je wel gaan zoeken in je multi-million-line codebase als je 'error 47' uit het veld terugkrijgt.

Op vrijdag 26 april 2024 14:45:42 schreef deKees:
[...]
En met deze notatie kun je wel gaan zoeken in je multi-million-line codebase als je 'error 47' uit het veld terugkrijgt.

grep Cause47

Op vrijdag 26 april 2024 08:30:41 schreef PE9SMS:
[...]Een beetje IDE helpt daarbij toch? Matig argument heden ten dage.

Dat helpt alleen tegen typefouten. Niet bij variabelen die op elkaar lijken. En dat komt maar al te vaak voor igv copy/paste operaties waarbij er eentje vergeten wordt om aan te passen.

Op vrijdag 26 april 2024 15:01:18 schreef henri62:
[...] grep Cause47

En dan krijg je een lijst met 10 verschillende definities waar "Cause47" in voorkomt. Dan kun je vervolgens verder zoeken op %IPEC_Q931Cause47ResourceUnavailableUnspecified
en dan weet je meteen dat er een resource probleem is gedetecteerd en welke tekst aan die code gekoppeld is aan de logfiles.

2- of meercijferige error codes zijn zo 1980. Zeg gewoon in begrijpelijk Engels wat er aan de hand is.

Dan hoef je ook dat manual niet op te zoeken wat je waarschijnlijk de eerste week al kwijt was.

Plek-zat tegenwoordig voor tekst strings.

[Bericht gewijzigd door bprosman op (25%)]

Het maakt de code niet overzichtelijker als een variabelenaam meer als een halve regel beslaat... :)

Dan liever de cryptische µP registernamen in assembly waarvan men in een oogopslag niet ziet of niet meer weet welke variabele er mee bedoeld wordt of eraan is toegekend en men in de asm code moet gaan terugzoeken waar deze nu ook al weer voor diende. ;)

Dat zijn geen assemblynamen, maar de namen die de MCU fabrikant eraan heeft gegeven... (en dus in assembly meestal 'as is' overgenomen)

Bij pic's zijn de meeste registernamen trouwens kristalhelder, hoor...
(bijv. BORCON = brown out reset configuration)

Je kunt in assembly trouwens met '#define' een tabel met 'user-friendly' namen aanmaken als de registernamen je niet bevallen... ;)

Ik zie dat probleem niet echt, je hebt toch de datasheet nodig om te weten wat elk bitje doet. Daarbij is dat alleen in de onderste laag code, waar de hardware wordt ingesteld, voor elk project doe je dat meestal maar één keer.

Maar terug naar de oorspronkelijke vraag: je ontkomt er niet aan om de specifieke taal te leren, welke dat ook is. Ik zie nogal eens dat beginners het verschil tussen de bitwise en logic operators niet snappen, en ook bij meer ervaren programmeurs dat de volgorde van bewerkingen niet altijd logisch lijkt. Er is niets mis met een cheat-sheet, en bij onduidelijkheid een paar haakjes die mogelijk overbodig zijn vind ik ook geen probleem.

[Bericht gewijzigd door SparkyGSX op (49%)]

Ik kan daar een heel topic over vullen, maar dat heeft iemand anders al gedaan, zie: https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong…

Alleen een aantal zaken die de compiler ons opdraagt zijn verplicht te volgen. Anders gaat het niets worden. Al de rest is window dressing.

Misschien kunnen IDE's/compilers ook eens "foo" en "bar" bannen. Gewoon een instant blue-screen-of death als je dat nog intypt en vervolgens compile kiest. Wie daar ooit mee is begonnen mogen ze ook opknopen. Tutorials met dat.... AAARGH. Joel maakt die grove fout zelf ook.

Toen ik voor het eerst iets "computer-achtigs" aan een complete newby moest uitleggen was ik al redelijk gevorderd.

Het heeft me een paar jaar gekost om het denken van die persoon te snappen toen ik zei geef het bestand een naam en hij "piet" riep...

Op zaterdag 27 april 2024 05:59:28 schreef blanka:

Misschien kunnen IDE's/compilers ook eens "foo" en "bar" bannen. Gewoon een instant blue-screen-of death als je dat nog intypt en vervolgens compile kiest. Wie daar ooit mee is begonnen mogen ze ook opknopen. Tutorials met dat.... AAARGH. Joel maakt die grove fout zelf ook.

Wat moet je dan gebruiken als voorbeeld? aap en noot, knut en helga, henk en ingrid? Maakt toch geen moer uit.

Dat blijft een elleloze en compleet zinloze discussie die niemand ooit gaat winnen (style en coding-guidelines). Hele documenten zijn erover gemaakt bij veel bedrijven, meer als unit test code, wat veel belangrijker is, dat is gewoon triest.

Ik vind de 'funky' syntax in programmeertalen wel leuk. Niet altijd leesbaarder dat begrijp ik.



#bash:
echo "$((++i)) : ${filename%.*%.old}"    
#een tellertje en extensie wordt vervangen door .old

#python:
for i in range(4,20,2): 
 print(i)
#tel van 4 tot 20 in stappen van 2

#php

foreach ($linesArray as $line)
#lus voor heel de array
print "i is nul" if ($i==0); 
#geen then of haakjes en omgekeerde volgorde.

#perl
/(\+31|0)[\d\s-]{8,}\d/ && print "Telefoonnr $%\n"
Zoek naar telefoonnummer in STDIN

Voor de liefhebber :+

https://www.ioccc.org/

Op zaterdag 27 april 2024 19:34:32 schreef K7Jz:


#python:
for i in range(4,20,2): 
 print(i)
#tel van 4 tot 20 in stappen van 2

Die python range functie is wel grappig: FORTRAN heeft precies dezelfde constructie in het DO statement:

https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn8c/index.html

Al het oude (FORTRAN is uit de jaren 60 vorige eeuw) komt gewoon weer terug :-)

Op zondag 28 april 2024 10:17:19 schreef blurp:
[...]

Die python range functie is wel grappig: FORTRAN heeft precies dezelfde constructie in het DO statement:

https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn8c/index.html

Al het oude (FORTRAN is uit de jaren 60 vorige eeuw) komt gewoon weer terug :-)

Ja het zijn immers ook veel voorkomende handelingen voor bijna elke ontwikkelaar. Net als de array_sort array_filter array_walk reeks in PHP. Zeker een dozijn handige functies die ook nog beter leesbaar zijn dan 

myArray[]=10;

Deze varianten op range zijn er ook nog


#python
print(list(range(30)))

#bash
for i in {1..30..3};do echo $i;done

Niet alleen leuk maar ook handig. In een moderne ontwikkelomgeving zou het opzoeken van de betekenis geen minuut hoeven duren en zelfs via Google vind je het in 10 seconden

Of in plain C:


int i;
for (i = 0; i < 30; i += 2)
    printf("i is: %i\n",i);

Je mag van een latere gebruiker van je code wel verwachten dat zij het idioom van die taal voor zulke basisoperaties (her-)kennen.

De onderstaande "for-in-do" range constructie kende Pascal vroeger al.
Niets nieuws.


Type  
  TWeekDay = (monday, tuesday, wednesday, thursday,  
              friday,saturday,sunday);  
 
Var  
  Week : set of TWeekDay  
       = [monday, tuesday, wednesday, thursday, friday];  
  d : TWeekday;  
 
begin  
  for d in Week do  
    writeln(d);  
end.

Helaas geen Pascal UBB code-tag attribuut...

Op vrijdag 26 april 2024 10:05:54 schreef henri62:
Dit is een relic van een paar ontwikkelaars die het echt niet begrepen hebben wat nu de "Hungarian-Notation" / "App Hungarian" precies was.

Dat denk ik niet. Ik denk dat het stamt uit de tijd dat Fortran populair was. Ja KAN in fortran een integer declareren, maar als de variabele naam met een I, J of K begint hoeft dat NIET.

In die tijd kostte het serieus "moeite" om een extra regel "INTEGER I, J, K" toe te voegen. Ponskaarten maken, iedere keer als je wil compileren weer een extra kaart door de lezer duwen etc. Maar tegenwoordig is die extra regel "gratis" en toch verplicht geworden.

Op zaterdag 27 april 2024 17:20:32 schreef henri62:
[...] Wat moet je dan gebruiken als voorbeeld? aap en noot, knut en helga, henk en ingrid? Maakt toch geen moer uit.

Dat blijft een elleloze en compleet zinloze discussie die niemand ooit gaat winnen (style en coding-guidelines). Hele documenten zijn erover gemaakt bij veel bedrijven, meer als unit test code, wat veel belangrijker is, dat is gewoon triest.

Knut en Helga zijn grappig... Ik had op de TU een vriend die vaak kh gebruikte, betekende voluit geschreven wel wat anders maar moest ik aan denken bij deze discussie.

Op zondag 28 april 2024 18:45:41 schreef rew:
[...]Dat denk ik niet. Ik denk dat het stamt uit de tijd dat Fortran populair was. Ja KAN in fortran een integer declareren, maar als de variabele naam met een I, J of K begint hoeft dat NIET.

En de L,M of N. In Fortran is het default IMPLICIT INTEGER van I tot N. Als je dat niet wilt IMPLICIT INTEGER NONE of IMPLICIT INTEGER (A-C) gebruiken. Daarom wordt er zo vaak i gebruikt voor een variabele.

Sorry vergeten er bij te zetten. Ik weet nog uit m'n hoofd dat het een letter reeks was en dat de i er in zat, waarschijnlijk als eerste. Maar wat de laatste letter in die range was dat wist ik niet meer uit m'n hoofd.

Er zijn een hoop dingen die je tegenwoordig kan beheersen als je weet hoe het ongeveer werkt en de details kan opzoeken als je het nodig hebt.

Op de TU vond de prof "microprocessors" dat we de HPIB bus timing uit ons kop moesten leren voor het tentamen. Ik vond dat onzin. Ik heb een 6 gehaald voor het tentamen omdat ik 40% van de vragen niet kon beantwoorden.

Op dezelfde manier heb ik "Bridge arbitrage" gedaan. "Nee ik geef je op een briefje dat je zonder de cursus het examen niet haalt". Maar ik mag dus wel examen doen zonder cursus. Mooi. Doen we dat en dan zien we wel weer verder. Ik had het een-na-hoogste cijfer van mijn lichting. De beste van die examenronde is 8 dagen geleden overleden. :-( Goede gast.

Op maandag 29 april 2024 10:25:16 schreef rew:
Sorry vergeten er bij te zetten. Ik weet nog uit m'n hoofd dat het een letter reeks was en dat de i er in zat, waarschijnlijk als eerste. Maar wat de laatste letter in die range was dat wist ik niet meer uit m'n hoofd.

I tot N, de eerste twee letters van INteger :)