Wolfgang schrieb:> Beantwortet deine Frage nicht, aber warum schreibst du nicht if (x=!x)> TX_String("\nxy\n");> else> TX_String("\nyz\n");
ist mir nicht in den Sinn gekommen, aber hast du Recht! Ich denke es
gibt viele Möglichkeiten
Die erst toggelt immer.
Die zweite nur mit Randbedingungen.
Noch besser wäre nur (x) in der ersten Version dann würde es auch mit
schwierigen Typen für x laufen.
Vorteil schrieb:> Welchen Vorteil hat diese if bedingung> if(x == 1)> {> x = 0;> [...]> }> gegenüber dieser> x ++;> if(x > 1)> {> x = 0;
(a) es ist für den Außenstehenden so klarer und schneller erfassbar, was
beabsichtigt ist.
(b) Für den Fall, dass "x" als "volatile" deklariert ist und noch von
einer nebenläufigen anderen Routine ausgewertet wird: "x" nimmt im
ersteren Fall nicht zwischendurch komische andere Werte an, sondern kann
ohne Mutexe direkt gelesen werden.
Wolfgang schrieb:> Beantwortet deine Frage nicht, aber warum schreibst du nicht if> (x=!x)> TX_String("\nxy\n");> else> TX_String("\nyz\n");
... weil es oft als schlechter Stil angesehen wird, eine Zuweisung ins
if() zu packen - nach Jahren weiß der geneigte Leser dann nicht mehr, ob
das tatsächlich so gewollt war, oder ob nur das zweite "=" vergessen
wurde.
(Siehe: Unklarhgeiten bei den zwischenzeitlichen Postings...)
(re)
re schrieb:> ... weil es oft als schlechter Stil angesehen wird, eine Zuweisung ins> if() zu packen ...
Bei C steht in jedem for eine Zuweisung, warum soll das im if
plötzlich böse sein.
> ... - nach Jahren weiß der geneigte Leser dann nicht mehr, ob> das tatsächlich so gewollt war, oder ob nur das zweite "=" vergessen> wurde.
Ein "!" ist kein "="
re schrieb:> Wolfgang schrieb:>> Beantwortet deine Frage nicht, aber warum schreibst du nicht if>> (x=!x)>> TX_String("\nxy\n");>> else>> TX_String("\nyz\n");>> ... weil es oft als schlechter Stil angesehen wird, eine Zuweisung ins> if() zu packen - nach Jahren weiß der geneigte Leser dann nicht mehr, ob> das tatsächlich so gewollt war, oder ob nur das zweite "=" vergessen> wurde.
und weil da die { } fehlen. Lass den String mal länger werden und jemand
teilt ihn deshalb auf zwei TX_String() auf -> Überraschung!
Hi, das ist für mich eine theoretische Frage die sich nicht so einfach
klären lässt. Ob besser oder schlechter kann man nur in der Praxis
klären.
Es mag sein das mal die eine Loesung besser ist oder die andere.
re schrieb:> (b) Für den Fall, dass "x" als "volatile" deklariert ist und noch von> einer nebenläufigen anderen Routine ausgewertet wird: "x" nimmt im> ersteren Fall nicht zwischendurch komische andere Werte an, sondern kann> ohne Mutexe direkt gelesen werden.
das leuchtet mir ein. tatsächlich ist die Variable als volatile
deklariert
Bauform B. schrieb:> und weil da die { } fehlen. Lass den String mal länger werden und jemand> teilt ihn deshalb auf zwei TX_String() auf -> Überraschung!
Keine Überraschung - dann wird es eher Zeit, sich mal wieder mit den
Grundlagen von C zu beschäftigen.
p.s.
re schrieb:> ... oder ob nur das zweite "=" vergessen wurde
Auf die Idee ein if (x == !x) als an dieser Stelle sinnvollen Ausdruck
zu erachten, wird wohl hoffentlich niemand kommen oder sollte dabei
zumindest ernsthaft ins Grübeln kommen.
Wolfgang schrieb:> re schrieb:>> ... weil es oft als schlechter Stil angesehen wird, eine Zuweisung ins>> if() zu packen ...>> Bei C steht in jedem for eine Zuweisung, warum soll das im if> plötzlich böse sein.>>> ... - nach Jahren weiß der geneigte Leser dann nicht mehr, ob>> das tatsächlich so gewollt war, oder ob nur das zweite "=" vergessen>> wurde.>> Ein "!" ist kein "="
Was die reine Funktionalität angeht, ist das schon klar.
Die Diskussion hat ja eben bereits demonstriert, dass beim flüchtigen
Lesen schon Verwechselungsgefahr besteht. Obwohl es gang und gäbe in
sehr vielen Quelltexten ist.
Der vom TO angefragte Vorteil liegt hier in der Redundanz gegenüber
Irrtümern. Erkauft mit mehr Prosa.
Ob das in einem bestimmten Kontext besser oder schlechter ist, muss der
TO für sich selbst entscheiden.
(re)
Wolfgang schrieb:> re schrieb:>> ... weil es oft als schlechter Stil angesehen wird, eine Zuweisung ins>> if() zu packen ...>> Bei C steht in jedem for eine Zuweisung,
Aber normalerweise nicht in dem Abschnitt, der die Bedingung enthält.
ODer schreibst du sowas wie:
1
for(intx=0;x++<10;)
2
// ...
?
> warum soll das im if plötzlich böse sein.
Ich finde, es erschwert das Lesen unnötig. Ich halte es für sinnvoll,
das Prüfen der Bedingung und das Modifizieren des Wertes, die zwei
separate und ganz unterschiedliche Operationen sind, auch separat
hinzuschreiben.
Oder anders: Man muss nicht alles zusammenfassen, nur weil man es kann.
Bauform B. schrieb:> und weil da die { } fehlen. Lass den String mal länger werden und jemand> teilt ihn deshalb auf zwei TX_String() auf -> Überraschung!
Wärst du da ernsthaft überrascht, wenn es dann ohne die Klammern nicht
funktioniert?
Wolfgang schrieb:> Auf die Idee ein if (x == !x) als an dieser Stelle sinnvollen Ausdruck> zu erachten, wird wohl hoffentlich niemand kommen oder sollte dabei> zumindest ernsthaft ins Grübeln kommen.
Aber zumindest auf die Idee, dass "!=" gemeint war, könnte man kommen -
und das ist ja beim TE auch passiert.
re schrieb:> ... weil es oft als schlechter Stil angesehen wird, eine Zuweisung ins> if() zu packen - nach Jahren weiß der geneigte Leser dann nicht mehr, ob> das tatsächlich so gewollt war, oder ob nur das zweite "=" vergessen> wurde.
Das gilt nur für "Grundschüler" und ist ansonsten Unsinn bzw.
gedankenloses Wiederholen!
Rolf M. schrieb:> Aber zumindest auf die Idee, dass "!=" gemeint war, könnte man kommen -> und das ist ja beim TE auch passiert.
Da helfen die Vorteil oben schon für bessere Lesbarkeit
vorgeschlagenen Leerzeichen im Quelltext, auch wenn sie dem Compiler
egal sind.
Zeigefinger schrieb:> Das gilt nur für "Grundschüler" und ist ansonsten Unsinn bzw.> gedankenloses Wiederholen!
Naja, zumindest hat Wolfgang es falsch umgesetzt, und zumindest hat das
bisher niemand angemeckert. Wenn ich so eine minimale if-zuweisung, wo
jeder erstmal stolpert, wo ich Warnungen für abschalten muss, schon
falsch mache, dann sollte ich den Stil nicht auch noch als sinnvoll
verteidigen.
Ich glaube, selbst PeDa, der keine Klammer zuviel setzt und ganz sicher
enorme Erfahrung hat, würde so etwas weder schreiben, noch hoppelfrei
lesen.
MISRA würde ich nicht unbedingt als gutes Beispiel sehen. Da werden so
manche Dinge einfach pauschal verboten, die an den richtigen Stellen den
Code verbessern könnten oder wo die MISRA-konforme Alternative eher
schlechter lesbar ist.
Rolf M. schrieb:> MISRA würde ich nicht unbedingt als gutes Beispiel sehen.
Misra ist ja eher ein Gefahrstoffregister. Bei manchen Gefahrstoffen
reicht es, wenn alle darin geschult sind (dann wird dieser aus dem
Register gestrichen), bei anderen muss zu jeder Verwendung ein
Warnaufkleber.
Misra ist natürlich vor allem für Anfänger und reine Programmierer. Aber
wie Wolfgangs Fehler zeigt, zuweilen auch für Profis hilfreich.
re schrieb:> ... wie z.B. die von MISRA & Co ...
Wer mal in der Automobilbranche gearbeitet hat, der ahnt warum die das
brauchen, mit Mittelmaß gehörst du dort zu den Besten.
MISRA hat mit SW Engineering nichts zu tun, genau so wenig, wie ISO9001
nicht wirklich was mit Qualität zu tun hat!
Auch sind Anweisungen in z.b. switch() normal ausserhalb der
"Grundschule".
Auch kann euer if() z.b. so geschrieben werden: if(x=!x, x), um auch den
Blinden noch zum Sehen zu verhelfen.
Zeigefinger schrieb:> Auch sind Anweisungen in z.b. switch() normal ausserhalb der> "Grundschule".
... und sehr oft auch nützlich in while(), z.b.
while (c=putc(), c) printf(c);
Zeigefinger schrieb:> while (c=putc(), c) printf(c);
Das ist ja auch ein Beispiel, wo es andernfalls einer Verrenkung bedarf
(wegen des while). Zudem hast Du beides getrennt, so dass die Intention
(und das Verhalten) klar und eindeutig sind.
Beim if des TO bzw. Wolfgang ist das nicht der Fall. Es ist egal, ob die
Zuweisung vor dem if steht. (von Einzel-Statements ohne Block mal
abgesehen).
Vorteil schrieb:> Welchen Vorteil hat diese if bedingung if(x == 1)
Gleiche Laufzeit weil gleiche Anzahl von Maschinenbefehlen egal welcher
if-Zweig genommen wird, üersichtlich.
> gegenüber dieser
Kein Vorteil, ein if-Zweig dauert länger.
Wolfgang schrieb:> if (x=!x)
Unübersichtlich, Verwirrend, leicht für Versehen-Fehler gehelten.
Besser wäre:
if(x)
TX_String("\nxy\n");
else
TX_String("\nyz\n");
x=!x;
Der Compiler sollte dasselbe draus machen.
re schrieb:> | "MISRA C:2004, 13.1 - Assignment operators shall not be used> | in expressions that yield a Boolean value"
Diese Regel ist (zumindest in dieser Formulierung) Unsinn, denn sie
verbietet u.a. auch folgendes:
1
boolb1=true,b2;
2
3
b2=b1;// Diese Zuweisung in einem Ausdruck, der einen booleschen
4
// Wert liefert, verstößt gegen MISRA-Regel 13.1.
Vermutlich ist die Regel anders gemeint und nur falsch formuliert.
Das zeigt dann aber, dass die MISRA-Autoren genauso große Schlamper sind
wie die Programmierer, die sie mit ihrem Regelwerk zu einem besseren
Programmierstil erziehen wollen.
Oder ist die Formulierung der Regel inzwischen vielleicht korrigiert
worden?
Vorteil schrieb:> Welchen Vorteil hat diese if bedingung
Ein weiterer Vorteil ist, dass sie für jeden Wert von x funktioniert
(und in den else- Teil übergeht)
Die zweite mit x++ kann wenn x vorher sehr gross war (und x als signed
definiert war) UB sein.
Yalu X. schrieb:> Diese Regel ist (zumindest in dieser Formulierung) Unsinn, denn sie> verbietet u.a. auch folgendes:
Bist Du sicher? Hab gerade keinen Zugriff auf Standards, wird der
Begriff yield wirklich so verwendet: also als Ergebnis einer Zuweisung,
auch wenn diese nicht verwendet wird?
A. S. schrieb:> Bist Du sicher? Hab gerade keinen Zugriff auf Standards, wird der> Begriff yield wirklich so verwendet: also als Ergebnis einer Zuweisung,> auch wenn diese nicht verwendet wird?
Ja, steht da so drin, ist aber eher nur eine Zusammenfassung der ganzen
Regel.
Dort steht nämlich drin:
1
However, it does not preclude assigning a Boolean value to a
2
variable.
Yalu X. schrieb:> Das zeigt dann aber, dass die MISRA-Autoren genauso große Schlamper sind> wie die Programmierer, die sie mit ihrem Regelwerk zu einem besseren> Programmierstil erziehen wollen.
Oh je
Thread beobachten
Seitenaufteilung abschalten