Wat doet deze coderegel?

Dan zou ik eerst Y-1 oftewel 10-1 moeten doen.
Ook dan is het wederom mijn opvoeding die stelt dat vermenigvuldigen vóór aftrekken komt,

Wat zijn de voorrangsregels die ik moet hanteren, rechts van het = teken?

In C zij de voorrang regels zoals je die kent hetzelfde, maar dan moet je de regels van C wel eerst goed toepassen.

x *= z moet je zien als
x = x * z
of in woorden
vermenigvuldig x met alles na het = teken en zet dat terug in x

stel dat
z = y - 1 en
x *= z

Als je dan eerste de onderste regel uitwerkt tot
x = x * z

en dan z = y -1 daarin invult krijg je
x = x * (y - 1)

Ik heb met mijn simpele geest het idee dat wat aan de ene kant van het "=" teken staat, gelijk moet zijn aan wat er aan de andere kant staat.

OOk dat is niet verandert. Enkel staat daar niet alleen een = teken maar een *= teken en dat beteken net even iets anders
Het beteken vermenigvuldig eerst alles na het = teken met hetgeen wat ervoor staat en stop dat resultaat weer terug in hetgeen voor het + teken staat.

x *= Y is dan vermenigvuldig eerst Y met X en stop dat terug in X. Het is dus een dubbele operatie en dat klopt ook want er staat een * plus = en er moeten dus 2 dingen gebeuren.

[Bericht gewijzigd door benleentje op zondag 6 oktober 2024 19:13:34 (32%)]

Op zondag 6 oktober 2024 16:52:58 schreef Fantomaz:
Wat dan met de -- of ++ die respectievelijk een vermindering of vermeerdering zijn van de betreffende variabele? Hoe zit het daar met de voorrangsregels?

Daar bestaan 2 varianten van, ++x betekent dat x met één wordt opgehoogd vóórdat de rest van de expressie wordt geëvalueerd, en x++ betekend dat het na de evaluatie gebeurd. In dat laatste geval heeft de x++ dus geen invloed op de uitkomst van de expressie, maar alleen op de nieuwe waarde van x.

Hoewel ik het wel gebruik, ben ik er een beetje huiverig voor, wat betreft de leesbaarheid; soms zie je een while met een x++ die beter een for loop had kunnen zijn. Soms zie je een x++ verstopt in een complexe regel waarbij het wellicht beter is om die x++ gewoon op een nieuwe regel te zetten.

@deKees en Benleentje,

Dit waren de antwoorden die ik zocht!
Inderdaad had een verkeerd beeld bij "=". In C zou het == moeten zijn.

Nu begint een stukje lesstof mij ook weer te dagen.

Er staat me ook iets van bij dat ik in geval van ++Y eerst de Y met 1 moet verhogen vóór ik andere handelingen doe.
Als het Y++ is, moet ik eerst die handelingen doen en daarna pas Y met 1 verhogen.

Als ik het verkeerd heb, hoor ik dat graag.

[edit] SparkyGSX, jij beantwoorde mijn laatste vraag nog voor ik je reactie had gelezen.

Op zondag 6 oktober 2024 18:51:25 schreef deKees:
x = y in de wiskunde betekent dat x en y gelijk zijn aan elkaar.
x = y in software betekent dat de waarde van y gecopiëerd wordt naar x. Dat is dus heel iets anders.

In C wel. Maar lang niet altijd in andere talen. Het kan ook een vergelijking zijn. A=B geeft dan een true als het waar is en een false als het niet waar is.

In een hoop talen kun je if A=B doen en dan is dat een vergelijking. In C is dat een kopieactie, daar doe je als je die vergelijking wil bereiken if A==B.

Een vaak gemaakte fout in C is het gebruiken van een enkele = waar een dubbele, ==, bedoeld wordt. C is hierin duidelijk anders dan andere talen, dit komt waarschijnlijk door de heel oude geschiedenis, uit 1972. Geen verbetering meer mogelijk.

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?'.

:= voor assingments en = voor vergelijkingen is misschien wel intuitiever dan = voor assignments en == voor vergelijkingen, maar onder de streep is het een arbitraire keuze die je gewoon moet onthouden.

Als ik het me goed voor de geest haal heb je ook talen zoals BASIC waar de = operator overloaded is. Dat werkt alleen als het altijd werkt zoals je denkt dat het werkt...

[Bericht gewijzigd door maartenbakker op zondag 6 oktober 2024 22:42:36 (30%)]

In een hoop talen kun je if A=B doen en dan is dat een vergelijking.

?? 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

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. 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. 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 dinsdag 8 oktober 2024 16:19:56 (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.