if condition schöner schreiben?

Elias *. schrieb:
> Es funktioniert, aber ich wollte fragen ob es eine schönere Lösung
> dafür gibt?

 Was soll da ohne Klammern richtig funktionieren ?

programmierer schrieb:
> Ich würde es so lassen, ich finde es gut lesbar.

 Ja, sicher.
 Erkläre mir mal bitte,  was da womit gemacht wird ?

Marc V. schrieb:
> Was soll da ohne Klammern richtig funktionieren ?

1

if( (0 <= i && i <= 3) || (8 <= i && i <= 11) || (16 <= i && i <= 19) || (24 <= i && i <= 27) ){ // something }

Ich hab's gerade aus dem Kopf geschrieben und die Klammern vergessen … 
es ging mir eher ums "Konzept". Aber klar ohne geht es natürlich nicht.

Aber hast du noch eine Idee das anders zu schreiben? Und Effizienz?

Hallo,

Marc V. schrieb:

>  Was soll da ohne Klammern richtig funktionieren ?

Wenn ich mich recht entsinne gibt es bei C Prioritäten die den Ablauf in 
einem längeren Ausdruck regeln. Die unterschiedlichen Operatoren werden 
nach sinkender Priorität ausgeführt. && hat dabei eine höhere Prio als 
||. Womit die && ausgeführt würden, bevor die || an der Reihe wären.

Oder liege ich da falsch?

Das es mit Klammern lesbarer wird ist keine Frage.

Marc V. schrieb:
> Elias *. schrieb:
>> Es funktioniert, aber ich wollte fragen ob es eine schönere Lösung
>> dafür gibt?
>
>  Was soll da ohne Klammern richtig funktionieren ?
>
> programmierer schrieb:
>> Ich würde es so lassen, ich finde es gut lesbar.
>
>  Ja, sicher.
>  Erkläre mir mal bitte,  was da womit gemacht wird ?

Das erste Beispiel ist nach C-Standard ausreichend.
C Operatoren haben Prioritäten, die im Standard festgelegt sind.
http://en.cppreference.com/w/c/language/operator_precedence

Wenns nicht funktionieren sollte, dann gibts mecker für den 
Compiler-Hersteller.

Man schreibt so was schöner, in dem man abstrahiert:

1

if (valueCanDividedBy4(i)) {

2

}

Die Funktion selber kann dann zwar auch unschön aussehen, aber allein 
ihr Name verrät dann bereits was sie tut und im Hauptprogramm ist alles 
gut leserlich.

Peter II schrieb:
> Cyblord -. schrieb:
>> Man schreibt so was schöner, in dem man abtrahiert:
>> if (valueCanDividedBy4(i)) {
>> }
>
> man kann es aber auch klar übertreiben.
>
>

1

> if ( a_groeser_b(a,b) && a_ist_gleich_5(a) && c_ungleich_null(c) )

2

>

Kann man. Muss man aber nicht. Und mein Beispiel war in Ordnung, 
wohingegen deins Nonsense ist.
Da man an den Beispielen oben schön sieht, dass es eben NICHT mit einem 
Vergleich getan ist. Und am Ende kommen IMMER noch Bedingungen dazu, 
z.B. negative Zahlen usw.
Und das fängt man am übersichtlichsten mit einer Funktion ab.

Elias *. schrieb:
> 1) Es funktioniert, aber ich wollte fragen ob es eine schönere Lösung
> dafür gibt?

- indem man's übersichtlicher aufschreibt:

if ((0 <= i && i <= 3) ||
    (8 <= i && i <= 11) ||
    (16 <= i && i <= 19) ||
    (24 <= i && i <= 27) )

wird doch gleich viel übersichtlicher, oder?

- oder indem man sich überlegt, welche Systematik dahinter liegt:

if ((i & 0xFFE7) < 4)

> if((i&(~27)==0) doSomething();

Genau wegen sowas ist C verpönt. Es geht NICHT um die kürzest mögliche 
Schreibweise, sondern darum dem Leser schnell zu sagen, was der Code tut 
und WARUM. Und das sieht man hier eben nicht. Die Kürze alleine bringt 
keinerlei Informationen.

Elias *. schrieb:
> Aber hast du noch eine Idee das anders zu schreiben? Und Effizienz?

 Stefan U. hat dir schon eine Antwort geschickt, aber trotzdem...
 Erstens, sehen was überhaupt erreicht werden soll und was
 dementsprechend geprüft werden muss.
 Danach versuchen, es so kurz und so übersichtlich zu schreiben wie
 nur möglich.

 Was die Effizienz betrifft:
 If Abfragen sind die schnellsten und kürzesten, Compiler versucht
 alles mit If-Abfragen zu lösen.

Achim S. schrieb:
> switch(i>>2)


 switch wird immer zu If-Abfragen übersetzt, ist aber in der Regel
 viel übersichtlicher als die entsprechenden If-Abfragen.

Toni M. schrieb:
> Die unterschiedlichen Operatoren werden
> nach sinkender Priorität ausgeführt. && hat dabei eine höhere Prio als
> ||. Womit die && ausgeführt würden, bevor die || an der Reihe wären.

Genau.

Und die Klammern nur deshalb, weil man sie nicht schreiben muß 
wegzulassen, ist kein guter Stil. Der Leser fragt sich dann: ist das ein 
ganz Schlauer oder hat er die Klammern vergessen? Die Schleife kann man 
beiden Seiten ersparen.

"if it was hard to write it doesn't need to be hard to read"

Marc V. schrieb:
> switch wird immer zu If-Abfragen übersetzt

Nö.

Wenn er will (und der Ansicht ist, daß es sich lohnt), macht der 
Compiler da auch mal eine Sprungtabelle draus.

Markus F. schrieb:
> Toni M. schrieb:
>> Die unterschiedlichen Operatoren werden
>> nach sinkender Priorität ausgeführt. && hat dabei eine höhere Prio als
>> ||. Womit die && ausgeführt würden, bevor die || an der Reihe wären.
>
> Genau.
>
> Und die Klammern nur deshalb, weil man sie *nicht schreiben muß*
> wegzulassen, ist kein guter Stil.

Deshalb sagte ich ja auch, dass es außer Frage steht was lesbarer ist. 
Es ging nur darum das behauptet wurde, es würde ohne Klammern nicht 
funktionieren. Das ist aber falsch. Nicht mehr und nich weniger ;)

Achim S. schrieb:
> Cyblord -. schrieb:
>> Genau wegen sowas ist C verpönt. Es geht NICHT um die kürzest mögliche
>> Schreibweise, sondern darum dem Leser schnell zu sagen, was der Code tut
>> und WARUM. Und das sieht man hier eben nicht. Die Kürze alleine bringt
>> keinerlei Informationen.
>
> Ist ja richtig. Nur hier fehl am Platz. Auch ich habe mehrere Varianten
> beschrieben. Keine bisher vorgestellt ist sinnvoll, da letztendlich
> unleserlich.

Was war an meinem Beispiel denn nun unleserlich?

>
> Ich vermute gar, dass der Thread-Ersteller tatsächlich irgendein
> Register überwacht.

Nun ja, wir wissen nicht WARUM er das machen will, was er tut, darum ist 
es schwer einen guten Namen dafür zu finden. Aber WENN wir es wüssten, 
könnte man diese Funktionalität sehr gut kapseln.

Dem Hauptprogramm sollte es nämlich ziemlich egal sein, ob nun ein 
Register überwacht wird, oder sonst was. Es will eine Bedingung prüfen. 
WIE diese geprüft wird, will man dort nicht sehen.

Toni M. schrieb:
> Es ging nur darum das behauptet wurde, es würde ohne Klammern nicht
> funktionieren. Das ist aber falsch. Nicht mehr und nich weniger ;)

 Ohne Klammern funktioniert das nur zufällig und nur mit diesem
 Ausdruck.
 Ein Mensch kann ganz einfach nicht mehr als 2 Zustände miteinander
 vergleichen, das Resultat wird dann mit nächsten Ausdruck verglichen
 usw.
 Dabei muss aber auch die Priorität beachtet werden...

 Irgendwo weiter oben war ein Beispiel wie das Ganze viel
 übersichtlicher geschrieben werden kann, zumindest für normale
 Menschen. Ob ich etwas mit einem Blick prüfen kann, oder ob ich
 mehrere Minuten mit Finger darüber rätseln muss was der Author
 überhaupt prüfen will, macht schon einen Unterschied.

 Masochismus nennt man so etwas.

Peter II schrieb:
>
> in der Schule haben wir schon alle gelernt wie man rechnen.
>
> 3 + 4 * 5
>
> bekommt man auch ohne Klammern sehr gut hin, als Programmieren sollte
> man zumindest wissen wie ein Compiler rechnen und da sind die Klammern
> nicht notwendig. Das ist auch kein Zufall das es funktioniert.

Auch wenn man es weiß. Übersichtlich ist es ganz einfach nicht. In dem 
Moment wo ich mir schon überlegen muss, wie der Compiler rechnet, läuft 
bereits was falsch.

Aber ganz ehrlich, von übersichtlichem (=clean) Code scheinst du nicht 
die Bohne zu verstehen.

Und eine Einstellung a la "das weiß man doch", ist einfach nur arrogant. 
Da sieht man gleich, da will jemand mit seinem Code posen, anstatt ihn 
leserlich zu schreiben.

programmierer schrieb:
> Ernst gemeinte Frage?

 Ja, aber bitte so, wie du diesen Ausdruck liest, also erst einmal
 nach Prioritäten suchen, dann einen Vergleich, wieder Prioritäten,
 Vergleichen, Prioritäten...

 Und wenn du dann ohne Bleistift und Papier immer noch das Resultat
 der letzten Operation behalten hast, werde ich dich für Nobelpreis
 vorschlagen.

Peter II schrieb:
> Und ja
> ich kann Code auch ohne klammern lesen.

Genau DIESE frühkindliche Arroganz meine ich. Solltest du nicht alt 
genug sein um das langsam mal abzulegen?

>> Aber ganz ehrlich, von übersichtlichem (=clean) Code scheinst du nicht
>> die Bohne zu verstehen.
>was war an meinen Beispiel nicht lesbar?

q.e.d.

Holla die Waldfee, das war ja mal eine sehr ausführliche Debatte über 
ein IF Statement. :) Vielen Dank für die ganzen Antworten! Ihr habt mir 
sehr geholfen.

Peter II schrieb:
> Und ja ich kann Code auch ohne klammern lesen.

 Sicher, ich und jeder andere auch.
 Kannst du es aber auch verstehen ?

 Wenn jemand portugiesische und swahili Texte lesen kann, bedeutet es
 noch lange nicht, dass...

Peter II schrieb:

> von euch beiden kam kein sinnvoller Lösung wie man es schöner/einfacher
> schreiben kann, aber Hauptsache versuche andere Fehler bei andere Leute
> zu finden - ist das nicht etwas albern?

Ich habe eine sinnvolle Lösung gepostet. Und ich habe keinerlei Fehler 
bei dir gesucht. Was redest du für wirres Zeug? DU hast meine Lösung 
angegriffen du Vogel.

Schöner Code fängt nun mal früher an und geht deutlich weiter als sich 
zu überlegen ob man nun Klammern setzt oder Switch nutzt oder 
Zeilenumbrüche einfügt.

Aber wie gesagt, davon verstehst du nichts und das wirst du 
wahrscheinlich auch nicht mehr auf die Kette bekommen.

Peter II schrieb:
> Cyblord -. schrieb:
>> Ich habe eine sinnvolle Lösung gepostet. Und ich habe keinerlei Fehler
>> bei dir gesucht. Was redest du für wirres Zeug? DU hast meine Lösung
>> angegriffen du Vogel.
>
> du hast nur eine Funktion eingefügt, und nicht den Inhalt der Funktion
> gezeigt. Es gibt um den "Ausdruck" der vereinfach werden sollte. Einfach
> eine Funktion an der Stelle einfügen ist leider keine Lösung.

Lass gut sein, ich kann akzeptieren dass das über deinen Verstand geht. 
Solltest du auch langsam mal.

Elias *. schrieb:
> Marc V. schrieb:
>> Was soll da ohne Klammern richtig funktionieren ?
>
>
>

1

> if( (0 <= i && i <= 3) || (8 <= i && i <= 11) || (16 <= i && i <= 19) || 

2

> (24 <= i && i <= 27) ){ // something }

3

>

>
> Ich hab's gerade aus dem Kopf geschrieben und die Klammern vergessen …
> es ging mir eher ums "Konzept". Aber klar ohne geht es natürlich nicht.
>
> Aber hast du noch eine Idee das anders zu schreiben? Und Effizienz?

Es ist ein Irrtum, dass man Code in erster Linie so schreiben sollte, 
dass er möglichst effizient ist.

In erster Linie schreibt man Code so, dass er:
-das richtige Ergebnis liefert
-lesbar und wartbar ist

Das Optimieren überlässt man lieber dem Compiler. Der kann es im 
Zweifelsfall auch besser.

Natürlich sollte man sinnvolle Algorithmen verwenden. Wenn man das tut, 
ist Optimierung auf der Ebene "wie-kodiere-ich-das-am-besten-von-Hand" 
in sehr vielen Fällen komplett unnötig.

Johann L. schrieb:
> - indem man's übersichtlicher aufschreibt:
>
> if ((0 <= i && i <= 3) ||
>     (8 <= i && i <= 11) ||
>     (16 <= i && i <= 19) ||
>     (24 <= i && i <= 27) )
>
> wird doch gleich viel übersichtlicher, oder?
>
> - oder indem man sich überlegt, welche Systematik dahinter liegt:
>
> if ((i & 0xFFE7) < 4)

Wer solchen Code schreibt, gehört verhauen. ;-)

Der GCC erlaubt auch:

1

switch(i){

2

  case  0 ...  3:

3

  case  8 ... 11:

4

  case 16 ... 19:

5

  case 24 ... 27:

6

         doSomething(); 

7

         break;

8

}

Paddy schrieb:
> if (i & 0b11100100 == 0) ...

Diese Lösung ist natürlich am besten lesbar.
Sie sagt auf einen Blick, welche Bits 0 sein müssen und welche egal 
sind.
Wenn Bitmuster auszuwerten sind, sind die Bitbefehle (&,|) zu 
bevorzugen.

NurEinWort schrieb:
> P.S. oder wenn man es wirklich kurz will wäre es if( ! ( i & 0xE7 ) )
> und nicht if( ( i & 0xE7 ) < 4 ). *klugscheiss*

Es wurde gar NIE nach kurz gefragt.

Finde die Originalversion verständlich, man kann den Ausdruck doch an 
den '&&' auftrennen und jemand, der in Mathe schonmal die 
Intervallschreibweise gesehen hat, versteht auch schneller als mit jeder 
Bitoperation, was hier gemeint ist?!
Lesbarer ist es mit Zeilenumbruch und von mir aus auch noch mit 
Klammern.

Geht es hier wirklich um gesetzte Bits? Dann sieht die Sache ggf. anders 
aus.

Aber ein "(i & 0xFFE7) < 4" finde ich persönlich deutlich schwieriger.

Peter D. schrieb:
> Paddy schrieb:
>> if (i & 0b11100100 == 0) ...
>
> Diese Lösung ist natürlich am besten lesbar.
> Sie sagt auf einen Blick, welche Bits 0 sein müssen und welche egal
> sind.

Aber sie sagt nichts darüber aus, warum gerade DIESE Bits zu prüfen sind 
und nicht irgendwelche anderen.

Im Endeffekt ist das auch eine "Magic Number", und von daher ist es 
keine wirklich gute Lösung.

Mark B. schrieb:
> Aber sie sagt nichts darüber aus, warum gerade DIESE Bits zu prüfen sind
> und nicht irgendwelche anderen.

Das ist nicht wichtig. Wichtig ist allein die Tatsache, daß es um 
Bitmasken geht.
Dieses Konzept mit Maskieren und Vergleichen findet man z.B oft bei der 
Adressierung von seriellen Schnittstellen wieder (CAN-ID, RS-485, I2C 
usw.).
Die Maskierung sagt z.B. aus, welchen Priorität die Adressen haben oder 
ob sie sich überlappen oder ausschließen.
Mit magischen Dezimalvergleichen ist sowas völlig unübersichtlich.

Peter D. schrieb:
> Mark B. schrieb:
>> Aber sie sagt nichts darüber aus, warum gerade DIESE Bits zu prüfen sind
>> und nicht irgendwelche anderen.
>
> Das ist nicht wichtig. Wichtig ist allein die Tatsache, daß es um
> Bitmasken geht.

Aha und wenn die gewünschte Informationen nicht mehr über die Bits 
reinkommen, sondern z.B. über einen UART und darum ganz anders aussieht? 
Dann schreiben wir das ganze um, weil es dann ja nicht mehr um Bitmasken 
geht?

Darum abstrahieren. Wie dann die abstrahierte Funktion, die Information 
bekommt oder herleitet ist dann sekundär und das kann auch immer wieder 
geändert werden.

Wichtig ist dem Leser aber eben gerade NICHT dass es um Bits geht, 
sondern WAS wird eigentlich hier überprüft? Das will ich doch wissen 
wenn ich das lese. Und nicht, aha hier wird geguckt ob Bit 2 oder Bit 5 
gesetzt ist.

Peter D. schrieb:
> Mark B. schrieb:
>> Aber sie sagt nichts darüber aus, warum gerade DIESE Bits zu prüfen sind
>> und nicht irgendwelche anderen.
>
> Das ist nicht wichtig.

Selbstverständlich ist das wichtig. In einem Code Review kriegst Du 
sowas gleich um die Ohren gehauren. Und womit? Mit Recht!

Meinetwegen kann man es ja als 0b11100100 schreiben, wenn aus dem 
Funktionsnamen oder aus einem Kommentar ersichtlich ist, was da gerade 
geprüft wird bzw. warum gerade diese Bits.

Die Erfahrung zeigt: Nach einer Weile weiß man es sonst selbst nicht 
mehr ;-)

Paddy schrieb:
> if (i & 0b11100100 == 0) ...

Fast so hätte ich es auch gemacht, aber nur dann, wenn es wirklich kein
Zufall ist, dass die im Originalausdruck vorkommenden Konstanten diesem
einfachen System gehorchen.

Allerdings fehlen die Klammern um i & 0b11100100 (== bindet stärker als
&).

Um vom verwendeten Integer-Typ (8 Bit, 16 Bit usw.) unabhängig zu sein,
würde man vielleicht besser

1

if((i & ~0b11011) == 0)

oder

1

if((i & ~0x1b) == 0)

oder je nach persönlichem Geschmack auch

1

if(!(i & ~0x1b))

schreiben.

Edit: Natürlich mit einem kurzen Kommentar, woher die Konstante 0b11011
bzw. 0x1b kommt.

Cyblord -. schrieb:
> Aha und wenn die gewünschte Informationen nicht mehr über die Bits
> reinkommen, sondern z.B. über einen UART und darum ganz anders aussieht?

Ob das Byte mit magischen Bits drin nun in einem Register steht oder in 
einem per UART übertragenem Puffer, ist relativ egal. Das sollte sogar 
dir klar sein.

> Dann schreiben wir das ganze um, weil es dann ja nicht mehr um Bitmasken
> geht?

Wenn sich die Struktur ändert, ist dein Ansatz mit IstTeilbarDurchVier() 
genauso hinfällig. Sollte es tatsächlich um Bitmasken gegangen sein, war 
er schon vorher b'scheuert.

Da der TO aber den Hintergrund nicht angegeben hat, bleibt die der 
Aufgabenstellung angemessenste Methode ohnehin versteckt.

Cyblord -. schrieb:
> Aha und wenn die gewünschte Informationen nicht mehr über die Bits
> reinkommen, sondern z.B. über einen UART und darum ganz anders aussieht?

Was soll da anders aussehen?
Die Bits kommen seriell rein und haben eine von ihrer Position abhängige 
Bedeutung. Daher ist es besser lesbar, wenn man ihre Position klar 
erkennen kann.

Schau Dir einfach mal an, wie das beim CAN-Bus mit der ID-Auswertung 
funktioniert. Da hast Du je MOB ein CANIDT-Register und ein 
CANIDM-Register.
Mit dem CAN Identifier Mask Register gibt man an, welche Bits verglichen 
werden sollen und das CAN Identifier Tag Register enthält dann den zu 
vergleichenden Wert. Und da käme wirklich absolut niemand auf die Idee, 
diese beiden Register mit kryptischen Dezimalzahlen zu befüllen.

Elias *. schrieb:
> 2) Und wie sieht es mit der Effizienz aus? Brauchen diese ANDs und ORs
> viel Prozessorpower?

Das hängt vom verwendeten Compiler ab. Der AVR-GCC 6.3.0 liegt mit
seinem Ergebnis schon sehr nahe am Optimum:

1

  andi    r24, 0xE7

2

  cpi     r24, 0x04

3

  brcc    ...

Er halt also das dahintersteckende System erkannt.

Paddys Lösung ist allerdings noch einen Taktzyklus schneller:

1

  andi    r24, 0xE4

2

  brne    ...

Yalu X. schrieb:
> Paddys Lösung ist allerdings noch einen Taktzyklus schneller:
>
>
>

1

>   andi    r24, 0xE4

2

>   brne    ...

3

>

Für nicht verbrauchte Rechenzeit bekommt man kein Geld zurück. ;-)

S. R. schrieb:
> Ob das Byte mit magischen Bits drin nun in einem Register steht oder in
> einem per UART übertragenem Puffer, ist relativ egal. Das sollte sogar
> dir klar sein.

Sagen wir mal, es werden Taster abgefragt, vorher direkt per Port 
(Bitmaske) jetzt per UART in einem ganz anderen Format.

> Wenn sich die Struktur ändert, ist dein Ansatz mit IstTeilbarDurchVier()
> genauso hinfällig. Sollte es tatsächlich um Bitmasken gegangen sein, war
> er schon vorher b'scheuert.

Richtig, weil IstTeilbarDurchVier() ein Beispiel war, weil wir ja nicht 
wissen WAS wirklich abgefragt werden soll. Aus dem Eingangsbeispiel 
hätte aber ja die Prüfung einer Zahl auf Teilbarkeit eine Möglichkeit 
sein können.

Wenn wir beim Tasterbeispiel bleiben, müsste es lediglich lauten: 
IsButtonPressed(int buttonNr). Oder besser noch: isStartButtonPressed();

Und das ganze dahinter wird dann eben über Bitmasken, UART-Bytes, I2C 
Kommandos, egal was, realisiert.


> Da der TO aber den Hintergrund nicht angegeben hat, bleibt die der
> Aufgabenstellung angemessenste Methode ohnehin versteckt.
Ja ich weiß. Aber wenn man obigen Ansatz verfolgt, wird die 
Fragestellung des TE auf einmal immer weniger relevant weil das 
Konstrukt im Hauptprogramm gar nicht auftaucht sondern irgendwo in einer 
austauschbaren Funktion schlummert. Und auf jeden Fall auch nur einmal 
und nicht vielleicht 5 mal im Code verteilt. Und darum geht es mir.

Cyblord -. schrieb:
> Sagen wir mal, es werden Taster abgefragt, vorher direkt per Port
> (Bitmaske) jetzt per UART in einem ganz anderen Format.

Dann ändert sich die Struktur und du musst den Code ohnehin anpassen. 
Also ist diese Annahme im gegebenen Kontext reichlich bescheuert, und 
ich bin mir sicher, dass du das absichtlich tust.

Du diskutierst High-Level-Funktionen. Die wiederum nutzen 
Low-Level-Funktionen, um die es hier geht. Sicher ist ein 
isStartButtonPressed() sinnvoll, aber irgendwo bleibt es eine Maske.

S. R. schrieb:
> Dann ändert sich die Struktur und du musst den Code ohnehin anpassen.
> Also ist diese Annahme im gegebenen Kontext reichlich bescheuert, und
> ich bin mir sicher, dass du das absichtlich tust.

Nein ich muss EINE Funktion anpassen bzw. alle Tasterfunktionen.
Das Hauptprogramm bleibt völlig unbeeindruckt. DAS ist der Unterschied. 
Ein Riesenunterschied. Und daran ist auch nichts bescheuert. Das 
Beispiel ist gar nicht so realitätsfremd.


> Du diskutierst High-Level-Funktionen.
Nein ich diskutiere ein Konzept.

Hallo,

@ Cyblord

> Wichtig ist dem Leser aber eben gerade NICHT dass es um Bits geht,
> sondern WAS wird eigentlich hier überprüft? Das will ich doch wissen
> wenn ich das lese. Und nicht, aha hier wird geguckt ob Bit 2 oder Bit 5
> gesetzt ist.

@ Mark B. schrieb:

> Die Erfahrung zeigt: Nach einer Weile weiß man es sonst selbst nicht
> mehr ;-)

Nachdem jetzt jeder Experte seine Meinung kundgetan hat, hier mal ein 
Vorschlag von mir als schlechtem Hobbyprogrammierer:
In jeder mir bekannten Programmiersprache gibt es die Möglichkeit 
Kommentare einzufügen, die es ermöglichen (!! Achtung jetzt kommt es !!) 
zu erklären was der produzierte Quellcode eigentlich tun soll.
Man könnte zum Beispiel obige Codezeile auskommentieren und dann die 
effizientere Lösung verwenden, mit dem Kommentar als Hinweis das beide 
Codestücke die gleiche Funktion besitzen.

rhf

Johann L. schrieb:
> if ((0 <= i && i <= 3) ||
>     (8 <= i && i <= 11) ||
>     (16 <= i && i <= 19) ||
>     (24 <= i && i <= 27) )
>
> wird doch gleich viel übersichtlicher, oder?

nur frage ich mich ob das nicht schneller ist

statt if zu verodern:

if((0 <= i && i <= 3)
Bedingung erfüllt muss nicht zum else Zweig

else if(8 <= i && i <= 11)
Bedingung erfüllt muss nicht zum else Zweig

else if(16 <= i && i <= 19)
Bedingung erfüllt muss nicht zum else Zweig

usw.

Roland F. schrieb:
> Kommentare einzufügen, die es ermöglichen (!! Achtung jetzt kommt es !!)
> zu erklären was der produzierte Quellcode eigentlich tun soll.
> Man könnte zum Beispiel obige Codezeile auskommentieren und dann die
> effizientere Lösung verwenden, mit dem Kommentar als Hinweis das beide
> Codestücke die gleiche Funktion besitzen.

"Kommentare sind gut, lesbarer Code ist besser."

Warum erst verschwurbelten Code schreiben den man hinterher mit 
Kommentaren erläutern muss, anstatt gut lesbaren Code zu schreiben der 
nur minimal kommentiert werden muss?

Das Problem mit Kommentaren ist, dass sie dazu neigen zu veralten. Man 
Kommentiert schön, irgendwann ändert man was im Code und hat natürlich 
keinen Zeit den Kommentar nachzuziehen. Dann steht da irgendwas im Code 
was nicht aktuell ist.

Peter II schrieb:
> short evaluation ist in C schon lange definiert.

mag sein, mich überrascht der optimierende -o3 gcc in der Arduino IDE 
immer wieder, wenn ich denke ich schreibe es besser und kürzer kommt 
u.U. längerer Code raus.

Deswegen teste ich immer mehrere Möglichkeiten, mal mit Bits die ich 
setze und zurücksetze und mit dem Oszi, um die kürzeste Zeit zu finden, 
mal mit Codegröße um den kürzesten Code zu finden.

Hardcorefreaks kenne natürlich jede Laufzeit und machen das aus dem Kopf 
oder in ASM.

Joachim B. schrieb:
> Deswegen teste ich immer mehrere Möglichkeiten, mal mit Bits die ich
> setze und zurücksetze und mit dem Oszi, um die kürzeste Zeit zu finden,
> mal mit Codegröße um den kürzesten Code zu finden.
>
> Hardcorefreaks kenne natürlich jede Laufzeit und machen das aus dem Kopf
> oder in ASM.

Warum überhaupt derart "Hardcore" Optimieren? Eigentlich sollte das 
nicht die Regel sein, sondern nur in speziellen Ausnahmefällen nötig 
werden.

Bitwurschtler schrieb:
> Cyblord -. schrieb:
>> "Kommentare sind gut, lesbarer Code ist besser."
>
> Das Problem mit lesbaren Code ist, das nur Coder den lesen können. Gute
> Kommentare versteht auch der Service/Vertrieb/PM/etc. also jeder der die
> Spreache versteht in der der Kommantar verfasst wurde.

Der Service/Vertrieb/PM schaut in den Code? Wo soll das sein? Völliger 
Humbug.

> Lesbarer Code erhöht also die "Geheimnisskrämerei" unter der
> Programmieren und erschwert die Verifikation/Test durch
> Nicht-Programmierer.
Bitte? Code durch Nicht-Programmierer verifizieren lassen? Anhand der 
Kommentare? Was rauchst du eigentlich für ein Kraut?

> Lesbarer Code ist nicht selten nur eine Ausrede um sich vor der
> Dokumentation/Kommentierung zu drücken.
Klaro.

Bitwurschtler schrieb:
> Lesbarer Code ist nicht selten nur eine Ausrede um sich vor der
> Dokumentation/Kommentierung zu drücken.

oder eben schnell abzuliefern, wie sagte ein Chef mal, manchmal muss man 
dem Entwickler auch das Produkt aus der Hand reissen.

Ich arbeite ja nach top down, erst das grobe umschliessende Gerippe, 
dann die Feinausarbeitung und Kommentare oder lesbar erst wenn ich weiss 
das es funktioniert.

Ich verschwende möglichst keine Zeit für Lesbarkeit und Kommentare wenn 
ich nicht weiss ob diese Routine überlebt.

Bitwurschtler schrieb:
> Elias *. schrieb:
>
>> 1) Es funktioniert, aber ich wollte fragen ob es eine schönere Lösung
>> dafür gibt?
>
> Klar, mit Kommentaren verstehts auch die Grandma
>

1

> /*     range 0 .. 3   or  range 8 .. 11    or  range 16 .. 19    or 

2

> range 24 .. 27 */

3

> if ( 0 <= i && i <= 3 || 8 <= i && i <= 11 || 16 <= i && i <= 19 || 24 

4

> <= i && i <= 27){ // something }

5

>

Dann kannst Du den Code auch gleich so schreiben, daß man ihn ohne 
Kommentar versteht:

1

static inline int in_range(int value, int low, int high)

2

{

3

    return (low <= value && value <= high);

4

}

5

6

...

7

    if (in_range(i, 0, 3) ||

8

        in_range(i, 8, 11) ||

9

        in_range(i, 16, 19) ||

10

        in_range(i, 24, 27))

11

    {

12

        ...

13

    }

Das unterbricht den Lesefluss nicht und wenn Du das Ding das nächste Mal 
brauchst, ist es schon da.

> Warum erst verschwurbelten Code schreiben den man hinterher mit
> Kommentaren erläutern muss, anstatt gut lesbaren Code zu schreiben der
> nur minimal kommentiert werden muss?

Ich hatte vor einiger Zeit ein fast gleiches Problem wie Elias. Die mit 
Abstand am besten zu verstehen de Version wäre eine Kette von 16, 
ineinander verschachtelten IF-Abfragen gewesen. Das gefiel mir nicht und 
habe eine Lösung gefunden, die mit einer einzigen Zeile auskommt.
Hätte ich auf den Vorteil der deutlich effizienteren und Speicher 
sparenden Version verzichten sollen nur um eine bessere Lesbarkeit des 
Quellcodes zu erreichen?
Ich habe das Problem der schwereren Verständlichkeit meiner Lösung 
dadurch gelöst, das ich einfach die Funktion in einem Kommentar 
dokumentiert habe.

> Das Problem mit Kommentaren ist, dass sie dazu neigen zu veralten. Man
> Kommentiert schön, irgendwann ändert man was im Code und hat natürlich
> keinen Zeit den Kommentar nachzuziehen.

Ich finde das Kommentieren zum Programmieren dazu gehört.

rhf

Bitwurschtler schrieb:
> Also bei uns passiert es schon das der Vertreinb/Service schon mal
> nachfragt ob das Gerät selbst prüft welche Eingaben
>
> Cyblord -. schrieb:
>>> Lesbarer Code ist nicht selten nur eine Ausrede um sich vor der
>>> Dokumentation/Kommentierung zu drücken.
>> Klaro.
>
> Das meine ich Ernst, muss dich ja nicht angesprochen fühlen.
> Aber meisten ist es so, das Softwerker die Verständlichkeit ihres Codes
> masslos überschätzen und Nachwuchs-Programmierer die den Alt-code
> weiterpflegen sollen nur auslachen wenn die hofflich um Erklärungen
> bitten.
> Genialität ist selbsterklärend -- jajaja.
> Job security by code obfuscation - ich doch nicht ?!?

Ja, vor allem, wenn in dem genialen Code Fehler sind und der 
Nachwuchsprogrammierer dann anhand des fehlerhaften Codes rausfinden 
darf, was denn der geniale Programmierer wohl geschrieben haben würde, 
wenn er wirklich genial und fehlerfrei programmiert hätte.

Das sind dann die Programme, die von Grund auf neu geschrieben werden 
müssen.

Gruss
Axel

C. A. Rotwang schrieb:
> Das Stichwort ist "Kontext" - also der Kommentar muss für sich allein
> das Programm erklären, der Code selber ist für diese Erklärung völlig
> unnötig und ungeeignet.

Der Code kann das oft schon erklären, wenn man ihn denn läßt.
Wenn man aber mit kryptischen Vergleichen von Dezimalzahlen verschleiern 
will, daß hier nur bestimmte Bits getestet und bestimmte Bits maskiert 
werden sollen, dann muß man das wenigstens auch im Kommentar 
hinschreiben.
Man könnte in diesem Fall aber auch den verständlichen Code als 
Kommentar hinschreiben:

1

// to realize this function: if (i & 0b11100100 == 0) ...

Wenn wir gerade bei Literatur sind, empfehle ich wärmstens

Clean Code: A Handbook of Agile Software Craftsmanship
Robert C. Martin
978-0132350884

Peter D. schrieb:
> C. A. Rotwang schrieb:
>> Das Stichwort ist "Kontext" - also der Kommentar muss für sich allein
>> das Programm erklären, der Code selber ist für diese Erklärung völlig
>> unnötig und ungeeignet.
>
> Der Code kann das oft schon erklären, wenn man ihn denn läßt.
> Wenn man aber mit kryptischen Vergleichen von Dezimalzahlen verschleiern
> will, daß hier nur bestimmte Bits getestet und bestimmte Bits maskiert
> werden sollen, dann muß man das wenigstens auch im Kommentar
> hinschreiben.
> Man könnte in diesem Fall aber auch den verständlichen Code als
> Kommentar hinschreiben:
>

1

> // to realize this function: if (i & 0b11100100 == 0) ...

2

>

Das ändert aber alles nichts daran, dass der Code komplett 
unverständlich ist, sobald da ein Fehler drin ist.

Dann sollte der Kommentar im ungünstigsten Fall wenigstens erläutern, 
was der Code denn hätte machen sollen.

Sonst kann man den nach ein paar Monaten nur noch wegschmeissen, weil 
weder der Autor und schpon gar nicht ein Anderer den Hauch eine Chance 
hat, den Fehler zu finden.

Gruss
Axel

Achim S. schrieb:
> Für schlechtere Programmierer (also immer ;-) programmiert man
> konservativ, hier z.b. Klammern, sinnvolle Namen.

 Klammern in solchen Ausdrücken gehören immer dazu. Die paar
 Sekunden die es länger dauert, zahlen sich bei der Fehlersuche
 schon aus.
 Und nur Morons müssen sich selber durch unlesbaren Code ständig
 beweisen, dass sie programmieren können.

 Abgesehen davon, dass kürzest geschriebener Ausdruck nicht immer zu
 kürzestem Code auch compiliert wird.

> // to realize this function: if (i & 0b11100100 == 0) ...


Aber ich muss schon sagen, die Idee einen schwer lesbaren Code zu 
programmieren und mit einem vermeintlich besser lesbaren Code zu 
kommentieren ist mir wirklich noch nicht untergekommen. Das ist jetzt 
mal was neues. So programmiert man sicher auf dem Narrenschiff.

Achim S. schrieb:
> Der Kommentar beschreibt das Warum.hier z.b. dass diese Magic Numbers
> vom TO die bitoperationen für bit 0,1,3 und 4 obfuscieren sollen.

Sehr schön gesagt.
Ich vermute mal, das war aber nicht absichtlich. Anfänger tun sich oft 
schwer mit logischen Operationen, obwohl diese für die hardwarenahe 
Programmierung essentiell sind. Einzelne Bits haben immer eine große 
Bedeutung, ob es nun Konfigurationsbits sind oder Portpins.

Da hilft nur, sich die Verschleierung schleunigst abzugewöhnen und immer 
die passenden logischen Operatoren hinzuschreiben. Das ermöglicht auch 
später noch durch den Quelltext überhaupt durchzusehen.

Es schreibt ja auch niemand:

1

  switch( PINB ){

2

    case   0 ...  63:

3

    case 128 ... 191: led_on(); break;

4

    case  64 ... 127:

5

    case 192 ... 255: led_off(); break;

6

  }

sondern:

1

  if( PINB & 1<<6 )

2

    led_off();

3

  else 

4

    led_on();

Peter D. schrieb:

> sondern:
>

1

>   if( PINB & 1<<6 )

2

>     led_off();

3

>   else

4

>     led_on();

5

>

Und hier Frage ich mich nun warum die LED an gehen soll, wenn Bit 6 in 
PINB nicht gesetzt ist. Warum nicht Bit 7, oder Bit 5?

Das KANN man natürlich mit einem Kommentar erschlagen z.B.
// Start Taster hängt an PB6 (Bit 6 in PINB)

Oder man schreibt einfach:

1

  if( button_pressed() )

2

    led_off();

3

  else

4

    led_on();

Denn für die LEDs hast du ja auch sprechende Funktionen gewählt (war das 
jetzt Zufall?) und schreibst NICHT PORTB |= (1<<3);
Warum also bei der Bedingung mit Bits wurschteln, bei der Aktion aber 
Funktionen aufrufen.
Kosistent ist das nicht.

Bitwurschtler schrieb:

> Jetzt im Nachhineien betrachtet ist mein Kommentarvorschlag wohl nicht
> optimal, nächster Vorschlag:
>
>

1

> /*     Check for subranges 0 .. 3 , 8 .. 11 , 16 .. 19 or 24 .. 27 */

2

> if ( 0 <= i && i <= 3 || 8 <= i && i <= 11 || 16 <= i && i <= 19 || 24 

3

> <= i && i <= 27){ // something

4

>

Jemand der DAS für gut kommentierten Code hält, sollte aufhören anderen 
Tipps geben zu wollen.

Cyblord -. schrieb:
> Warum also bei der Bedingung mit Bits wurschteln,

Ganz einfach, weil ich das Prinzip der logischen Operationen 
verdeutlichen wollte.
In der Praxis nehme ich natürlich auch vorher definierte Macros.

Bitwurschtler schrieb:
> Cyblord -. schrieb:
>> Jemand der DAS für gut kommentierten Code hält, sollte aufhören anderen
>> Tipps geben zu wollen.
>
> Was ist dein Vorschlag?

Ich rede hier schon genug und gebe genug Beispiele. Das da ist definitiv 
durch und wurde viel weiter oben schon behandelt. Auch von mir.

Auch deine Ausführungen zu lesbare Code vs. Effizienz sind hanebüchen, 
weil man dank guten Compilern derartige Überlegungen nur noch sehr sehr 
selten anstellen muss. Effizienz auf dieser Low-Level Ebene ist nicht 
mehr oft notwendig.
Wirkliche Effizienz kommt dann wieder bei Datentypen oder Algorithmen 
zum Tragen (HashMaps vs. Listen, Bäume, Sortieren, IO Zugriffe, Caching 
usw.). Und da steht Effizienz in keinem Widerspruch zu sauberem Code.

> Ganz einfach, weil ich das Prinzip der logischen Operationen
> verdeutlichen wollte.

Das verdeutlichen von Prinzipien führt selten zu gutem Code. Du bist 
eben der Meinung weil man hardwarenah programmeiert ist das Konzept der 
Bitmasken derart präsent dass man es überall in den Code streuen kann. 
Aber ich sage, ob hw-nah oder nicht, das spielt keine Rolle, solche 
Masken wild in den Code zu bauen, führt zu schwer leserlichem und schwer 
wartbarem Code.


> nein hast nicht. du hast kein Beispiel gegeben wie es lesbar ist und die
> gleiche Funktionalität vorhanden ist.
Peter, das meinst du nur weil du meinen Ausführungen intellektuell nicht 
folgen kannst.

Bitwurschtler schrieb:

> Wer sich auf seinen Compiler verlassen muss, der ist verlassen. Wer
> garantiert dir das der Code nicht durch einen andern Compiler übersetzt
> wird oder mit anderen Optimierungsoptionen? Willst du im Quelltext immer
> vermerken für welchen Compiler das snippet gedacht ist.

Dann musst du Assembler verwenden und darfst gar nicht kompilieren. 
Natürlich muss man sich auf den Compiler verlassen. Natürlich gibt es 
andere Compiler und sogar ganz andere Architekturen für die ein Programm 
vielleicht kompiliert wird.
Will man die absolute Effizienz muss man sich auf ein Zielsystem 
festlegen und ASM programmieren. Anderes geht es nicht.

> Nochmals, ich glaube nicht das ein Compiler immer den Konflikt zwischen
> Lesbarkeit und Effizienz auflösen kann. Er muss es auch nicht, wenn sich
> von dem Konzept "Lesbaren Code um jeden Preis und durch
> Kommentarvermeidung" löst.

Manuelle Optimierung von Syntax hinsichtlich Effizienz ist das 
schlimmste was man heutzutage so machen kann. Weil es die Effizienz in 
99% der Fälle nicht steigert, dafür die Fehleranfälligkeit drastisch 
erhöht.

@Peter:
Willst du nicht woanders spielen? Ich kann dich leider nicht ernst 
nehmen. Erst den Coder-Proll und dann den Clown raushängen lassen. Na 
danke.
Willst du nicht wenigstens mal eine Minute nachdenken über das was ich 
dazu geschrieben habe?

Cyblord -. schrieb:
> Bitwurschtler schrieb:
>
>> Jetzt im Nachhineien betrachtet ist mein Kommentarvorschlag wohl nicht
>> optimal, nächster Vorschlag:
>>
>>

1

>> /*     Check for subranges 0 .. 3 , 8 .. 11 , 16 .. 19 or 24 .. 27 */

2

>> if ( 0 <= i && i <= 3 || 8 <= i && i <= 11 || 16 <= i && i <= 19 || 24

3

>> <= i && i <= 27){ // something

4

>>

>
> Jemand der DAS für gut kommentierten Code hält, sollte aufhören anderen
> Tipps geben zu wollen.

Wieso, das ist super.

Denn damit würde der folgende Fehler:

1

/*     Check for subranges 0 .. 3 , 8 .. 11 , 16 .. 19 or 24 .. 27 */

2

if ( 0 <= i && i < 3 || 8 <= i && i <= 11 || 16 <= i && i <= 19 || 24

3

<= i && i <= 27){ // something

zumindest eine Chance haben, im Review gefunden zu werden.

Gruss
Axel

Cyblord -. schrieb:
> Das verdeutlichen von Prinzipien führt selten zu gutem Code.

Es führt aber zu verstehbarem Code.
Es ist nicht die Aufgabe des Compilers, zu erkennen, ob hinter 
kryptischen Vielfachvergleichen einfach nur eine Bitoperation steht, 
sondern die Aufgabe des Programmierers.
Und wenn dem so ist, dann hat er es gefälligst auch so hinzuschreiben.
Sonst wird der Code völlig chaotisch und unverstehbar.
Code muß nicht nur mathematisch richtig sein, sondern er muß auch 
sinnvoll erscheinen.

Natürlich kann man mit kryptischen Vielfachvergleichen auch ohne 
Bitoperationen feststellen, ob z.B. beim ATmega8 im TIFR-Register die 
Bits TOV0, TOV1 oder TOV2 gesetzt sind. Nur wird Dir dann jeder 
ernsthafte Programmierer nen Vogel zeigen.

nicht"Gast" schrieb:
> Axel L. schrieb:
>> Denn damit würde der folgende Fehler:/*     Check for subranges 0 .. 3 ,
>> 8 .. 11 , 16 .. 19 or 24 .. 27 */
>> if ( 0 <= i && i < 3 || 8 <= i && i <= 11 || 16 <= i && i <= 19 || 24
>> <= i && i <= 27){ // something
>>
>> zumindest eine Chance haben, im Review gefunden zu werden.
>
> Ja klar. Frage, was ist denn jetzt richtig. Der Code oder der Kommentar?
>
> Solche Fehler sollten bei Unit Tests auffallen, nicht bei Reviews.

Ist egal, entscheidend ist, dass da jemand drüber sieht, und eines von 
beidem korrigiert.

Und Tests sind immer schön, aber meine Erfahrung ist, dass man im Review 
regelmässig noch was findet, was im Test nicht aufgefallen ist. Im 
Beispiel oben wäre es fast schon Zufall, wenn ausgerechnet die 3 
getestet würde.

Natürlich nur, wenn die Kommentare was taugen, ansonsten kämpft sich 
keiner durch den Code und versucht zu verstehen, was da gemeint ist. Es 
ist sogar noch schlimmer, denn fehlerhafter Code ist schwerer zu 
verstehen, und dann ist die Neigung, den Tests zu vertrauen, statt die 
Ursache für das Unverständnis zu finden, noch grösser.

Gruss
Axel

Masl schrieb:
> Wie man also auf solche Antworten kommt:
> Johann L. schrieb:
>> if ((i & 0xFFE7) < 4)
>
> verstehe ich nicht wirklich.

Ich schon.
Das ist einfach nur ein erster Versuch gewesen, weil ja die eigentliche 
Aufgabe (Bitmaske) verschleiert wurde.

Peter D. schrieb:
> Ich schon.
> Das ist einfach nur ein erster Versuch gewesen, weil ja die eigentliche
> Aufgabe (Bitmaske) verschleiert wurde.

Niemand kennt die eigentliche Aufgabe mit Sicherheit, außer dem 
Themenersteller. Und der war nicht so clever sie uns zu nennen.

Bitwurschtler schrieb:
> nicht"Gast" schrieb:
>> Axel L. schrieb:
>>> Denn damit würde der folgende Fehler:/*     Check for subranges 0 .. 3 ,
>>> 8 .. 11 , 16 .. 19 or 24 .. 27 */
>>> if ( 0 <= i && i < 3 || 8 <= i && i <= 11 || 16 <= i && i <= 19 || 24
>>> <= i && i <= 27){ // something
>>>
>>> zumindest eine Chance haben, im Review gefunden zu werden.
>>
>> Ja klar. Frage, was ist denn jetzt richtig. Der Code oder der Kommentar?
>
> Das entscheidet die Spec, die muss man lesen.

Im Prinzip ja. Dann gibt es noch den schönen Fall, dass die 
Spezifikation falsch ist. Immer wieder toll :-)

Mark B. schrieb:
> Niemand kennt die eigentliche Aufgabe mit Sicherheit, außer dem
> Themenersteller.

Ich bin ja mit dir nicht immer einer Meinung, aber hier hast du absolut
recht :)

Deswegen frage ich mich gerade, warum die Leute hier über gute und
schlechte Kommentare zur Codezeile des TE diskutieren. Da der tiefere
Sinn bzw. die dahintersteckende Absicht dieser Codezeile nicht bekannt
sind, kann jeder ausgedachte Kommentar (egal wie er aussieht) nur die
Codezeile als solche in anderen Worten beschreiben. Solche Kommentare
sind aber – das wurde ja bereits zurecht festgestellt – völlig
überflüssig.

Ihr solltet den TE bitten, Sinn und Zweck seiner Codezeile in möglichst
kurzen Worten zu beschreiben. Seine Antwort wäre dann ein guter Kandidat
für einen Kommentar über der Zeile.