Wat doet deze coderegel?

In dit geval heb je inderdaad slechts 1 letter uitgespaard. Bij globale variabelen gaat het snel over meerdere letters. Des te meer letters, des te maar kans op fouten. In een programma gaat het ook zelden om 1 variabele maar over tientallen.

Dit is een discussie die even snel zal opgelost zijn als AVR/PIC, Windows/Linux/Mac, .... Werk je binnen een firma, dan is alles meestal heel strikt omschreven. Vaak liggen de naam en grootte (int8_t, uint8_t, uint16, ...) van de variabelen al vast. Dan doe je wat de werkgever vraagt. Thuis kan ieder voor zich kiezen wat het beste aanvoelt.

Op zaterdag 5 oktober 2024 14:30:51 schreef Arco:
De onderliggende gedachte om kost wat kost 1 letter minder in te moeten toetsen om de code veel duidelijker te maken vind ik belachelijk...

Ik denk dat je daarin redelijk bijzonder bent. Vrijwel iedere taal die ontstaan is na C (C++, Java, Perl, Python, Ruby, Javascript, Rust, VisualBasic zelfs SystemVerilog) heeft zulke Augmented Assignment operators.

En ook C was niet de eerste: Algol heeft ze ook.

Oorspronkelijk was de bedoeling ook niet om het aantal tekens code te beperken.
Het was ook omdat de simpele compilers uit de jaren '70 van dit:


x = x + 1;

zoiets maakten:


Laad locatie-X in processor register
Verhoog processor register met 1
Berg processor register in locatie-X

Terwijl


x += 1;

wel opleverde:


verhoog locatie X met 1

Tegenwoordig is dat niet meer relevant, maar het is uiteraard onmogelijk een dergelijke constructie uit een taal te verwijderen.

Maar uiteindelijk is het de programmeur die de leesbaarheid bepaalt. Real programmers can write COBOL in any language.

Op zaterdag 5 oktober 2024 10:32:22 schreef Arco:


result = result + (pin_0 = 0x01)

Weinig langer en meteen duidelijk.

Is die rechter = een vergelijking of een assignment? Stel nou dat je daar onderscheid in zou maken, door voor een vergelijking == te gebruiken. Dat is letterlijk altijd maar één toetsaanslag extra, een dat is jouw grote argument.

In de praktijk zijn variabelen zelden maar één letter lang (tenzij je "zo'n programmeur" bent die het hele alfabet gebruikt, tot frustratie van iedereen die de code ooit moet lezen). In echte code gaat het al snel om verwijzingen naar arrays een structures, en dan is het echt veel simpeler als je het niet twee keer hoeft te lezen om te zien of er twee keer exact hetzelfde staat.

Maar goed, voor Arco is Basic prachtig en heilig en de taal des Gods, en al het andere, C in het bijzonder, is van de duivel. Ik kan me redden in C, Python, VHDL, Verilog, Matlab en Simulink, en nog wel een paar andere, en gebruik in elke situatie dat wat het beste past. De taal maakt niet de programmeur. Het zijn allemaal stukken gereedschap in een koffer, en als er alleen een hamer in je koffer zit zul je alleen op spijkers kunnen slaan.

Op zaterdag 5 oktober 2024 10:32:22 schreef Arco:
C is een van de weinige talen waarbij ik bij zulke kromme notaties altijd de C language reference erbij moet halen...

Op een bepaald moment ken je die wel uit je hoofd. Of je moet af en toe iets in C programmeren.

Op zaterdag 5 oktober 2024 14:30:51 schreef Arco:
De onderliggende gedachte om kost wat kost 1 letter minder in te moeten toetsen om de code veel duidelijker te maken vind ik belachelijk...

Ja maar draai je het om. Het is geen moeten maar je kan het gebruiken. En het is een kwestie van gewenning.

result += pin_0 ? 0x01 : 0;

is in basic

pic basic code:

result = result + (pin_0 = 0x01)

Weinig langer en meteen duidelijk.

Volgens mij is dat 

If pin_0 == 0x01 then {
 result = result + 0x01
} else {
  result = result + 0
}

Volgens mij word eerst het deel achter de ? geëvalueerd en dat de uitkomst opgeteld bij result.

Op zaterdag 5 oktober 2024 18:22:28 schreef ohm pi:
[...]Op een bepaald moment ken je die wel uit je hoofd. Of je moet af en toe iets in C programmeren.

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.

Op zaterdag 5 oktober 2024 17:57:11 schreef SparkyGSX:
[...] Is die rechter = een vergelijking of een assignment?

Een 'X = Y' tussen haakjes is altijd een vergelijking, assignment doe je niet tussen haakjes. (da's dus duidelijk)

In de praktijk zijn variabelen zelden maar één letter lang (tenzij je "zo'n programmeur" bent die het hele alfabet gebruikt, tot frustratie van iedereen die de code ooit moet lezen).

In de praktijk gezien dat een C 'programmeur' de labels 'loop', 'Loop' en 'LOOP' alledrie gebruikte, om dol van te worden... 8)7

Maar goed, voor Arco is Basic prachtig en heilig en de taal des Gods, en al het andere, C in het bijzonder, is van de duivel. Ik kan me redden in C, Python, VHDL, Verilog, Matlab en Simulink, en nog wel een paar andere, en gebruik in elke situatie dat wat het beste past.

Je kunt in elke taal programmeren, en vergelijkbare code krijgen, de kwaliteit hangt van de programmeur en de compiler af...
Ik heb graag een duidelijke taal en dat is Basic (Pascal ook trouwens)

De taal maakt niet de programmeur. Het zijn allemaal stukken gereedschap in een koffer, en als er alleen een hamer in je koffer zit zul je alleen op spijkers kunnen slaan.

"It's not the paintbrush, but the artist that makes a painting..."

Op zaterdag 5 oktober 2024 10:32:22 schreef Arco:


result += pin_0 ? 0x01 : 0;

is in basic


result = result + (pin_0 = 0x01)

Weinig langer en meteen duidelijk.

Niet dus: Jouw picbasic code in dit geval doet net wat anders als het C voorbeeld.

De C code doet exact dit, geen discussie over mogelijk:


if (pin_0 != 0)
    result = result + 0x01
else
    result = result + 0;
end if

En waar evalueert de expressie (pin_0 = 0x01) in picbasic naar?
Theoretisch een boolean, maar wie zegt dat 'true' 1 is en 'false' 0?
(In C is 'true' ook niet echt gedefinieerd, dan kan valles zijn als het maar niet 0 is).

Op zaterdag 5 oktober 2024 19:17:45 schreef Arco:
In de praktijk gezien dat een C 'programmeur' de labels 'loop', 'Loop' en 'LOOP' alledrie gebruikte, om dol van te worden... 8)7

Dat is een knoeier!
Die dingen moeten een fatsoenlijke herkenbare naam hebben.

Op zaterdag 5 oktober 2024 21:33:27 schreef ohm pi:
[...]Dat is een knoeier!
Die dingen moeten een fatsoenlijke herkenbare naam hebben.

Het was om aan te geven dat case sensitivity juist knoeien in de hand werkt...

Op zaterdag 5 oktober 2024 19:17:45 schreef Arco:
Een 'X = Y' tussen haakjes is altijd een vergelijking, assignment doe je niet tussen haakjes. (da's dus duidelijk)

Nergens in de wiskunde, en bij mijn weten ook in geen enkele andere taal dan basic (en varianten?) is de functie van een operator anders door de expressie in haakjes te zetten.

Anders gezegd:

(expr1 operand expr2) is altijd gelijk aan expr1 operand expr2

Natuurlijk kun je daar prima aan wennen, en dan is het niet anders dan logisch. maar dat argument geld evengoed voor de += operator in C.
En daarmee haal je eigenlijk je hele argument ertegen onderuit.

Case sensitivity is verreweg de minst slechte manier om rare excessen en geknoei te vermijden. Probeer voor de grap in Windows eens een bestand te hernoemen waar je per ongeluk een hoofdletter verkeerd hebt staan.

Nou zal je zeggen, slechte implementatie... Natuurlijk, want het is Microsoft... Maar als je er over na gaat denken, is er geen goede implementatie mogelijk.

Het lijkt mij dus verreweg het beste om er op te vertrouwen dat een programmeur zijn vak verstaat en niet op een of ander arbitrair algoritme dat bepaalt dat willekeurige tekens hetzelfde betekenen.

Probeer voor de grap in Windows eens een bestand te hernoemen waar je per ongeluk een hoofdletter verkeerd hebt staan.

?
Is geen probleem...

Kennelijk erg oud nieuws, zal wel Windows XP geweest zijn. In 7 lijkt het te werken. Het principe was: Omdat filenames niet case sensitive zijn, ziet hij het verschil niet. Kan zijn dat dat tegenwoordig/op andere manieren wel gewoon werkt, maar ik vond het altijd een goed voorbeeld van de kansloosheid van een systeem dat niet case sensitive is. Onder de streep zijn twee verschillende willekeurige characters altijd verschillend ondanks dat wij ze herkennen als op een of andere manier bijelkaar horend. Zelfs al kun je het in ASCII met een simpele operatie zien, je moet toch extra logica inbouwen op een plaats waar dat niet persé altijd goed afloopt.

Je kunt het niet volledig vermijden. Je zal altijd op twee gedachten moeten blijven hinken, denk aan gebruik van unicode in internetadressen waar je soms twee characters niet op het oog van elkaar kunt onderscheiden en hoe je daar als internetsecurity-software misschien wel op moet kunnen filteren.... Maar in een stricte logische omgeving zoals programmeertalen wil je geen arbitraire regels invoeren over characters die er anders uitzien maar hetzelfde moeten betekenen.

Op zondag 6 oktober 2024 15:46:35 schreef maartenbakker:
Dat moet, in elk geval de laatste keer dat ik het probeerde, met een tussenstap.

Da's dan lang geleden dat je Windows gebruikt hebt, is er al bijna 25 jaar... :+
(sinds XP)

Ik kwam er inmiddels ook achter en heb het aangepast. Blijft staan dat er valkuilen op de loer liggen als je arbitrair bepaalt dat bepaalde characters speciale onderlinge relaties hebben, zeker als niet de hele wereld het erover eens is of het op dezelfde manier doet. Bij Windows XP (denk ik dan toch) ging het fout omdat twee interne stukjes software er anders mee omgaan. Legacy, zo je wilt (zoals de meeste programmeertalen ook).

Een programmeur met slechte gewoontes is zelf de schuld van wat hij aanricht. Elke taal die Turingcompleet is, is altijd krachtig genoeg om jezelf in je voet te schieten. Een taal die rare beperkingen oplegt, zal een slechte programmeur verleiden om die op een rare manier te omzeilen.

En dan ga je als topic starter eens kijken of je vraag een antwoord opgeleverd heeft.
Ik was even vergeten dat het Circuitsonline betreft, met een ijzersterke en overvloedige participatie.

Waarvoor mijn respect en dank. Dat als eerste...

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.
Dat zal aan mijn opvoeding liggen. :-)

Zie ik dan X *= Y-1 staan, gaat dat niet meer op omdat ik niet weet wat ik dan aan moet met "*".

Omdat X = 5 en Y = 10 zou X iets anders moeten worden...
Dat dit 45 is, ontgaat me volledig.

De uitleg van de fout door mij beantwoorde vraag is iets verhelderend.
Ik moet de X met de Y vermenigvuldigen, vandaar de *.
Toch stelt wederom mijn simpele geest dat X * Y 50 moet zijn.

Inmiddels heb ik uit de verschillende reacties in dit topic op kunnen maken dat ik éérst alles rechts van het = teken moet uitvoeren.
OK... 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, tenzij zaken tussen haakjes staan.

Al met al vind ik de materie vooral zeer onlogisch en sluit ik me ook aan bij Arco.

Dat neemt niet weg dat ik open sta om te leren, dus als er een logica is, wil ik die graag begrijpen.
Dus... Kan ik het zo zien dat eerst alles rechts van het = teken moet worden verwerkt, ongeacht de regels aangaande volgordes?
Dat zal dan opgaan voor alle operatoren?
Wat dan met de -- of ++ die respectievelijk een vermindering of vermeerdering zijn van de betreffende variabele? Hoe zit het daar met de voorrangsregels?
Om het iets ruimer te trekken... Wat zijn de voorrangsregels die ik moet hanteren, rechts van het = teken?

Op zaterdag 5 oktober 2024 20:23:53 schreef henri62:
[...]
Niet dus: Jouw picbasic code in dit geval doet net wat anders als het C voorbeeld.

De C code doet exact dit, geen discussie over mogelijk:


if (pin_0 != 0)
    result = result + 0x01
else
    result = result + 0;
end if

En waar evalueert de expressie (pin_0 = 0x01) in picbasic naar?
Theoretisch een boolean, maar wie zegt dat 'true' 1 is en 'false' 0?
(In C is 'true' ook niet echt gedefinieerd, dan kan valles zijn als het maar niet 0 is).

Delphi is alweer leesbaar:
if pin_0 <> 0 then inc(result);
of Delphi en PLM:
if pin_0 <> 0 then result := result +1;

Waarom een nul erbij optellen?

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.

*= is een variant daarvan. Dat betekent: De totale waarde van rechts wordt vermenigvuldigd met de waarde van links en het resultaat wordt opgeslagen in links.
Daar is geen sprake van een volgorde. Dat is een enkele bewerking.
Anders is het als je meerdere operators op een regel zet:
x = a + b / c - d * e
Dan gelden de voorrangs regels wel.

En strikt genomen is de = (en dus ook *= en += en afgeleiden) ook onderhevig aan de voorrangs regels. Die wordt gelukkig pas uitgevoerd als alle andere bewerkingen gedaan zijn.

Voor een complete lijst : https://en.cppreference.com/w/cpp/language/operator_precedence

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