Beispiel von Trade:

Und meine Antwort darauf:


Hinweis: Ich meine hier nicht solche Codes wie in [Sammelthread] VB-Sprüche

Ich möchte auch die Gelegenheit nutzen, um dieses unsinnige Codeschnipsel zu analsyieren, welches ich hin und wieder sehe:

Da hier der ===-Operator verwendet wird, muss es sich um PHP oder JavaScript handeln. Ruby hat auch so einen Operator, aber Ruby hat eine andere Syntax. Da in Zeile 4 camelCase verwendet wird, handelt es sich eher um JavaScript, denn in PHP wird typischerweise snake_case verwendet.

Zeile 2:
Generell gilt: Das Vergleichen von Booleans mit True in einem If-Statement ist schlechter Stil. Man könnte hier argumentieren, dass der Inhalt des Blocks auch dann übersprungen werden soll, wenn etwas zurückgegeben wird, was kein Boolean ist (z.B. der String "1"), aber das wäre ebenfalls schlechter Stil dahingehend, dass sad doppeldeutige Werte zurückgibt.

Zeile 3:
In JavaScript kann kein Wert === true sein und gleichzeitig eine Eigenschaft stop besitzen. Bzw. anders gesagt: true hat keine Eigenschaft namens stop.
In PHP ist es möglich, zwei Funktionen aufzurufen, eine Stringverknüpfung auf den Ergebnissen durchzuführen, und das als Statement so stehen zu lassen. Wenn es also eine weitere Funktion namens stop gibt, ist dieser Code syntaktisch korrekt, ergibt aber trotzdem keinen Sinn.

Fazit: Dieses "Lebensmotto" sollte man als Programmierer meiden, da es den Eindruck vermittelt, dass man den Code bzw. die Sprache, in der der Code geschrieben ist, nicht versteht.

@Rinecamo

Da hab ich nicht dran gedacht.

ergibt aber trotzdem keinen Sinn

Ich mag es, dass man nur True als Antwort bekommen kann. Das ist genauso unsinnig wie die Frage "Schläfst Du schon?". Wenn nein: Nein als Antwort. Wenn ja: keine Antwort (TimeoutException vielleicht?).

Was ich aber noch interessanter finde: Man kann die Korrektheit eines Systems nicht alleine mit den Mitteln überprüfen, die dieses System bereitstellt.
Beispiel: Du kannst nicht die Batterie eines Multimeters mit dem Multimeter selbst abmessen.
Etwas abstrakter: Du kannst nicht mit den Werkzeugen, die die Mathematik bereitstellt, beweisen, dass Mathematik korrekt ist. Du kannst nur beweisen, dass Mathematik in sich konsistent ist.
Das selbe Prinzip kann man auch auf den Code übertragen:
Normalerweise ist True = False eine falsche Aussage. Wenn die Werkzeuge von VB aber inkonsistent zu den Werkezgen der Außenwelt sind, dann kannst Du das nicht ausschließlich mithilfe von VB-Werkzeugen beweisen:

Erkennst Du das Problem? Wenn das True-Literal richtig funktioniert, dann funktioniert alles wie erwartet. Aber angenommen True und False wären vertauscht (nur die Literale, nicht die Bedeutungen von "wahre" und "falsche Aussage"), dann wird "falsche Aussage" mit "falsche Aussage" verglichen, was gleich ist, was "wahre Aussage" ergibt. Man kann also nur prüfen, ob VB insich konsistent ist, nicht aber, ob es irgendwelchen Regeln entspricht, die wir von außen festlegen.

Edit:
In welcher Sprache ist Ausdruck++ ein gültiges Ziel für eine Zuweisung? Was soll da überhaupt passieren? Ausdruck + 1 zurückspeichern und direkt danach mit dem Ausdruck rechts vom = überschreiben?

https://blogs.msdn.microsoft.com/ericlippert/2011/02/03/curiouser-and-curiouser/ schrieb:

The second reason to avoid this is simply because it bakes the noodle of anyone who reads the code.