Laden...

Diskussion um Anfängerfehler == true / == false

Erstellt von herbivore vor 17 Jahren Letzter Beitrag vor 17 Jahren 9.040 Views
herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren
Diskussion um Anfängerfehler == true / == false

[EDIT] Abgetrennt von Checkbox-Array | Boxen prüfen u.ä.[/EDIT]

Hallo sh4rk,

nein, im Gegenteil, == true sollte man immer weglassen: Anfängerfehler == true / == false

herbivore

S
45 Beiträge seit 2006
vor 17 Jahren

danke für die info...

mfg hannes

Z
43 Beiträge seit 2006
vor 17 Jahren
Sorry herbivore, aber ...

... das ist nicht ganz wahr, was du da erzählst. Bedauerlicherweise ist dieser Thread (Anfängerfehler == true / == false ) gesperrt und man lässt die Benutzer mit fehlerhaftem/halbem Wissen herumlaufen. Deshalb antworte ich hier auf diese Falschaussage:

Wer '== true' benutzt, hat m.E. noch nicht vollständig verstanden, was eine boolsche Variable ist.

Wer '== true' im Vergleich nicht benutzt, hat das Konzept des expliziten Vergleichs - wie er durch "if" eingeleitet wird - nicht verstanden, könnte ich im Gegenzug behaupten. Dabei handelt es sich mitnichten um eine Tautologie, sondern bewirkt neben einer - zweifellos marginal und deshalb bestenfalls als tertiäres Argument tauglich - beschleunigten Kompilierung auch, dass die Autoren es dem Leser - bewusst oder unbewusst - einfacher machen, nachvollziehen zu können, was sie beabsichtigen.

Dementsprechend hinkt dein Beispiel auch gewaltig:

... wie bei jeder Verwendung von Integer-Variablen ein '+ 0' anzuhängen.

Abgesehen davon, dass ich von meinen Jungs im Sinne der Lesbarkeit sehr wohl erwarte, dass sie auch '+ 0' addieren, wenn es - beispielsweise in loops - sinnvoll für die Darstellung ist, wäre es zumindest im Kontext der hiesigen Unternehmensrichtlinien sogar ein Kündigungsgrund, vorsätzlich wider die Lesbarkeit zu verkürzen. Dies gilt insbesondere, da Quellcode heute vor allem anderen auf Wiederverwendbarkeit geschrieben und optimiert wird.

Tatsache ist, dass der Quelltext mit der Formulierung if (x==true); lesbarer wird. Die Abfrage if (x); hingegen bietet viel Interpretationsspielraum, den man erst mehr oder weniger aufwändig schließen muss. Aus der Perspektive des Qualitätsmanagements ist es weitaus leichter "!" zu vergessen/übersehen, als "==false" versehentlich falsch einzugeben.

fBed == false kann und sollte man ersetzen durch !fBed also die Negation.

Konsequent, dass ich auch daran etwas auszusetzen habe: Das "!"-Zeichen ist, insbesondere beim Debugging extrem schnell überlesen; während die Phrase '== false' nicht nur exakt das gleiche aussagt, sondern zudem auch die Negation ("!") intern vom Compiler nach '== false' rückübersetzt wird.

Es mag vielleicht schicker aussehen und bei der Freundin oder anderen Unbedarften sicher auch toll ankommen. Praktiker und Profis schätzen es jedoch i.d.R., wenn man sich nur dort auf den impliziten "== true/== false"-Vergleich reduziert, wo es die Lesbarkeit nicht beeinträchtigt.

Preisfrage: Wo ist die Fehleranfälligkeit wohl größer?

a) bool o = ((!((!((!((!x) ? true : false)) ? true : false)) ? true : false)) ? true : false);

oder

b) bool o = ((((((((x == true) ? true : false) == true) ? true : false) == true) ? true : false) == true) ? true : false);

und was unterscheidet die snippets oben von denen unten?

a) bool o = ((!((((!((!x) ? true : false)) ? true : false)) ? true : false)) ? true : false);

oder

b) bool o = ((((((((x == true) ? true : false) == true) ? true : false) == false) ? true : false) == true) ? true : false);

Und wenn es schon bei so kleinen Code-Fragmenten möglich ist, den Programmierer für mehrere Minuten "außer Gefecht" zu setzen, wie wahrscheinlich ist es, dass du den Fehler in tausenden von Zeilen findest?

Wenn du also auf die Verkürzungsoption hinweist, dann solltest du das nicht ganz so sehr von oben herab ("Anfängerfehler") machen, sondern berücksichtigen und festhalten, dass es - auch und gerade - im Lebenszyklus von oo-Software das Qualitätsmerkmal Wiederverwendbarkeit gibt.

S
95 Beiträge seit 2006
vor 17 Jahren

Hi zero,

es mag teilweise schon stimmen was du da schreibst. Allerdings hat herbivore auch Recht.

Man kann das aber auch nicht so pauschalisieren, sondern muss das eher im Einzelfall betrachten, wie es der einzelne handhabt und wie er es besser lesen kann.

Sicher ist es am Anfang leichter == true / false zu schreiben, aber im Laufe der Jahre wird man sicher für eine der beiden Varianten entscheiden.

Und zu deinem Beispiel muss ich auch was sagen:

Wann kommen wirklich so komplexe Formulierungen vor???

Weil wenn du so programmierst, dann steht das in Widerspruch mit dem von dir Bschriebenem.

Ich würde das dann halt einfach auf mehrere If - Else Statements aufteilen, dann haste auch wieder Lesbarkeit erreicht 😁 und da kannste dann auch wieder die kurze Schreibweise reinklatschen ...

so far
Syrinx

Das größte Misstrauensvotum gegen Gott ist ein Blitzableiter auf dem Kirchturm! 😁

Z
43 Beiträge seit 2006
vor 17 Jahren
Zweifellos hat Herbivore auch Recht.

Es lässt sich verkürzen. Machen sollte man es allerdings nur ausgesprochen selten und nur dort machen, wo es die Lesbarkeit eindeutig nicht beeinträchtigt. Und selbst das nunmehr simple Beispiel oben sollte dir zeigen, dass es schon bei relativ trivialen Dingen wesentlich einfacher zu lesen - und KORRIGIEREN - ist, wenn man den Vergleich explizit macht. 😉

Wann kommen wirklich so komplexe Formulierungen vor??? ... solche praktisch nie. 😉
Was hingegen aber immer wieder vorkommt, sind tausende Zeilen Quellcode, die einen, zwei oder drei Fehler beinhalten. Und die Suche darin gestaltet sich nicht weniger schwierig, als die Suche in dieser "komplexen" Formulierung. Es ist also nur eine symbolische Erhöhung des Schwierigkeitsgrades, wie er auftritt, wenn du dir 20 lokale und 45 globale Variablen und deren Zustände wenigstens annähernd merken musst.

Ich würde das dann halt einfach auf mehrere If - Else Statements aufteilen...

Du meinst, abgesehen davon, dass ich dich dann nach Hause jagen würde? 😉 Glaubst du wirklich, es wird lesbarer, wenn du es auseinander ziehst?



bool x = true;

if (x)
  x = !x;
if (!x)
  x = !x;
if (x)
  x = !x;

// Ich erwarte, dass x hier wahr ist.
// Wo ist der Fehler?

// Ist es nicht lesbarer - und damit leichter korrigierbar -, wenn ich schreibe:

bool x = true;

if (x == true)
  x = false;
if (x == false)
  x = true;
if (x == true)
  x = false;


herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren

Hallo zero,

ich verstehe nicht, was du mit einem Beispiel wie

bool o = ((!((!((!((!x) ? true : false)) ? true : false)) ? true : false)) ? true : false);

zeigen willst, außer das du damit genau die von mir bemängelten Tatutologien benutzt und damit genau den von mir bemängelten Fehler machst. Dass dein Code damit "unlesbar" wird, zeigt mir, dass ich Recht habe, wenn ich sage, dass man Tautologien weglassen soll.

Die Anweisung sollte man entsprechend des Tipps verkürzen zu:

bool o = x;

Ich bleibe vollständig bei meinen Aussagen in Anfängerfehler == true / == false, mal abgesehen davon, dass es in C echt falsch wäre, wenn man == true schreiben würde (egal auf welchen Wert ungleich 0 true definiert wäre).

herbivore

T
223 Beiträge seit 2006
vor 17 Jahren

Hiho,

Zero du schreibst, dass du bei deinen Jungs darauf bestehst, dass sie ein "+ 0" schreiben, aber wann sollte man denn +0 schreiben, kannst du da ein konkretes Beispiel geben?

Gruß Thomas

2.082 Beiträge seit 2005
vor 17 Jahren

Hallo zero,

tut mir leid aber ich kann deine Ansicht nicht teilen.

Dein Beispiel ist mir auch völlig unlogisch, wer so eine Abfrage erstellt sollte sich imho nochmal überlegen, ob er wirklich Programmierer werden will/kann.

Wer '== true' im Vergleich nicht benutzt, hat das Konzept des expliziten Vergleichs - wie er durch "if" eingeleitet wird - nicht verstanden Lässt sich so schlecht sagen oder nicht? Wer bei boolschen Variablen trotzdem noch == true benutzt kann genauso gut

if((myIntVar == 5) == true) {
}

schreiben.

Ich sehe keinen Punkt, bei dem ich herbivores Beitrag bemängeln kann.

Machen sollte man es allerdings nur ausgesprochen selten und nur dort machen, wo es die Lesbarkeit eindeutig nicht beeinträchtigt. Ich denke mal es ist Geschmakssache.

Ich habe 2 Jahre lang mit "== true" gearbeitet, bis mich jemand in die if-Abfrage richtig eingewiesen hat und was im Kopf der if-Abfrage eigentlich passiert. (War vorher auf einer Informatikschule 🤔 )

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

347 Beiträge seit 2006
vor 17 Jahren

Wenn ich sowas sehe:

fBed == false

...ist mir auch vollkommen klar, warum du mit Händen und Würgen versuchst deutklich zu machen, dass es sich um einen bool'schen Ausdruck handelt.

Du benutzt en Substantiv für ein Feld[1], das einen Boolean enthält.
Woher zum Geier sollte der Leser auch wissen, dass es ein Boolean ist?
Booleans sollten immer so benannt werden, dass ein klarer Ja/Nein-Status erkennbar ist.
Bleistiftsweise: IsBed, IsSomething, AllowDingsBums, UseXyz, Active,...

Jetzt stellst du einfach eine Bedingung anhand dieses Status:

if(AllowDeleteXyz)
  DeleteXyz();
else
  throw new DingsBumsNotAllowedException(blabla);

Das Ganze mag sich für mich als alten Pascalhasen vllt nicht so hübsch lesen wie es mit Wörtern statt Sonderzeichen möglich wäre...
Jedoch ist ein ganz klarer Ablauf erkennbar, OHNE dass der Leser wissen muss ob die Bedingung einen Boolean enthält.
Es könnte genauso gut irgendein Typ sein, der implizit in einen Boolean gewandelt wird.
Vernünftige Benennung und korrektes Benutzen von Sprach features sollte es absolut unnötig für den Leser machen, zu wissen welche Typen benutzt werden um zu verstehen was in einem lokalen Schnipsel Code passiert.
Das ist nur nötig um globale Auswirkungen zu verstehen, aber die Lesbarkeit wird IMHO dadurch bestimmt wie schnell man erfassen kann was lokal passiert. 😉

[1]falls ich ein delphi-like fXXX hier richtig deute 😉

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Robert G,

hm, mir kommt es so vor, als würde da was durcheinanderer gehen. Wenn meinst du denn mit 'du'?

Das Beispiel fBed == false ist ja von mir. Aber es ist als Negativbeispiel gemeint. Ich meine nämlich, dass klar ist, dass es um einen boolschen Ausdruck geht und versuche gerade nicht mit "hängen und würgen" darauf hinzuweisen, genau im Gegenteil.

herbivore

Q
214 Beiträge seit 2006
vor 17 Jahren

Hallo,

Original von frisch

Ich sehe keinen Punkt, bei dem ich herbivores Beitrag bemängeln kann.

Also wenn viele Programmierer mit verschiedenen Prog. Sprachen zusammenarbeiten, sollte man sich schon überlegen, dass jeder if(x== true) schreibt.

Denn bei if(x) wäre es für einen C++-Programmierer nicht klar, dass x unbedingt eine bool Variable sein muss, für ihn kann es z.B. auch eine Int-Variable sein.

Das gleiche, nur andersrum:

if(x)
return 100/x;
else
//Error, keine Division durch 0

Für einen C# Programmierer recht ungewohnt, in C wäre dieser Ausdruck aber kein Problem (und ich sah schon viele Programme/Scripts die soetwas verwendet haben, vorallem in fast jedem PHP Script sieht man so etwas in der Art). Aber zur besseren Lesbarkeit sollte man sich auf:

if(x > 0)

einigen, aber dann auch auf if(x == true) //Sofern x eine bool Variable ist

Meine Meinung dazu 😉

Edit:
PS: Ich verwende == false immer dann, wenn ich dies besonders deutlich hervorheben möchte, also dieses == false so extrem wichtig ist, dass man es auf keinen Fall überlesen darf.
Sonst benutze ich aber auch meistens if(x) bzw. if(!x)

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Qwald,

gerade in C und C++ wäre es aber in vielen Fällen falsch, == true zu schreiben! Damit bricht aber leider deine Argumentation in sich zusammen.

herbivore

347 Beiträge seit 2006
vor 17 Jahren

Original von herbivore
Hallo Robert G,

hm, mir kommt es so vor, als würde da was durcheinanderer gehen. Wenn meinst du denn mit 'du'? Ups, sorry.
Aber ich hatte mir seine Variablen angesehen und hatte es schon geschrieben.
Danach bin ich nur wild durch den Thread gescrollt und habe mir die erste var gekrallt von der ich dachte sie wäre seine. Ging wohl nach hinten los. 😁

Aber um mich selbst ein wenig in allgem. verständliche Sprache zu übersetzen: ( 😁 )

Wenn man einen Namen eines bool'schen Ausdruckes hat, der ganz klar seinen Jupp/Nope-Status klarmacht, ist ein "if" nur ein halbwegs natürlich lesbar Satzanfang dafür.

Wenn ich DeleteXyz ausführen darf, rufe DeleteXyz auf, andernfalls wirf' dem User was ins Gesicht.
Auf CSharpish sieht das nunmal so aus:

if(AllowDeleteXyz)
  DeleteXyz();
else
  throw new DingsBumsNotAllowedException(blabla);

@ QWald, ob du es willst oder nicht: you made my point! 😜

S
8.746 Beiträge seit 2005
vor 17 Jahren

true-Vergleich ist nicht meine Sache. Die genannten Beispiel gehen m.E. an der Praxis vorbei.

Bei der Negation finde ich es aber überlegenswert anstelle des "!" den false-Vergleich zu verwenden. Viel besser gefällt mir in Pascal "not", aber leider hat sich C# an der Stelle zu viel von C abgeschaut.

Das schmale "!" ist leider viel zu leicht zu übersehen.

3.511 Beiträge seit 2005
vor 17 Jahren

Da muss ich svenson allerdings Recht geben. Ich entwickle seit Jahren in Pasal/Delphi und da gefällt mir ein "not" ebenfalls besser als ein "!". Liegt aber wahrscheinlich nur an der überschaubarkeit, bzw. das es leßbarer ist. Ein

if (Blub <> 0) and (not GehNachHause) then

finde ich schöner zu lesen als

if (Blub != 0 && !GehNachHause)

Aber das ist reine Geschmackssache und man gewöhnt sich irgendwann an alles. Allerdings kloppe ich meinen Mitarbeitern jedesmal auf die Finger wenn ich konstrukte wie

if (Bla > 0) then X := False else X := True;

oder (sehr beliebt)

if (X) then X := False else X := True;

Könnt ich jedesmal explodieren, weil das überflüssiger Source ist, und alles unübersichtlicher gestaltet.

"Jedes Ding hat drei Seiten, eine positive, eine negative und eine komische." (Karl Valentin)

Z
43 Beiträge seit 2006
vor 17 Jahren
Massenreplik

@frisch

Dein Beispiel ist mir auch völlig unlogisch, wer so eine Abfrage erstellt sollte sich imho nochmal überlegen, ob er wirklich Programmierer werden will/kann.

Wenn das deine einzige Sorge ist, kann ich dich beruhigen: Ich bin seit fast 20 Jahren im Geschäft. Ich habe also quasi die Anfänge des OOP miterlebt und arbeite seit fast 5 Jahren ausschließlich mit meinem Lieblingsspielzeug ".NET". Allerdings, das muss ich wohl gestehen, "programmiere" ich nur noch selten. Zu wenig Zeit. Mein Job ist Projektmanagement und Qualitätssicherung. ... Und was man da erlebt, lässt einen frühzeitig altern. 😉

Wer bei boolschen Variablen trotzdem noch == true benutzt kann genauso gut

if((myIntVar == 5) == true) {  
}  

schreiben.

Sicher "kann" man das. Aber erhöht es auch die Lesbarkeit, frisch? Oder fällt es nicht vielmehr in die Kategorie "Nicht alles was hinkt, ist auch ein Vergleich"?

Wie wäre es mit


if (myIntVar == 5) {;}
// entspricht: if (myBoolVar == true) {;}

// vs. 

if((myIntVar == 5) == true) {;}

// 
// und
// 

if (myIntVar != 5) {;}
// entspricht: if (myBoolVar == false) {;}

// vs.

if (!(myIntVar == 5)) {;}

Ich habe 2 Jahre lang mit "== true" gearbeitet, bis mich jemand in die if-Abfrage richtig eingewiesen hat und was im Kopf der if-Abfrage eigentlich passiert.

Würdest du mich bitte aufklären, was im Kopf der if-Abfrage eigentlich passiert?

(War vorher auf einer Informatikschule

Beeindruckend... 😁

@Thomas B

Zero du schreibst, dass du bei deinen Jungs darauf bestehst, dass sie ein "+ 0" schreiben, aber wann sollte man denn +0 schreiben, kannst du da ein konkretes Beispiel geben?

Ad hoc? Ehrlich gesagt: kein konkretes (Und das, obwohl ich eben rasch durch die aktuellen Leistungen meiner Leute gewühlt habe. 😉). Ich kann aber eines konstruieren, wenn es dir reicht. (Offensichtlich haben einige hier ein arges Problem mit analytischer Betrachtung, ich hoffe, du gehörst nicht dazu.)


int x = 5;
for (int i= 0;i<=10;i++) {
  y += x;
  x--;
} 

Natürlich könnte man hier mit Hilfe einer - mehr oder minder - komplexen Abfrage verhindern, "0" zu addieren. Jedoch ginge der Sinn verloren: Die Lesbarkeit würde dramatisch vermindert werden, weil der Autor verlangen würde, dass der Leser begreift, warum er hier die "0", die durchaus einen "sinnlosen" und überflüssigen Durchlauf erzeugt, da gebe ich herbivore absolut Recht, ausgrenzt. Das Beispiel müsste also - korrekterweise - erweitert werden, wobei allerdings der Schwierigkeitsgrad und damit die Fehlerwahrscheinlichkeit auf allen Seiten, also beim Autor, beim Lektor und beim Leser, dramatisch ansteigt:


int x = 5;
for (int i= 0;i<=10;i++) {
  if(x!=0) 
   y += x;
  x--;
} 

@herbivore

... verstehe nicht, was du mit einem Beispiel wie [Beispiel] zeigen willst, außer das du damit genau die von mir bemängelten Tatutologien benutzt ...

Abgesehen davon, dass du entweder das falsche Beispiel kopiert hast oder den Begriff "Tautologie" missinterpretierst, ist dies ein abstrakt-analytisches Exempel für komplexen Quellcode. Dabei wäre es egal, ob ich hunderte Zeilen Quellcode hineinkopiert hätte, oder ob ich ein einzelnes statement bis zur Unkenntlichkeit verklausuliere. Das Resultat ist das Gleiche: Das Lesen von Quellcode ist einfach; das VERSTEHEN hingegen eine ganz andere Sache. Erst recht, wenn man das Zeug nicht selbst - oder schon in grauer Vorzeit - geschrieben hat.

Ich habe keine Ahnung, wie es bei euch gehandhabt wird, bei allen Unternehmen, für die ich arbeite, liegt die Messmarke bei Qualität des Quellcodes und Geschwindigkeit in der Entwicklung. Immer mit dem Augenmerk auf Wiederverwendbarkeit. Demzufolge ergibt sich auch die Notwendigkeit, lesbaren Code zu produzieren. Im Idealfall so lesbar, dass die änderungswürdigen Stellen in kürzester Zeit ins Auge springen.

Und da ich - aus eigener, leidiger Erfahrung - weiß, dass du deinen Community-Mitgliedern nur die halbe Wahrheit erzählst und dir damit anmaßt (vgl. "Anfängerfehler"), über ihre Zukunft ein ultimatives Urteil zu fällen, habe ich dich darauf hingewiesen, dass du zwar durchaus nicht völlig, aber doch quasi "zu 50%" falsch liegst.

Diese Klausel ("==true/==false") ist nicht nur erlaubt; sie wird sogar zwangsweise vom Compiler erzeugt, wenn du sie weglässt. (Ebenso, wie die Standardeigenschaft im VB zwangsweise hinzugefügt wird, wenn die Codiersau sie weglässt.) Das Resultat ist also einfach nur unübersichtlicherer Quellcode. 😉


// Quellcode:
private void Test()
{
	bool test= true;
	if (test) {;}
	if (test == true){;}
}

// PE-Code:
.method private hidebysig instance void  Test() cil managed
{
  // Code size       24 (0x18)
  .maxstack  2
  .locals init ([0] bool test,
           [1] bool CS$4$0000)
  IL_0000:  nop
  IL_0001:  ldc.i4.1
  IL_0002:  stloc.0
  IL_0003:  ldloc.0
  IL_0004:  ldc.i4.0
  IL_0005:  ceq
  IL_0007:  stloc.1
  IL_0008:  ldloc.1
  IL_0009:  brtrue.s   IL_000d
  IL_000b:  nop
  IL_000c:  nop
  IL_000d:  ldloc.0
  IL_000e:  ldc.i4.0
  IL_000f:  ceq
  IL_0011:  stloc.1
  IL_0012:  ldloc.1
  IL_0013:  brtrue.s   IL_0017
  IL_0015:  nop
  IL_0016:  nop
  IL_0017:  ret
} 

Und? Schon einen Unterschied gefunden, herbivore?

Am Ende stehen wir also vor der Frage: "Lässt du sie aus Faulheit weg oder machst du das, um deine Freunde zu beeindrucken?". Denn die Lesbarkeit eines vieltausend Zeilen langen Scripts erhöhst du nicht einmal im Ansatz, wenn du wahlfrei verkürzt.

Aus dem gleichen Grund ist übrigens die berühmt-berüchtigte Standardeigenschaft von VB nicht nach C# übernommen worden: Was in VB keinen Fehler erzeugt, macht in C# - mit voller Absicht 😉 - erhebliche Schwierigkeiten, denn eine derartige Verkürzung vermindert die Lesbarkeit dramatisch.

Die - thematisch identische - Debatte bricht übrigens immer wieder aus, wenn es um die Frage der Kommentare im Quellcode geht. "Keine Zeit zum Kommentieren" ist ein Killerargument, das zumindest eines garantiert: Sobald das QM hinter solchen Leuten steht, haben diese schon bald seeeeeehr viel Zeit, nachzuholen, wozu sie angeblich keine Zeit hatten...
Und du willst dir doch wohl nicht ernsthaft anmaßen, in diesem Kontext Gott spielen zu wollen, oder?!

2.082 Beiträge seit 2005
vor 17 Jahren

Würdest du mich bitte aufklären, was im Kopf der if-Abfrage eigentlich passiert? Es wird ein Vergleich gemacht, wenn dieser Vergleich wahr ergibt, wird der Inhalt des Vergleichs durchgeführt.

Richtig?

Ich bin seit fast 20 Jahren im Geschäft. Ahja, meine Kollegen warnen mich vor solchen Leuten... Ich sag jetzt mal nicht warum 😁

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

Z
43 Beiträge seit 2006
vor 17 Jahren
Du Schelm. :)

Es wird ein Vergleich gemacht, wenn dieser Vergleich wahr ergibt, wird der Inhalt des Vergleichs durchgeführt.

Na sowas. Dann habe ich gleich noch eine Frage: Wenn ein _Vergleich _gemacht wird, womit wird denn verglichen, frisch?

S
8.746 Beiträge seit 2005
vor 17 Jahren

Original von zero
Diese Klausel ("==true/==false") ist nicht nur erlaubt; sie wird sogar zwangsweise vom Compiler erzeugt, wenn du sie weglässt. (Ebenso, wie die Standardeigenschaft im VB zwangsweise hinzugefügt wird, wenn die Codiersau sie weglässt.) Das Resultat ist also einfach nur unübersichtlicherer Quellcode. 😉

Die Argumentation kann ich nicht nachvollziehen. " == true" ist Quellcode, das andere MSIL. Die Tatsache, dass auf MSIL-Ebene das Pendant zu "== true" generiert wird, sagt überhaupt nichts über die Verständlichkeit des Quell-Codes aus.

90% aller Bedingungen bestehen nur aus einem Ausdruck und warum if(a == true) lesbarer sein soll als if(a) leuchtet mir nicht ein. Für mich ist genau das Gegenteil richtig.

Aber vielleicht lieferst du uns ja noch ein einleuchtendes Beispiel jenseits völlig akademischer Klammerorgien und Schachtelungen bedingter Ausrücke von der Tiefe des Mariannengrabens.

2.082 Beiträge seit 2005
vor 17 Jahren

Pfft...

Wenn ein Vergleich gemacht wird, womit wird denn verglichen, frisch? Eingangsvariable 1 mit Eingangsvariable 2 = Ergebnis. Das Ergebnis ergibt sich aus den beiden Variablen, je nachdem welcher Operator verwendet wird.

Anders ausgedrückt:
Im if-Kopf steht eine Bedingung, wenn diese Bedingung zutrifft, wird die Anweisung im Block ausgeführt.

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren

Hallo zero,

"Lässt du sie aus Faulheit weg oder machst du das, um deine Freunde zu beeindrucken?"

immerhin schon mal 100 Gummipunkte für Polemik. Das ist so ungefähr auf der Ebene, wenn ich fragen würde, ob bei dir dein Nick Programm ist. 🙂

Aber um mal inhaltlich zu werden, weil Polemik für mich immer ein Zeichen ist, dass man auf der inhaltlichen Ebene nicht die passenden Argumente hat.

Dein CIL-Beispiel stützt gerade meine These, weil das == true wegoptimiert wird, es ist nämlich kein Gleichheitsoperator und keine Konstante true zu finden, sondern nur die Vergleichsoperation brtrue.s, die entscheidet, ob der boolsche Ausdruck wahr (ich schreibe extra wahr und nicht true) ist.

Wenn ein Vergleich gemacht wird, womit wird denn verglichen, frisch?

Es wird eben nicht auf == true verglichen, sondern ob der boolsche Ausdruck wahr ist. Das ist ja genau der Verständnisunterschied, der meiner Argumentation zu Grunde liegt.

Abgesehen davon, dass du entweder das falsche Beispiel kopiert hast oder den Begriff "Tautologie" missinterpretierst,

Ich habe das Beispiel kopiert, dass ich kopieren wollte und das ich als das richtige ansehe, um meinen Gedanken zu untermauern. Der Begriff Tatuologie hat mehrere Bedeutungen (in der Logik steht er für eine Aussage, die immer wahr ist). true ist also eine Tautologie. Ich meinte den Begriff hier aber in dem Sinne, einer überflüssigen/redundanten Information, weil man eben == true weglassen kann und sollte.

ist dies ein abstrakt-analytisches Exempel für komplexen Quellcode.

Es ist in meinen Augen ein Besispiel für künstlich aufgeblähten, redundaten und damit tautologischen Quellcode, der durch seine Unübersichtlichkeit meine Meinung stützt, dass unnötige Tautologien zum Nutzen der Lesbarkeit weggelassen werden sollten.

Über Lesbarkeit kann man aber streiten und du bist da wohl eben gegenteiliger Auffassung.

Mein Hauptargument liegt aber, in dem Verständnis, was eine boolsche Variable bzw. eine boolsche Bedingung ist. Das habe ich ja in der FAQ auch schon ausgebreitet.

Noch zu deinem + 0 Beispiel. Das ist für mich ein weiteres Beispiel für eine völlig am Ziel vorbeigehende Argumentation. Wir reden ja über == true, also den Gleichheitsvergleich mit einem Literal, genauso wie + 0 eine Addition mit einem Literals wäre. In deinem Beispiel lässt du dich aber über die Addition mit einer Variablen aus, die in machen Fällen den Wert Null annehmen kann. Das eine hat mit dem anderen überhaupt nichts zu tun.

herbivore

Z
43 Beiträge seit 2006
vor 17 Jahren
*lol

Zumindest im einzigen insistierten Punkt sind wir uns offensichtlich endlich einig.

Über Lesbarkeit kann man aber streiten und du bist da wohl eben gegenteiliger Auffassung.

Genau das war mein Eingangsstatement. Und genau das war meine Aussage während der gesamten Debatte. Die Behauptung "Anfängerfehler" ist demzufolge - bei höflichster Auslegung - bestenfalls die halbe Wahrheit. Richtiger wäre, dass es sich dabei um eine ABSOLUT SUBJEKTIVEN KRITERIEN UNTERLIEGENDE Auslegung handelt, über die jeder seinen Projektbedingungen entsprechend entscheiden muss und kann. Und das solltest du, wenn du dich wirklich deinen Community-Mitgliedern verpflichtet fühlst, zukünftig berücksichtigen.

Schade nur, dass es so lange dauerte...

Anyhow, danke an alle Diskussionsteilnehmer für die interessanten Einsichten in ihre Meinungen.

347 Beiträge seit 2006
vor 17 Jahren

Geht es nur mir so, oder haben noch andere gerade Wostok 1 vor dem geistigen Auge.
An Board Gagarin und Ptolemäus: Selbst nachdem sie die Erde einmal umrundet haben, will Ptolemäus immer noch nicht einsehen, dass die Erde keine Scheibe ist.

Traurig sowas...

2.082 Beiträge seit 2005
vor 17 Jahren

Was jetzt is meine Erkärung für if soweit richtig oder nicht? Ich möchte ja schließlich nicht mein Leben lang als unsicherer Mensch was das angeht umherirren 😁

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren

Hallo zero,

Zumindest im einzigen insistierten Punkt sind wir uns offensichtlich endlich einig.

An dem Punkt sind wir uns einig, aber wir sind uns nicht einig, dass das der einzig intressierende Punkt ist.

Richtiger wäre, dass es sich dabei um eine ABSOLUT SUBJEKTIVEN KRITERIEN UNTERLIEGENDE Auslegung handelt, über die jeder seinen Projektbedingungen entsprechend entscheiden muss und kann.

Nein, das ist aus meiner Sicht unzutreffend.

Und das solltest du, wenn du dich wirklich deinen Community-Mitgliedern verpflichtet fühlst, zukünftig berücksichtigen.

Da wir bei der Voraussetzung nicht konform gehen, ist für mich die Schlussfolgerung auch falsch. Mal abgesehen von der unterschwelligen Unterstellung, die ich entscheiden zurückweise und abgesehen davon, dass es sich bei mycharp.de nicht um "meine" Community handelt. Ich bin weder Betreiber, noch Leiter der Community.

Gerade Anfänger brauchen vielfach eine klare Linie und klare Aussagen. Deshalb ist der Beitrag entsprechend formuliert. Und dazu stehe ich und darin sehe ich meine Verpflichtung.

herbivore

Z
43 Beiträge seit 2006
vor 17 Jahren
...und ich sag noch so "Hääääääääääää"?

Gerade Anfänger brauchen vielfach eine klare Linie und klare Aussagen.

Und das ist für dich Grund genug, ihnen deine Meinung aufzudiktieren und sie im Unklaren darüber zu lassen, dass es immer mehr Firmen gibt, die extremen Wert auf Wiederverwendbarkeit und Wartbarkeit legen? ... Statt der Schilderung der tatsächlichen Gegebenheiten (meinetwegen auch mit einer Empfehlung, auch wenn diese dafür sorgen würde, dass alle, die ihr folgen, in nur wenigen der Unternehmen, die mir geläufig sind, eine Anstellung finden würden) einfach nur ein subjektives Diktat? ... Interessant.

abgesehen davon, dass es sich bei mycharp.de nicht um "meine" Community handelt. Ich bin weder Betreiber, noch Leiter der Community.

Du bist Moderator dieses Forums, richtig? Damit bist du, ob es dir passt oder nicht, sowas wie ein Halbgott. GERADE für Anfänger.

Nein, das ist aus meiner Sicht unzutreffend.

herbivore belieben zu scherzen, oder in welche Kategorie soll ich die folgenden Aussagen einnorden?

Es wird eben nicht auf == true verglichen, sondern ob der boolsche Ausdruck wahr ist.

Mit anderen Worten: Es wird nicht auf 'true' verglichen, sondern auf 'wahr' geprüft. ... Ah ja...

(Paraphrase) Wir sind uns einig, dass es eine subjektive Frage der Lesbarkeit ist, aber es ist unzutreffend, dass es eine subjektive Auslegung der Projektbedingungen ist.

PS: Kann man hier den Autor in die Zitate aufnehmen?

Z
43 Beiträge seit 2006
vor 17 Jahren

@frisch

Was jetzt is meine Erkärung für if soweit richtig oder nicht?

Sorry, dich habe ich vergessen...

Eingangsvariable 1 mit Eingangsvariable 2 = Ergebnis. Das Ergebnis ergibt sich aus den beiden Variablen, ...

Okay, das habe ich verstanden, glaube ich. ... Allerdings frage ich mich, wo bei

if (x){;}

die Eingangsvariable 2 geblieben ist, wenn wir annehmen, dass x die Eingangsvariable 1 darstellt. ... Kannst du mir das bitte sagen?

89 Beiträge seit 2006
vor 17 Jahren

if (a > 1000)
{
  fUeberlauf = true;
}
else 
{
  fUeberlauf = false;
}

if (someThingNastyHappend == false)
{
  blubbern();
}


fUeberlauf = a > 1000;
if (!someThingNastyHappend)
  blubbern();

Anfaengerfehler wuerde ich das auch nicht nennen, und deshalb den Titel aendern. Ich halte erstere Variante uebersichtlicher, und benutze auch die == false schreibweise, da sie mehr ins Auge faellt.

Dazu koennte auch locker noch gesagt werden, Anfaengerfehler sind brackets vor einzeiligen Statements => nichts verstanden, oder sind brackets aus uebersichtsgruenden vorhanden? Wobei ich die brackets auch weglasse.

just my 2 cents

347 Beiträge seit 2006
vor 17 Jahren

Original von zero
dass es immer mehr Firmen gibt, die extremen Wert auf Wiederverwendbarkeit und Wartbarkeit legen?

Und wenn du jetzt auch noch Lesbarkeit dazu packst hast du mich komplett verloren.
C# mag einiges sein, aber wenn es um Lesbarkeit geht, dürfte C# ein Witz gegenüber Pascal sein. C# ist schnell zu tippen, right. Aber lesbar und wartbar? 🤔

btw: Ich habe absolut kein Problem damit C# lesen zu können, aber als wirklich hübsch und lesbar kann ich C# nun wirklich nicht bezeichnen. 😉

2.082 Beiträge seit 2005
vor 17 Jahren

die Eingangsvariable 2 geblieben ist, wenn wir annehmen, dass x die Eingangsvariable 1 darstellt. ... Kannst du mir das bitte sagen? x ist in diesem Fall gleich das Ergebnis.

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren

Hallo zero,

meinetwegen auch mit einer Empfehlung, auch wenn diese dafür sorgen würde, dass alle, die ihr folgen, in nur wenigen der Unternehmen, die mir geläufig sind, eine Anstellung finden würden

Ist nicht dein Ernst, oder? Also mit solchen Aussagen gibt du dich m.E. der Lächerlichkeit preis. Damit sagst ja, dass im Bewerbungsgespräch die Frage gestellt würde, ob der Bewerber == true schreiben würde oder nicht und wenn er auf die zugestandermaßene Geschmacksfrage "falsch" antwortet, nicht eingestellt werden würde. Sag mal, merkst du eigentlich noch, was du da für eine polemischen Quasch schreibst?

Mit anderen Worten: Es wird nicht auf 'true' verglichen, sondern auf 'wahr' geprüft. ... Ah ja...

Ganz genau! Ist durchaus üblich, diese Ebene in der Logik zu trennen. Das wird aber einem Anfänger nicht unmittelbar einleuchten. Deshalb gibt es eine klare Aussage. Bei der Aussage handelt es sich um eine Ausage, die von mir nur formuliert wurde, die aber eben breite Anerkennung in der Informatikwelt findet, wie auch der Prozentsatz der jeweiligen Antworten hier in diesem Thread zeigen.

Damit bist du, ob es dir passt oder nicht, sowas wie ein Halbgott.

Wenn du das so möchtest, bitte sehr. Und ich nutze die Macht, um Anfängern Orientierung zu geben. Dazu stehe ich.

Kann man hier den Autor in die Zitate aufnehmen?

Ja, es ist ja nur BBCode. Automatisch geht das aber nur für den gesamten Text (Beitrag zitieren).

Hallo purestrain,

Anfaengerfehler wuerde ich das auch nicht nennen

musst du auch nicht. 🙂 Da ich einfach viele Leute kenne, die mit zunehmender Erfahrung von der oberen zur unteren Schreibweise wechseln, finde ich es schon einen Anfängerfehler.

Dazu koennte auch locker noch gesagt werden, Anfaengerfehler sind brackets vor einzeiligen Statements => nichts verstanden,

Ich weiß sehr genau, dass man die Klammern weglassen kann, schreibe sie aber absichtlich immer aus Gründen der Les- und Wartbarkeit. Bei den Klammen ist es aber m.E. reine Geschmackssache, wogegen bei den boolschen Variablen die Konzeptfrage dazukommt.

herbivore

T
223 Beiträge seit 2006
vor 17 Jahren

@zero
Ich habe dein Beispiel zur 0 Addition verstanden. Eine Addition mit 0 ist unnötig, passiert aber in der Schleife. Um den Code zu optimieren könnte man die 0 als Sonderfall behandeln und die Schleife damit ein mal weniger laufen lassen. Diese Optimierung würde aber den Code aufblähen und weniger lesbar machen.

@purestrain
Ich lasse Brackets bei einzeiligen Code auch weg, früher habe ich diese gesetzt, wusste es da aber auch nicht besser. Ich finde es ohne Brackets übersichtlicher, einfach aus dem Grund, dass es kompakter ist.


if (x == x)
     blubbern();

vs


if (x == x)
{
     blubbern();
}

und


if (x == x)
     blubbern();
else
     bibbern();

vs


if (x == x)
{
     blubbern();
}
else
{
     bibbern();
}

Als Fehler würde ich soetwas nicht bezeichnen, da das Ergebnis das selbe ist (wie auch bei der Hauptproblematik hier).

Gruß Thomas

2.082 Beiträge seit 2005
vor 17 Jahren

Ich stimme Thomas B was die Brackets angeht teilweise zu. Manchmal ist es übersichtlicher und manchmal nicht.

Ich mache die Brackets bei einzelnen Zeilen selten, halte es dennoch in bestimmten Fällen für nötig.

Fragt jetzt bitte nicht 'wann' ich nun Brackets setzte und wann nicht. Ich gehe bei der Sache nach Gefühl, je nachdem was meiner Meinung nach optisch überschaubarer ist.

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

89 Beiträge seit 2006
vor 17 Jahren

Original von frisch
Ich stimme Thomas B was die Brackets angeht teilweise zu. Manchmal ist es übersichtlicher und manchmal nicht.

Ich mache die Brackets bei einzelnen Zeilen selten, halte es dennoch in bestimmten Fällen für nötig.

Fragt jetzt bitte nicht 'wann' ich nun Brackets setzte und wann nicht. Ich gehe bei der Sache nach Gefühl, je nachdem was meiner Meinung nach optisch überschaubarer ist.

Und genauso sollet es auch jeder bei xx==false handhaben, ohne das als Fehler anzumerken. Am einfachsten wäre es getan, den ursprüngliche Thread von Herbivore abzuändern, und in eine Art "Aufklärung" abzuwandeln. Warum auch immer noch hier diskutiert wird, ist mir schleierhaft, aber dennoch unterhaltsam.

Wobei mich das auch nicht weiter stört. 😉

2.082 Beiträge seit 2005
vor 17 Jahren

Warum auch immer noch hier diskutiert wird Aus dem gleichen Grund warum auch über andere Themen schon diskutiert wurde:

Es ist sinnlos aber wir brauchen etwas um uns darüber aufregen zu können 😁

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

5.941 Beiträge seit 2005
vor 17 Jahren

Hallo Jungs

Original von frisch
Was jetzt is meine Erkärung für if soweit richtig oder nicht? Ich möchte ja schließlich nicht mein Leben lang als unsicherer Mensch was das angeht umherirren 😄

Man kann das doch auch so umschreiben, das unser zero zufrieden ist:

if(true) {;}                       // Kein Vergleich, sondern eine reine Auswertung
if(test == true) {;}           // Ein Vergleich
if((test=true) == false) {} // Ein Ausdruck der zuerst (teil)ausgewertet wird und danach ein Vergleich anfällt

Man darf nicht von einem Vergleich augehen, sondern vom auswerten des Ausdruckes - der Vergleiche enthalten kann.

Einfach gesagt, es wird einfach der Ausdruck zwischen "if(" und ")" ausgewertet.

Gruss Peter

--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

1.373 Beiträge seit 2004
vor 17 Jahren

Ich bin generell der Meinung, dass man dem Leser von Quellcode durchaus zeigen kann, dass man als Programmierer zu einer elitären Rasse intellektueller Übermenschen gehört. Ich schreibe deshalb immer in folgendem Stil:


bool dontDelete;
..
if(dontDelete != false) {
...
}

Kommt immer gut beim Code-Review.

Hint: wer hier Ironie wittert, liegt richtig.
*Solange sich der Schreiber und die potenziellen Leser von Code über gewisse Konventionen einig sind und auch konsequent(!) beibehalten, ist doch alles in Butter - in der Regel zumeist.

*Ich persönlich(!) schreibe auch kein "== true", dafür aber konsequent geschweifte Klammern, auch bei einzeiligen Anweisungsblöcken.

*Besseren Code schreiben? Lesen: Code Complete

Grüße,
Andre

T
512 Beiträge seit 2006
vor 17 Jahren

Solche Diskussionen sind mir am liebsten.

Am Besten schließen wir da gleich noch folgende Diskussion an:

Tabs vs. Leerzeichen: Was produziert den lesbareren Code?

Wenn man die Energie die für solchen Quatsch draufgeht in echte Probleme stecken würde, wüssten wir vieleicht schon ob P != NP

PS bin ich der Einzige der dieses Beispiel mit +0 so verstanden hat, dass da im Code wirklich +0 steht und nicht zufällig irgendeine Variable den Wert 0 hat?

Ich meine das Beispiel was zero da gebracht hat ist doch eher analog zu (a == b), falls b mal zufällig true ist. Das was ich erwartet habe wäre eher ein Beispiel was analog zu (a == true) ist.

PPS ich bin dafür Leerzeilen mit NoOp() zu füllen um auch deutlich zu machen, dass da nix passiert. Der Compiler macht das ja auch manchmal. 😉

e.f.q.

Aus Falschem folgt Beliebiges

2.082 Beiträge seit 2005
vor 17 Jahren

bin ich der Einzige der dieses Beispiel mit +0 so verstanden hat, dass da im Code wirklich +0 steht Nein bist du nicht.

Denn 1+0+0+0+0 = 1 😁

Tabs vs. Leerzeichen Das macht mein VS selbst 😉

Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de

1.373 Beiträge seit 2004
vor 17 Jahren

Original von Traumzauberbaum
P != NP

Respektive, ob (P != NP) == true; oder war es (P == NP) == false? Vielleicht sollten wir drüber abstimmen? 😁

Grüße,
Andre

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren

Hallo Traumzauberbaum,

PS bin ich der Einzige der dieses Beispiel mit +0 so verstanden hat, dass da im Code wirklich +0 steht und nicht zufällig irgendeine Variable den Wert 0 hat?

nein, bist du nicht. 🙂 Ich schieb ja oben schon:

Noch zu deinem + 0 Beispiel. Das ist für mich ein weiteres Beispiel für eine völlig am Ziel vorbeigehende Argumentation. Wir reden ja über == true, also den Gleichheitsvergleich mit einem Literal, genauso wie + 0 eine Addition mit einem Literals wäre. In deinem Beispiel lässt du dich aber über die Addition mit einer Variablen aus, die in machen Fällen den Wert Null annehmen kann. Das eine hat mit dem anderen überhaupt nichts zu tun.

herbivore

A
3 Beiträge seit 2006
vor 17 Jahren

moin !!

Es ist schon interessant, wie viele Leute um Selbstverständlichkeiten, wie die Wiederverwendbarkeit von Code debattieren. Über dieses Thema gibt es Doch nichts zu dikutieren. CODE MUSS LESBAR SEIN.

@zero

liegt die Messmarke bei Qualität des Quellcodes und Geschwindigkeit in der Entwicklung. Immer mit dem Augenmerk auf Wiederverwendbarkeit.

Hier kann ich dir nur absolut zustimmen. Bei der Mitarbeiterfluktuation innerhalb von größeren Projekten in der heutigen Zeit, gewinnt die Qualitätssicherung einen immer größeren Stellenwert. Firmen haben es satt, bei einem Austausch einzelner, oder dem Hinzufügen von Leuten zum Projekt, diesen Einarbeitungszeit wegen "komprimierter Schreibweise" geben zu müssen.

@herbivore (and supporters)

Euch unterstelle ich, noch nie an wirklich größeren Projekten gearbeitet zu haben. Ihr seid nicht in der Lage zu erkennen, dass die Idee der OOP war und ist, die Komplexität des Quellcodes zu verringern und die Übersichtlichkeit zu erhöhen (usability). Wenn mann also eine Sache einfach und nach dem Prinzip DISAS umsetzen kann,



bool b = true;
int i = 0;

if (b == true) i++; // bzw. (b == false)


dann werden nur Leute, die von Anfängern, die laut eigener Aussage auch noch "dazu stehen", als Anfänger bezeichnet werden, sich zu einem Bockmist wie diesem verleiten lassen.



bool b = true;
int i = 0;

if (b) i++; // bzw. (!b)


Sag mal, merkst du eigentlich noch, was du da für eine polemischen Quasch schreibst?

Dieser von Zero angesprochene und von dir als

polemischer Quasch bezeichnete Sachverhalt trifft zu. Nur zu deiner Information (scheinbar arbeitest du nicht in wechselnden Projektgruppen). Firmen lassen sich Codebeispiele deiner Arbeit zeigen und dich welche anfertigen bevor sie dich einstellen. Die Übersichtlichkeit von Code ist dann ein entscheidendes Einstellungskriterium. Es ist eben KEINE Geschmackssache. Ein " (b == true) " fällt mir zwischen 6000 Zeilen Code sicher eher auf als ein " (b) ", oder nicht (Syntaxhighlighting)? Das hat mit "Anfängern" nur in so weit zu tun, als das diese ihren Code bis zur Unkenntlichkeit verstümmeln.

Gruß allyourbase

A
3 Beiträge seit 2006
vor 17 Jahren

Nachtrag

Frage
Warum würden wir uns hier nicht streiten, wenn das ein Java-Forum wäre?

allyourbase

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 17 Jahren

Hallo allyourbase aka zero,

ah, da hat sich jemand unter einem anderen Nick neu registriert. Über die Gründe kann ich nur spekulieren. Wahrscheinlich, um die vermeindliche bzw. vorgebliche Anhängerschaft zu mehren. Auf jeden Fall ein alter, aber nicht besonders feiner Trick.

Da du im Wesentlichen nur wiederholst, was du schon weiter oben geschrieben hast, siehe bitte meine Argumente oben zur Widerlegung.

Leider strotz dein Beitrag wieder vor Unterstellungen, die alle unzutreffend sind. So habe ich vor knapp 25 Jahren angefangen, erfolgreich Informatik zu studieren und arbeite seit ca. 20 Jahren in wechselnden Projektgruppen mit unterschiedlichen Projektgrößen von bis zu ca. 50 Mitarbeitern. Als Anfänger würde ich mich also nicht bezeichnen. Mit den Konzpten von OO habe ich nicht nur auseinander gesetzt, sondern sie auch gelehrt. Ich weiß, dass muss jetzt schlimm für dich sein, weil vor deinem geistigen Auge bestimmt die Scharen von potentiellen Mitarbeitern erscheinen, die ich für immer verdorben habe. 🙂

Ich habe auch nichts gegen deine Ansicht, dass if (b == true) lesbarer ist. Aber bitte resprektiere, dass ich das 1. anderes sehe (ich finde if (b) lesbarer) und 2. aus prinzipiellen, theoretisch fundierten Überlegungen dazu komme, das if (b) vorzuziehen ist.

herbivore

Q
214 Beiträge seit 2006
vor 17 Jahren

Hallo,
nochmal was zur Lesbarkeit, hab heute selbst ein kleines Beispiel gefunden, wo == false evt. mehr Sinn macht, also !.
Und zwar wenn man viel 'casten' muss, ist so ein ! sehr unübersichtlich.

Bsp:
if(
((ClassForExampe)e.Item).SubItem.IsFolder && !((ClassForExampe)e.Item).SubItem.IsDisk
)

if(
((ClassForExampe)e.Item).SubItem.IsFolder && ((ClassForExampe)e.Item).SubItem.IsDisk == false
)

Das == false sieht man beim der 2. Anweisung sofort, das ! kann man aber bei Bsp1 recht schnell überlesen.

Des wegen sollten man == false nicht pauschal als schlechten Stile verurteilen, wobei ich aber selber meistens ! verwende.

A
3 Beiträge seit 2006
vor 17 Jahren

Hallo herbivore,

ich muss dich enttäuschen und kann deine Unterstellung nur zurückweisen. Nur weil ich massiv Zero unterstütze, heißt das nicht, dass ich es bin. Ich denke das würde den Intellekt der hier postenden beleidigen. Oder sind im Umkehrschluss jetzt alle Leute die deiner Meinung sind deine Accounts? Ich wäre dir also dankbar, wenn du mich als Moderator bitte mit meinem eigenen Accountnamen ansprechen würdest. Danke. Was Unterstellungen angeht liegst du damit also auch nicht schlecht im Rennen.

Mit den Konzpten von OO habe ich nicht nur auseinander gesetzt, sondern sie auch gelehrt.

Gott bewahre uns. SRY aber du kennst nicht mal den Unterschied zwischen "new" und "override" wie jeder im Threat Ausblenden vs. Override verstehen sehen kann.

Also new geht immer, ist aber manchmal falsch. Override ist immer richtig, geht aber nur manchmal.

Also ohne Kommentar.

Ach und, ich traue mich kaum es zu sagen (nicht dass ich auch noch Qwald bin) ist das ein schönes Beispiel Qwald. Wenn es also übersichtlicher ist (b == true) zu schreiben,

dass if (b == true) lesbarer ist.

warum sollte ich dann als Anfänger gelten, wenn ich es tue, denn darum ging es Zero doch oder?

Und welche

theoretisch fundierten Überlegungen

bringen dich bitte zu der Annahme

das if (b) vorzuziehen ist. ?

allyourbase

184 Beiträge seit 2005
vor 17 Jahren

Hab das Thema jetzt nur etwas überflogen, da ja fast alles schon min 2mal gesagt wurde...

Ich persönlich stimme dem Argument zu, dass Code vor allem lesbar sein sollte, aber finde die Schreibweise (b == false) etc. nicht wirklich sinnvoll. Wie das jeder einzelne macht ist IMAO sowas von egal - nur bemerkt man eben bei Anfängern oft, dass sie die Grundlagen bezüglich boolscher Operationen nicht verstanden haben, bzw. gar nicht wissen, dass sie sie auch in Form von (!Ausdruck) anwenden können.
Daher finde ich den Beitrag von herbivore absolut in Ordnung und schließe mich seiner Meinung an.

Und mal ehrlich - ein ! übersieht man eher?? Wenn man beim debuggen irgendetwas "übersieht" hat derjenige meiner Ansicht nach irgendwas nich so richtig verstanden 😁
Ne, mal ehrlich - das klingt ja theoretisch ganz nett, aber ich hab in meinem Leben noch nie ewig rumsuchen müssen und am Ende festgestellt dass ich ein (!) o.ä. übersehen habe.

Das hört sich für mich so an als ob ein Semikolon besser durch ein "Ausruck-bitte-hier-beenden" ersetzt werden sollte, da man es sonst ja übersehen könnte 😉

Summa summarum: wenn jemand persönlich die Schreibweise if (a == true) "ästhetischer" findet kann er es ja gerne machen, im beruflichen (team) umfeld wird man damit denke ich bei vielen nicht so gut ankommen.

Gruß
DCoder

P.S.: Code sollte eh nicht zu stark lesbar sein, da sonst Programmieren zu einfach scheint 😉

T
512 Beiträge seit 2006
vor 17 Jahren

Original von allyourbase
Euch unterstelle ich, noch nie an wirklich größeren Projekten gearbeitet zu haben.

Das unterstelle ich eher dir. In nem Projekt gibts ganz einfach Vorlagen dafür wie man Variablen benennt, wie man Methoden benennt, wie man Klassen benennt, wie man Code formatiert, wie man Code dokumentiert und falls es denjenigen wichtig genug ist auch wie man Abfragen aufbaut. Daran kann sich jeder halbwegs fähige Programmierer halten egal was für Richtlinien er davor eingehalten hat.

Da interessiert es kein Schwein was für Code in den Bewerbungsgesprächen/-unterlagen ist. Wenn man jemanden als fähig genug ansieht ihn als Programmierer einzustellen, dann sollte ein Kriterium dafür wohl sein demjenigen genug Intelligenz zuzutrauen solche primitiven Sachen zu meistern.

Deswegen ist das einfach ein absolut schwachsinniges Argument. Das ist so wie beim Bewerbungsgespräch zu sagen "So sie tragen einen schwarzen Anzug mit roter Krawatte. Bei uns werden aber blaue Krawatten benötigt, deswegen sind sie leider raus". Absolut lächerlich und ich weiß nicht für wie blöd du uns hältst, erstens so einen Schwachsinn zu schlucken und zweitens dir auch noch den gefakten Acount abzukaufen.

Ansonsten wünsch ich dir noch viel Erfolg mit deiner Engstirnigkeit. Ich wage mal zu behaupten, dass man von dir hier sonst nicht mehr viel hier sehen wird.

e.f.q.

Aus Falschem folgt Beliebiges

1.373 Beiträge seit 2004
vor 17 Jahren

Original von allyourbase
CODE MUSS LESBAR SEIN.

Stimme ich vollkommen zu. Ich kann lediglich das Gewicht, dass du einem "== true" beimisst, nicht ganz nachvollziehen. Ich persönlich bezweifle, dass ein "== true" die Lesbarkeit mehr erhöht als beispielsweise ordentlich benannte Variabelen oder weniger komplexer Code (in Hinsicht auf z.B. Schachtelung).

So würde dein Beispiel


bool b = true;
int i = 0;

if (b == true) i++; 

gegen ein


bool isOpen = true;
int openFileCount = 0;

if (isOpen) openFileCount++; 

in Punkto Lesbarkeit eindeutig verlieren. Letzteres kommt dabei sehr gut ohne "== true" aus. Anderes Beispiel - der vollkommen weltfremde Code von Zero:

bool o = ((((((((x == true) ? true : false) == true) ? true : false) == true) ? true : false) == true) ? true : false);

In diesem Ungetüm kann auch ein "== true" der Codequalität nicht mehr helfen.

Im Grunde genommen sind deine Absichten - lesbarer Code ist wichtig - ja gar nicht verkehrt und decken sich mit denen von herbivore, mir und anderen. Dass du jedem, der "== true" für redundant hält, allerdings jedwede Kompetenz absprichst, erscheint mir jedoch ziemlich anmaßend.

Grüße,
Andre

Z
43 Beiträge seit 2006
vor 17 Jahren
*lol, was ist denn hier los?

Paranoide Anfälle und bissige Polemik wohin das Auge blickt.

Da ich diese Diskussion mittlerweile für müßig halte - sie hat mich ausreichend über die verschiedenen Beteiligten gelehrt -, nur noch ein Wort zum "vollkommen weltfremden Code":

Lieber Andre, natürlich hätte ich hier auch ein "realistisches" Fragment posten können. Da wir aber über Lesbarkeit debattierten (Naja, einige jedenfalls. 😉) wäre der Haken jede Menge unsinnig verschwendeter Platz, weil alle irrelevanten Codeteile lediglich als "argumentativer Füllstoff" gedient hätten.

In Folge dieser - ich glaubte simplen - Überlegung gelangte ich zu dem Schluss, dass ein akademisches Beispiel es mindestens ebenso gut tun würde, ist doch Abstraktionsvermögen eine fundamentale Voraussetzung für jeden "Programmierer". (Dies gilt umso mehr als ich mehrfach explizit darauf hinwies, dass dieses Exempel synonym für ein "nicht-akademisches", praxisnahes Beispiel stünde, da der Komplexitätsgrad "praktischen Codes" weitaus niedriger, selbiger dafür aber vielzeiliger ist.)

... Eigentlich sollte es mich nicht erstaunen, wie darauf reagiert wurde, bin ich es doch, wie ich oben bereits beschrieb, aus eigener, leidiger Erfahrung gewöhnt, dass man nichts erwarten sollte, will man nicht enttäuscht werden. Dennoch: Auch ich bin nur ein Mensch - und in diesem Sinne stirbt auch meine Hoffnung zuletzt.

So verkommt es zur erschütternden Farce, wenn man - beispielhaft - lesen muss, dass es doch tatsächlich Leute gibt, die aus

"...meinetwegen auch mit einer Empfehlung, auch wenn diese dafür sorgen würde, dass alle, die ihr folgen, in nur wenigen der Unternehmen, die mir geläufig sind, eine Anstellung finden würden..."
(zero)

solche Dinge, wie

"Damit sagst ja, dass im Bewerbungsgespräch die Frage gestellt würde, ob der Bewerber == true schreiben würde oder nicht und wenn er auf die zugestandermaßene Geschmacksfrage "falsch" antwortet, nicht eingestellt werden würde."
(herbivore)

oder

"Das ist so wie beim Bewerbungsgespräch zu sagen 'So sie tragen einen schwarzen Anzug mit roter Krawatte. Bei uns werden aber blaue Krawatten benötigt, deswegen sind sie leider raus'."
(Traumzauberbaum) herauszulesen glauben müssen.

Die Quintessenz dieser - ebenso wilden wie haltlosen - Spekulationen kann daher nur lauten: Da ich beabsichtige, mich hier vorübergehend einzunisten, werde ich wohl meine Ansprüche dramatisch reduzieren müssen... ((Glosse: Ob du es glaubst oder nicht: Ich weiß jetzt schon, welche naiv-infantilen Reaktionen dieses statement hervorrufen wird. ... Menschen sind ja so leicht manipulierbar. 😉[/color])

Deine moderate Einstellung ("... deine Absichten - lesbarer Code ist wichtig - ja gar nicht verkehrt und decken sich mit denen von herbivore, mir und anderen.") ist also absolut ehrenwert und ich denke, ich habe sie wohl verstanden; sie deckt sich allerdings solange mitnichten mit der Realität (War auch bei dir der Wunsch Vater des Gedanken?), wie die These

Anfänger ist, wer == true / == false schreibt. aufrecht erhalten wird.

Angesichts der ausgeprägt paranoiden Tendenzen einiger Diskutanten würde ich - ungewöhnlicherweise - gern eine Grußformel verwenden, weiß aber nicht welche...

... Wie wäre es mit ... errrr ... h.a.n.d., AreBelongToUs? ... der andere Name gehört mir nämlich nicht und - obwohl ich durchaus zugebe, gelegentlich schizoide Symptome zu zeigen - es wäre Anmaßung, würde ich ihn mir aneignen. 😉

PS: Kleiner Seitenhieb - nein, ich will es mir nicht sparen 😉: Lieber herbivore, sobald du ansatzweise Erfahrung im Umgang mit Menschen gesammelt haben wirst, sollte es dir leicht fallen, die gewaltigen Stilbrüche zwischen den Statements der beiden "Verdächtigen" zu erkennen. Und du dürftest dann - kraft deiner dann vorhandenen Erfahrung - vermutlich auch wissen, dass derartige "Fakeversuche" mit astronomischem Aufwand verbunden sind. Ein Aufwand, den diese Debatte nicht einmal im Ansatz rechtfertigt(e). Doch, und das gestehe ich dir, dich ehrlich bewundernd, gern zu, zumindest bist du auch hier konsequent geblieben.