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?
Zitat
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.
Zitat
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.
Zitat
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,
Zitat
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.
Zitat
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.
@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).
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
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.
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 :D
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
- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
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:
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.
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.
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:
Zitat
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.
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
Zitat
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)
Zitat
Sag mal, merkst du eigentlich noch, was du da für eine polemischen Quasch schreibst?
Dieser von Zero angesprochene und von dir als
Zitat
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.
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.
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.
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.
Zitat
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.
Zitat
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,
Zitat
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?
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
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.
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:
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.
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
Zitat
"...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
Zitat
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.
lol ... mehr fällt mir zu dieser Diskussion ehrlich gesagt nicht mehr ein. Streitet Euch doch mal drum, ob man Variablen groß oder klein schreibt :-)
Also ehrlich, jeder wie er es mag. Bei uns in der Firma gibt es für diese spezielle Frage keine feste Richtlinie, manche schreiben == true, andere nicht. Ich selbst bin da völlig unvoreingenommen, lasse == true / false eigentlich immer weg, weil ich es aus C/C++ gewöhnt bin.
Ob darunter nun die Lesbarkeit leidet, kann ich nicht sagen. Ich selbst fühle mich eher irritiert wenn ich sowas wie == true lese.
Auf jeden Fall ist das kein "Anfängerfehler", sondern bestenfalls eine Vorliebe des jeweiligen Programmierers. Da die Formulierung "Anfängerfehler" von herbivore kommt, würde ich das Ganze aber nicht überbewerten. Ich glaube es gibt - vorsichtig ausgedrückt - seriösere Mitglieder dieser Community.
Ja aber wär doch mal ganz nett wenn dann sowas dasteht wie:
myStrBuilder.Appen(strVar1).Append(" und ").Append(strVar2).Append(" und ").Append(strVar3).Append(" und ")...... usw.
Imho sollte der Thread eh geschlossen werden. Alles ist ja wohl gesagt, was es zu sagen gibt und Sinn macht es jetzt auch keinen mehr darüber zu diskutieren!
Es ist toll jemand zu sein, der nichts von der persönlichen Meinung Anderer hält. - frisch-live.de
Irgendwie geht mir Diskussion zu sehr am Thema vorbei, es geht mittlerweile nicht mehr darum ob man == true schreibt oder nicht.
Es geht scheinbar nur noch darum sich gegenseitig die Kompetenz abzusagen.
Zitat
Wer '== true' benutzt, hat m.E. noch nicht vollständig verstanden, was eine boolsche Variable ist. Mit dieser direkte Aussage will ich niemanden kränken, sondern meine das rein sachlich.
Ich verstehe nich was man an der Aussage bemängeln kann, denn wer die boolesche Algebra kennt weiss nun einmal, dass x == true immer x ist.
ja auch ein Vergleich... Und wenn ich jetzt Zero's Empfehlung folgen würde müsste ich ja theoretisch
if((bIrgendwas==true)==true)
oder in einem anderen Fall
if((bIrgendwas==false)==true)
(==> ewig fortführbar) schreiben... oder sehe ich das jetzt völlig falsch.
Ich weiß, es ist ein übertriebenes Beispiel, aber es unterstützt herbivore's Aussage über den Unterschied zwischen 'true' und 'wahr'.
Also ich benutze true/false nur für Zuweisungen. Außerdem weiß man doch, dass ein if in seinem kopf letztendlich immer auf 'wahr' prüft... und wehr
if(bIrgendwas==true)
lesbarer findet als
if(bIrgendwas)
der nutzt '==true' meiner Meinung nach nur als eine Gedächtnisstütze, um sich daran zu erinnern wie ein if eigentlich funzt. :D. Und um damit auf die von Zero erwähnten Bewerbungsgespräche zu kommen.... wer will schon nen programmierer mit altzheimer...???
Ich für meinen Teil bestehe auf das == und Namen wie IsAktivated.... Für das Compailierte Programm macht es eh keinen Unterschied ob man es weglässt oder nicht. Ich denke es ist kein "Anfängerfehler", weil es das Programm nicht verändert und nicht unbrauchbar macht sondern nur die Syntax übersichltlicher darstellt.
Hier von einem "Fehler", sondern von der spezifischen Syntax eines Programmieres die Rede. Natürlich, ist es doppelt geschrieben.... aber kein Grund von einem Fehler zu sprechen...
Ich finde diese Duskussion etwas stupide
if erwartet einen boolnischen Wert, der Operator == vergleicht zwei boolnische Werte, true ist der Absolutwert für die Wahrheit.... == Argument entspricht der Warheit / Argument entspricht der Unwahrheit.....
Wenn es stimmt das es Unwahr ist...
Wenn es stimmt das es Nicht Wahr ist...
Zitat
Original von dN!3L
Hey, tolles Entertainment hier im Forum! Das hat doch was...
Zitat
Original von VizOne
Anderes Beispiel - der vollkommen weltfremde Code von Zero:
Das macht ebenfalls keinen Unterschied am Sorce, also: Warum schreibt ihr nicht so? Warum die Zeitauswändigen Zeilenvorschübe setzen...ist doch unnütze.....*ironie*
Aber wofür soll das gut sein? – Advanced Computing Systems Division von IBM, 1968, zum Microchip
