Wat doet deze coderegel?

Op zondag 6 oktober 2024 22:29:21 schreef ohm pi:
In C mag je gewoon 'if A=B' doen. Meestal (altijd?) is dat niet de bedoeling, want bij afwikkelen van deze stelling heeft 'A' de waarde 'B' gekregen en dan is de stelling altijd waar.

Het resultaat van die expressie is de waarde van B, dus die is waar als B ongelijk was aan 0.

Op zaterdag 5 oktober 2024 19:17:45 schreef Arco:
[...]
Ik programmeer (bijna) nooit in C, maar ik moet wel regelmatig hele lappen code omzetten in Basic, da's frustrerend als je steeds alles uit moet vlooien.
[...]

Het lijkt me zeker frustrerend om (ik neem aan werkende) C code om te moeten (van wie?) zetten naar basic. 8)7 Die tijd kun je toch beter besteden aan het leren (en accepteren?) van de ins en outs van C zou ik denken.

dat was ook mijn gedachte, maar ach ieder zijn smaak en doe lekker waar je je goed bij voelt. Dit is weer zo'n eindeloze discussie over wat goed en mooi en lelijk is.
Uiteindelijk boeit het allemaal niet zoveel.
Ik vind altijd het belangrijkste als je in team verband werkt, doe het dan graag allemaal hetzelfde zodat je elkaars code in ieder geval begrijpt en kan onderhouden. OF manier 1 daarin duidelijker is dan manier 2, dat is aan het team. 9 van 10x is het ook maar omdat mensen het zich eenmaal zo hebben aangeleerd of gewend zijn.
Sommige dingen zijn fundamenteel risico vol of foutgevoelig, daar heb je vaak een punt. Maar verder.
Ook de IDE's en compilers zijn toch ook echt wel met hun tijd meegegaan, dus
regeltjes als type indicatie in variabelen en fratsen als waarde en variabele omdraaien in if condities, omdat je dan voorkomt dat je per ongelukt = ipv == hebt getypt zonder een foutmelding. Leuk, maar schrijf gewoon fatsoenlijke code en fatsoenlijke tooling haalt deze fouten er zo voor je uit.

Op maandag 7 oktober 2024 10:30:46 schreef PE9SMS:
[...]Het lijkt me zeker frustrerend om (ik neem aan werkende) C code om te moeten (van wie?) zetten naar basic. 8)7 Die tijd kun je toch beter besteden aan het leren (en accepteren?) van de ins en outs van C zou ik denken.

Ik dacht dat ie de hele dag aan het debuggen was bij het omzetten tussen verschillende basic dialecten.

Op zondag 6 oktober 2024 22:29:21 schreef ohm pi:
In C mag je gewoon 'if A=B' doen. Meestal (altijd?) is dat niet de bedoeling, want bij afwikkelen van deze stelling heeft 'A' de waarde 'B' gekregen en dan is de stelling altijd waar. De meeste (alle?) compilers geven je een waarschuwing in de trant van 'Wil je dat echt?'.

if (a=b) is een goed voorbeeld van C code die legaal, maar eigenlijk nooit gepast is. Gelukkig waarschuwt iedere fatsoenlijke compiler ervoor.

Het is als in een clownspak naar een begrafenis gaan. Wettelijk gewoon toegestaan, maar ik zou niet weten wanneer dat gepast is.

Op vrijdag 4 oktober 2024 22:31:19 schreef SparkyGSX:
Ook dat ben ik van mening dat het juist duidelijker wordt; in alle gevallen gaat het resultaat naar str. Als je het als een if-else gaat schrijven moet je gaan vergelijken of de variabele waar naar geschreven wordt hetzelfde is. Met een korte naam als "str" gaat natuurlijk wel, maar die naam is voor mij juist fout omdat hij het doel niet beschrijft.

Neem deze regel:

HostData[ DeviceIndex ].Axes[ AXIS_X ].Increment = Actual > Target ? 1 : -1;

Of deze:

if( Actual > Target )
    HostData[ DeviceIndex ].Axes[ AXIS_X ].Increment = 1;
else
    HostData[ DeviceIndex ].Axes[ AXIS_Y ].Increment = -1;

Dan vind ik de eerste optie duidelijker.

of je gebruikt een "hulp" variabele, met een goeie compiler maakt ie daar hetzelfde van

int direction;
if( Actual > Target )
    direction = 1;
else
    direction = -1;
HostData[ DeviceIndex ].Axes[ AXIS_Y ].Increment = direction;

Op maandag 7 oktober 2024 08:58:17 schreef SparkyGSX:
[...]Het resultaat van die expressie is de waarde van B, dus die is waar als B ongelijk was aan 0.

C, het blijft altijd lastig!

Op maandag 7 oktober 2024 13:44:47 schreef blurp:
[...]

if (a=b) is een goed voorbeeld van C code die legaal, maar eigenlijk nooit gepast is. Gelukkig waarschuwt iedere fatsoenlijke compiler ervoor.

Het is als in een clownspak naar een begrafenis gaan. Wettelijk gewoon toegestaan, maar ik zou niet weten wanneer dat gepast is.

Op de begrafenis van een clown natuurlijk. Er is altijd wel ergens een edge case te bedenken... Maar onder de streep komt het er nog steeds op neer wat ik schreef en wat ik ook in jouw antwoord terugzie. Het is de verantwoordelijkheid van de programmeur, en ik vind het lief van de compiler dat er warnings inzitten.

nou, ik heb best ooit code die zoiets doet:

int sensor;
while(sensor = ReadSensor())
{
    //vanalles waar de waarde van sensor in gebruikt wordt
}

Dat is inderdaad een mooi voorbeeld waar het wel gepast is; je kunt het buiten de conditie van de while halen, maar dan moet je het één keer doen voor de while, en één keer aan het eind van de loop, en die code duplicatie is lelijk en gevaarlijk, want als je ooit een wijziging doet en vergeet dat je die ook moet dupliceren heb je de poppen aan het dansen.

Op alle andere plaatsen (zoals in een if statement) doe ik het nooit; het is dan de laatste regel voor de if statement, zodat de assignment direct in het zicht staat, maar wel op een aparte regel zodat er geen verwarring over kan bestaan.

@roadrunner84: als je per regel betaald wordt, zou ik inderdaad ook 6 regels schrijven terwijl het in één regel kan ;)

Er is zeker iets voor te zeggen om het zo uit te schrijven, maar ik houd er ook wel van om code een beetje bondig te houden, en ik vind die ene regel niet zo onduidelijk dat het opweegt tegen functies die veel langer worden. De standaard vuistregel is dat een functie maximaal ongeveer 10 regels lang zou moeten zijn, en daar zit je al bijna aan. Het vind dat een functie sowieso in zijn geheel op een normaal scherm moet passen, om het te kunnen overzien zonder te scrollen.

In beide voorbeelden zat trouwens opzettelijk een fout, om te laten zien hoe gemakkelijk je daar overheen leest; met jouw variant is dat probleem ook opgelost.

[Bericht gewijzigd door SparkyGSX op (39%)]

Op zondag 6 oktober 2024 23:20:43 schreef deKees:
[...]

?? Noem er dan eens een paar? Ik ken alleen Basic. (En Pascal, maar die heeft een andere assignment operator)

De == notatie zie ik juist wel overal terug, net als de +=, *= enz:
C, C++, Java, Python, php, javascript, perl, ruby, c#, rust, kotlin, typescript, go, shell

Meerdere hiervan zijn gewoon C adepten. Enkele voorbeelden van de "=" als vergelijking en niet als toewijzing uit bekende software:

  • Excel IF (A1=”Yes”,...
  • Mathcad (waar Matlab dan weer wel als C is)
  • Pascal, Delphi
  • Visual basic

waarbij dan bij verschillende programma's voor toewijzing ":=" gebruikt wordt. Het voordeel is dat je je niet snel vergist. If a:=B geeft een compileerfout, je kunt alleen maar vergelijken en dat is maar goed ook.

Op dinsdag 8 oktober 2024 16:08:39 schreef SparkyGSX:
Het vind dat een functie sowieso in zijn geheel op een normaal scherm moet passen, om het te kunnen overzien zonder te scrollen.

Eens! (Wie is "het"?? :-) ). De uitzondering is de functie waar een grote berg met cases met ieder 1-3 regels code wordt uitgeschreven. 


switch (cmd) {
  case CMD_THIS: do_this ();break;
  case CMD_THAT: 
     somevariable++;
     need_to_do_that=1;
     break;
...
}

Dit kan niet echt veel korter zonder onleesbaar te worden. En de heel korte dingen in een functie gaan doen is contra-productief: daar wordt het niet leesbaarder van: Dan moet je scrollen om de definitie van "do_that ()" te gaan zoeken en dan is dat deze twee regels. Dat maakt het dus niet leesbaarder.

Mee eens, juist om het overzicht over het geheel te behouden moet een functie bondig zijn. Als je iets doet dat niet direct duidelijk is, zijn 1 of 2 regels commentaar en 1 regel code nog altijd beter dan 6 regels code.

Ik is het, een foutje op de telefoon die ik niet op tijd gezien heb.

@maartenbakker: daar ben ik het absoluut mee eens. In mijn beleving moet het commentaar vooral uitleggen waarom iets gedaan wordt, niet wat er gedaan wordt, want dat is meestal wel duidelijk uit de code. Als dat niet direct duidelijk is, is het nooit verkeerd om dat er ook bij te zetten, natuurlijk.

Ik heb echt een bloedhekel aan zinloos commentaar, zoals dit:

Var++; // hoog Var op met 1

@rew: Soms is het inderdaad niet anders, maar dat is wel wat ik als vuistregel wil aanhouden; ergens tussen 5-6 regels en 40-60 regels. Een functie van 2 regels kan wel, mits dit op meerdere plaatsen gebruikt wordt, of code voor specifieke hardware bevat of zo, waardoor het in een andere file thuishoort.

Eind jaren 70 ben ik begonnen met microprocessoren in PLM te programmeren. Voor de meesten denk ik een onbekende taal ooit door Intel (denk ik) bedacht om hun 8080/8085 processoren te kunnen programmeren. De taal was simpel, had relatief weinig mogelijkheden maar was wel heel erg goed leesbaar. Stringverwerking ontbrak bijv. maar was ook in die wereld nauwelijks van toepassing.
Je kunt het zien als een vereenvoudigde versie van C.
De compiler is foutloos voor zover ik nu nog kan nagaan. Ik gebruik PLM nog steeds; tegenwoordig om 8051 derivaten aan het werk te zetten.

Ik heb nooit iets gehad met die compacte C-statements waar je steeds bedacht moest zijn dat je niet ergens een lettertje gemist had. Zeker toen je programmeurs kreeg die er een "sport" van maakten om zo weinig mogelijk toetsen aan te raken en daarom spaties weglieten als ze niet per se moesten. Onleesbare en foutgevoelige code leverde dat op.

Op dinsdag 8 oktober 2024 18:45:09 schreef SparkyGSX:
Een functie van 2 regels kan wel, mits dit op meerdere plaatsen gebruikt wordt, of code voor specifieke hardware bevat of zo, waardoor het in een andere file thuishoort.

Jazeker! Ik heb geen bezwaar tegen 2-regelige functies, maar als je je functie van zeg 100 regels met zo'n grote case in het midden gaat terugbrengen tot 40 door allemaal 2 en 3-regelige functies te maken ben je ook verkeerd bezig.

Op dinsdag 8 oktober 2024 19:03:37 schreef Leo-Bolier:
Eind jaren 70 ben ik begonnen met microprocessoren in PLM te programmeren. Voor de meesten denk ik een onbekende taal ooit door Intel (denk ik) bedacht om hun 8080/8085 processoren te kunnen programmeren. De taal was simpel, had relatief weinig mogelijkheden maar was wel heel erg goed leesbaar. Stringverwerking ontbrak bijv. maar was ook in die wereld nauwelijks van toepassing.
Je kunt het zien als een vereenvoudigde versie van C.
De compiler is foutloos voor zover ik nu nog kan nagaan. Ik gebruik PLM nog steeds; tegenwoordig om 8051 derivaten aan het werk te zetten.

Idem hier: bij Philips veel code voor een 8051-achtige met SDLC (Bitbus RS485 netwerk met operating system op netwerk niveau, 30 nodes, real-time je variabelen uitlezen - debuggen via het netwerk etc, multitasking, remote taken te starten op systemen) gemaakt en onderhouden. O.a. voor snelle servosystemen voor pick & place machines.

Ik vind het echter wat meer op pascal lijken qua structuur. C is wat sterker stack georiënteerd, waarbij PLM handig met registers werkt. Ik vond PLM erg handig, ik kon er grote programma's mee maken en toch overzicht houden. Het leende zich daar goed voor.

Een collega deed een wedstrijd tussen PLM en C (ik denk dat het Keil was maar wel lang geleden): PLM won.

Ik heb nooit iets gehad met die compacte C-statements waar je steeds bedacht moest zijn dat je niet ergens een lettertje gemist had. Zeker toen je programmeurs kreeg die er een "sport" van maakten om zo weinig mogelijk toetsen aan te raken en daarom spaties weglieten als ze niet per se moesten. Onleesbare en foutgevoelige code leverde dat op.

En idem hier. Minder sourcecode betekent niet minder hexcode.

Belangrijk aan software is leesbaarheid en overdraagbaarheid. Het hoeft niet knap te zijn, liever duidelijk.

Op woensdag 9 oktober 2024 00:19:02 schreef Hoeben:
[...]

Idem hier: bij Philips veel code voor een 8051-achtige met SDLC (Bitbus RS485 netwerk met operating system op netwerk niveau, 30 nodes, real-time je variabelen uitlezen - debuggen via het netwerk etc, multitasking, remote taken te starten op systemen) gemaakt en onderhouden. O.a. voor snelle servosystemen voor pick & place machines.
jd tussen PLM en C (ik denk dat het Keil was maar wel lang geleden): PLM won.

[...]

En idem hier. Minder sourcecode betekent niet minder hexcode.

Belangrijk aan software is leesbaarheid en overdraagbaarheid. Het hoeft niet knap te zijn, liever duidelijk.

Zo is het maar net. Ik was werkzaam in de gas- en olie-industrie. Wij maakten de eerste microprocessor gestuurde compressor- en gasstation besturingen die niet op oude analoge en relaistechnieken gebaseerd waren. Een hele stap voor de gas en olieboeren die als de dood waren dat er iets ging knallen.

Duidelijk geschreven programma's met veel commentaar/uitleg was het credo. Mijn opvolger moest er mee aan de gang kunnen gaan.

Ik gebruik de PLM compiler/assembler/linker/locater nog steeds. Er zat bij mijn weten 1 misser in de compiler: 1 x per jaar of zo weigerde hij om een source file te compileren. Bleef hangen zonder een object of zelfs listfile te genereren. Zonder aanwijsbare reden. Na lang proberen (pak de vorige versie en breng de modificaties stapsgewijs aan) bleek uiteindelijk de remedie om ergens een dummy variabele toe te voegen. Toen ik dat gevonden had was de support van Intel allang geleden gestopt dus klagen had geen zin meer.

Nu bezig met een klein systeempje dat de P1 poort van mijn slimme meter uitleest en op basis daarvan een signaal uitstuurt dat er teruggeleverd of verbruikt wordt en ten tweede een signaal dat er bijvoorbeeld een elektrische boiler aangezet mag worden zonder dat er een zekering uit gaat.