Hallo,
eine Frage zum guten Programmierstil hätte ich noch. Ich habe in einem
nicht von mir geschriebenen Programm gesehen, dass die if-Abfragen immer
ausgeschrieben wurden. So in der Art
1
if BooleanFlag <> 0
ich schreibe eigentlich nur immer
1
if BooleanFlag
Ist letzteres schlechter Stil? Ich dachte eigentlich dies sei allerorten
üblich.
Mit freundlichen Grüßen
Guido
Ich geh da nach der Devise: weniger ist mehr.
Wenn im Code steht
if( isEndschalterClosed )
Motor.Stop();
dann ist das für mich ausreichend gut zu lesen. Da brauch ich nicht
wirklich ein
if( isEndschalterClosed == true )
oder gar
if( isEndschalterClosed != 0 )
oder noch gefährlicher
if( isEndschalterClosed == 1 )
explizite Vergleiche nur dann, wenn damit auch eine Aussage verknüpft
ist. Ein boolscher Wert ist aber für sich (im Zusammenhang mit seiner
Benennung als Variablenname) schon eine Aussage, darum ist er ja bool
und deshalb geb ich der Variablen ja einen vernünftigen Namen. Die
Abfrage 'boolscher Wert == true' ist damit so ein bißchen doppelt
gemoppelt. So wie ein "weißer Schimmel" oder eine "runde Kugel" oder
eine "tote Leiche"
Hallo,
danke für die Antwort.
Karl Heinz Buchegger schrieb:> Die> Abfrage 'boolscher Wert == true' ist damit so ein bißchen doppelt> gemoppelt.
Vollkommen richtig. Jetzt wo Du es sagst. Ich muss jedoch noch etwas
nachhaken. Manche Funktionen liefern ja bei "Erfolg" eine Zahl zurück
(z. B. an Welcher Stelle ein bestimmter Buchstabe im String steht) und
bei "Misserfolg" den Wert 0. Ich verwende dann (z. B. in Matlab) dennoch
die if-Abfrage in der Art
1
if PositionOfCharakter
würdest Du dies auch so machen?
Mit freundlichen Grüßen
Guido
Guido C. schrieb:> Vollkommen richtig. Jetzt wo Du es sagst. Ich muss jedoch noch etwas> nachhaken. Manche Funktionen liefern ja bei "Erfolg" eine Zahl zurück> (z. B. an Welcher Stelle ein bestimmter Buchstabe im String steht) und> bei "Misserfolg" den Wert 0. Ich verwende dann (z. B. in Matlab) dennoch> die if-Abfrage in der Art>
1
if PositionOfCharakter
> würdest Du dies auch so machen?
Würde ich nicht.
Die Zahl in diesem Beispiel hat ja als Zahl für sich eine Aussage,
nämlich die Position. Und das es da einen speziellen Wert gibt, der
etwas aussagt, würde ich nicht verstecken wollen.
Den Vergleich lass ich nur an 2 Stellen weg:
* Bei Pointern, wenn es um die Frage geht: NULL oder nicht NULL
* wenn es sich wirklich um einen boolschen Wert handelt.
Wenn ich also de facto die Variable (oder was es dann auch immer
ist) mit dem Prefix 'Is' bennenen würde.
ALso: IsClosed, IsValid, IsFound
Aber gerade letzters hast du hier ja nicht. Der Wert den dir die
Funktion gibt ist ja in erster Linie eine Positionsangabe in die der
'Is...' Fall künstlich hineinoperiert wurde. Trotzdem würdest du die
entsprechende Variable ja nicht IsFound nennen, sondern zb FoundPosition
Was dann noch dazu kommt, sind die unterschiedlichen Philosophien, wie
eine Funktion einen Fehler meldet (und im Grund kann man diesen
Misserfolg als 'Funktion meldet Fehler' auffassen):
Die einen returnieren 0 im Fehlerfall und etwas ungleich 0 im
Erfolgsfall. Das hat den Vorteil, dass man sowas in Abfragen leicht
verwenden könnte. Das hat aber auch den Nachteil, dass man keine
Fehlerdifferenzierung machen kann (3 verschiedene Fehler melden).
Dann gibt es wieder die Umkehrung: 0 bedeutet Erfolg, ungleich 0 ist
Misserfolg. Was dann im Code wieder seltsam aussieht.
Hallo,
Karl Heinz Buchegger schrieb:> Würde ich nicht.
Ohje, ich habe das in Matlab bisher sehr oft so, wie von mir beschrieben
gemacht. Ich dachte bis zu Deiner Antwort meine Vorgehensweise wäre
üblich. Hier muss ich wohl in mich gehen und umdenken. O.K. wenn es den
Programmcode lesbarer/besser macht bin ich immer dabei! Danke.
Mit freundlichen Grüßen
Guido
Ich benutze auch immer die zweite Variante. Das ist kürzer und sieht
meiner Meinung nach besser aus. Als Argument dagegen wird manchmal
gesagt, dass es so nicht verständlich sei. Dem kann man aber ganz klar
widersprechen, weil das in C und Java (in Basic wahrscheinlich auch)
eindeutig definiert ist und man davon ausgehen kann, dass jeder
einigermaßen fortgeschrittene Programmierer mit den Grundlagen des
Standards vertraut ist. Sonst müsste man ja alles im Kommentar erklären.
Man kann ja nicht davon ausgehen, dass jeder weiß, was zum Beispiel if
macht.
Guido C. schrieb:> Ohje, ich habe das in Matlab bisher sehr oft so, wie von mir beschrieben> gemacht. Ich dachte bis zu Deiner Antwort meine Vorgehensweise wäre> üblich. Hier muss ich wohl in mich gehen und umdenken. O.K. wenn es den> Programmcode lesbarer/besser macht bin ich immer dabei! Danke.
Fass das bittet nicht als Dogma auf.
Ich wollte dir nur meine Gedankengänge zu dem Thema näher bringen.
Letzten Endes muss das jeder für sich selbst entscheiden (oder kriegt es
in einem Team aufs Auge gedrückt)
Hallo,
naja Deine Begründungen sind nicht von der Hand zu weisen. Ich bin
derzeit mein eigenes Team und da muss man mitunter schon sehr aufpassen,
dass man sich in seinem stillen Kämmerlein keine Programmierstil
aneignet, der schlecht ist. Letztlich wird ein Programmcode nur einmal
geschrieben aber mehrfach gelesen.
Mit freundlichen Grüßen
Guido
Guido C. schrieb:> Hallo,>> Karl Heinz Buchegger schrieb:>> Würde ich nicht.>> Ohje, ich habe das in Matlab bisher sehr oft so, wie von mir beschrieben> gemacht. Ich dachte bis zu Deiner Antwort meine Vorgehensweise wäre> üblich.
Halt Stopp!
Deine Vorgehensweise ist auch vollkommen üblich. Zehn andere Varianten
aber auch.
Irgendeiner könnte dir jetzt vorschlagen, statt
1
if Variable == 0
lieber
1
if 0 == Variable
zu schreiben. Vergisst man dann nämlich ein Gleichheitszeichen, wird
daraus nicht eine Zuweisung, sondern eine Fehlermeldung.
Geschmack, Anwendung und Rahmenbedingungen zählen. Und da Matlab-Code
ohnehin übles Gefrickel ist, würde ich mir da ernstlich keinen Kopf
machen ;-)
>>"if PositionOfCharakter" würdest Du dies auch so machen?>> Würde ich nicht.
Ich mag das auch nicht. Java hat es eliminiert, Groovy brachtes es als
sog. "Groovy truth" m. A. nach leider wieder zurück.
Was ich auch nicht mag:
1
bool b;
2
if (!b) {
da man bei längeren Variablen den ! übersehen kann. Stattdessen
1
if (b == false) {
Für eine bool'sche Variable ist m. E.
1
if (b) {
gut leserlich, das "== true" braucht es da m. E. nach nicht.
>if 0 == Variable>zu schreiben. Vergisst man dann nämlich ein Gleichheitszeichen, wird>daraus nicht eine Zuweisung, sondern eine Fehlermeldung.
Das falsche '=' sollte der Compiler bemerken, wer die Warnungen nicht
auf Anschlag dreht, hat sowieso kein Interesse an funktionierendem Code.
Das 'b == true' kann man auch konsequent fortsetzen: '(b == true) ==
true', '((b == true) == true) == true' usw.
Tom K. schrieb:>>if 0 == Variable>>zu schreiben. Vergisst man dann nämlich ein Gleichheitszeichen, wird>>daraus nicht eine Zuweisung, sondern eine Fehlermeldung.>> Das falsche '=' sollte der Compiler bemerken, wer die Warnungen nicht> auf Anschlag dreht, hat sowieso kein Interesse an funktionierendem Code.
Wobei ich sagen muss, dass das überhaupt ein seltsamer Fehler ist.
Den macht jeder am Anfang irgendwann mal. 2, 3 mal, vielleicht 5 mal.
Aber danach macht man ihn nie mehr wieder.
Dem gegenüber steht eine, zumindest für mich, seltsame Leseart. Da steht
zb
wenn 5 gleich dem Index ist
und das entspricht so gar nicht meiner Denkweise. Da frag ich mich:
Huch, was will er mir sagen, das sollte doch eigentlich heißen: Wenn der
Index gleich 5 ist. Da ist das falsche Hauptwort zum Subjekt geworden.
Noch schlimmer finde ich, wenn das dann wer durchzieht
wenn 5 kleiner als der Index ist
Da muss ich dann immer kurz überlegen und umstellen: Wenn der Index
größer 5 ist. Samt zugehörigem 2 Minuten Nachdenker: Muss das jetzt
größer oder doch größer/gleich heißen?
Ich finde die klassischen Schreibweisen viel natürlicher. Da liegt die
Betonung auf der Variablen die getestet werden soll, die muss eine
bestimmte Eigenschaft haben. Kann natürlich sein, dass ich ganz einfach
in meiner Denkweise gefangen bin und nur ich so sehe.
In der Zusammenfassung: Dieses == versus = ist in Wirklichkeit nicht das
große Problem, welches da jetzt entsprechende Umstellung mit
dazugehöriger Hirnverknotung erfordert.
Oder seh das nur ich so?
Karl Heinz Buchegger schrieb:> Kann natürlich sein, dass ich ganz einfach> in meiner Denkweise gefangen bin und nur ich so sehe.
Sehe ich ebenso, da krieg ich immer den berüchtigten Augenkrebs, am
besten noch:
1
if(true==isValid)
brrrr Wenn man wirklich so eine Angst vor solchen Fehlern hat muß man
die Warnun eben als Error compilieren oder auf eine Programiersprache
umsteigen wo dies prinzipbedingt nicht geht (z.B. erlaubt Java so eine
Zuweisung erst gar nicht, Ausnahme sidn booleanwerte welche man eh nicht
gegen true/false vergleichen sollte da unsinnig).
Karl Heinz Buchegger schrieb:> Oder seh das nur ich so?
nö.
Läubi .. schrieb:> (z.B. erlaubt Java so eine Zuweisung erst gar nicht
if(nInd = 0)
C# auch nicht. C# meckert dann nur rum, daß es kein Boolean ist. Aber
wenn man es konvertiert geht es wieder. Wie in C.
if (System.Convert.ToBoolean(nInd = 0))
Da weiss natürlich jeder sofort, was das soll.
Ist halt konsequent. Konsequenten Unsinn nenne ich sowas.
mfg.
Karl Heinz Buchegger schrieb:> Aber danach macht man ihn nie mehr wieder.
Naja, ich habe vor zehn Jahren mit C(++) angefangen und mir ist der
Fehler letztens nochmal passiert. Das lag zwar daran, dass ich das
Doppelgleich zu schnell gedrückt habe, so dass die Tastatur nur eins
registriert hat, aber das kann immer mal vorkommen.
Trotzdem bleibe ich bei der Standardschreibweise, weil man so einen
Vergleichsfehler dann doch recht schnell findet, wenn er einem nicht
schon beim Überfliegen auffällt.
Thread beobachten
Seitenaufteilung abschalten