Wie erklärt man jemand eine If Abfrage?

Dizzy schrieb:

Was man aber allgemein sagen kann: ein else ist nie falsch, selbst wenn es unnötig ist.

meine Meinung

Code sollte lesbar sein.
Wenn du etwas in einer Zeile schreiben kannst anstatt in 5, dann ist das wesentlich einfacher zu erfassen.
Bei viel unnützem Code wird das Programm schnell unübersichtlich.

verstehe ich nicht. das war auch nicht die Frage.

Das sind 2 verschiedene Auffassungen von "falsch" - also da muss erstmal definiert werden, was mit richtig/falsch gemeint ist.
Die erste Auffassung definiert als "richtig", wenn der Code macht wasser soll - egal ob lesbar, umständlich, effizient, resourcenschonend oder whatever.

Die zweite Auffassung ist strenger: Wenn du 2 Möglichkeiten hast, und eine ist besser, dann ist die schlechtere automatisch die falsche, denn als Programmierer kann es keinen Grund geben, von 2 Lösungen wissentlich die schlechtere zu nehmen - das wäre eben falsch.
Und Code, der unnützes Zeugs enthält ist numal unanzweifelbar schlechter als derselbe Code, wnner das unnütze Zeug nicht enthält.

und welche Variante ist nun die Beste um zu Erklären wie das mit dem If geht?

Was ist das Ziel dieses Threads?
Erläuterung der Syntax des If - Then - Else If - Else - End If - Konstrukts?
Das musste natürlich vollständig erläutern, und auch erläutern, dass Else If und Else optional sind, also auch weggelassen werden können, wenn nicht gebraucht.
Ausserdem musste noch aufs einzeilige If eingehen, weil da ist End If unzulässig.
Keinesfalls darfst du Statements bringen wie "Ich finde, zu jedem If gehört ein Else".
Ok - das darfst du finden, aber mitte Syntax von vb.net hat das nix zu tun (und wohl jeder andere wird das anders finden ).

Am besten bist du aus dem Schneider, wenn du einfach auf die Dokumentation von Microsoft verweist:
Vb.Net-Schlüsselworte

Es gibt den "tenären Operator", wo ein Else-Zweig erforderlich ist. Wenn hier schon darüber diskutiert wird, sollte dieser auch erwähnt werden:



MSDN: msdn.microsoft.com/de-de/library/zakwfxx4(v=vs.100).aspx

Konnte hier nur die C#-Version finden, ist aber 1:1, abgesehen vom Syntax, auf VB zu übertragen.

Auch sollte man das "Select Case"-Statement nicht vergessen, welches ich persönlich einem komplexen If-Statement vorziehe wenn möglich.

Mein Erklärungsversuch "Es gibt immer ein ELSE" wurde leider flasch verstanden.
Ich meinte damit If a = b Then TuEs hat auch ein ELSE ohne das man es schreiben muss. Dieses ELSE wäre ein Else "DoNothing" Sry für die Verwirrung die ich damit scheinbar gestiftet habe.

Was den Code angeht stimme ich @ErfinderDesRades zu je "kürzer" und/oder besser lesbar der Code ist desto besser ist er im Nachgang zu warten. Meist kann man sich durch eine vernünftige Benamsung und lesbaren Code viele Kommentar in der Doku sparen.

Wenn else also weggelassen wird muss oft auch noch gesprungen werden, wenn es aber direkt das Ende ist, dann kann der Compiler(KP ob .net gut genug ist, deren Optimierungen sind immer noch ziemlich schlecht) direkt nen return machen, oder innerhalb einer Schleife ggf direkt an den Anfang springen(man spart sich einen Sprung und Sprünge sind teuer)

Abgesehen davon kann ein "DoNothing" als NOP interpretiert werden, was dabei sehr irreführend sein kann

Edit: das ASM ist außerdem eher Pseudocode und kann nach Befehlssatz und code emitter variieren.

Machen die Compiler das heuer noch immer so ? Inzwischen sollte sowas in ein



compiliert werden...

Die Compiler machen beides, jenach Befehlssatz und Optimierungsmöglichkeiten, deshalb hab ich auch extra "Pseudocode" geschrieben. Sobald du beide parts hast brauchst du so oder so gleich viel Sprünge, nur wenn man was auslässt ist eine der beiden Sinnvoller. Bei Negierung der boolwerte dann natürlich wieder jz statt jnz etc...

ich dachte, es geht hier um die Syntax von vb.net zu klären - nicht, was der Compiler davon macht.
Dass der Compiler es richtig macht, das setze ich mal voraus.
Und ob ers so oder so macht ist glaub net relevant.
Ich rate jdfs. davon ab, seinen Code danach auszurichten, ob vermutet wird, dass der Compiler in dem Fall eine Sprungmarke setzen wird, und anders nicht.

Was der Compiler daraus macht ist mMn auch relevant für die Erklärung was passiert.
Und richtig ist dabei auch sehr wohl interpretationssache.

Vorallem nachdem der .Net Compiler ziemlicher misserabel beim Optimieren ist. Nur weil @ErfinderDesRades meint seine Datenanbindung(bitte nicht böse nehmen) sei perfekt, heißt das nicht, dass dies Architektonisch noch Performationstechnisch der fall ist(Vor allem was Performation anbelangt :P).
Deshalb finde ich es sehr wohl releveant mal die tatsächlichen gegebenheiten kennen zu lernen, nur das verhilft einem zur Entwicklung.
(Mir fehlen in .Net immer noch viele nette features die nicht nur architektonisch sondern gleichzeitig auch performance technisch fortschritt bringen würden)
Edit: Thema Templates(und nicht T4 schrott sondern richtige templates), dann natürlich variadic templates, und so viele compile time optimierungen. Auf welchem system ist denn bitteschöne %256 schneller asl &255?
auf keinem mir bekanntem systtem zumindest. Wth. gibt es dafür keine Optimierung(ich könnte das noch viel weiter ausführen, aber dafür reicht der Alkoholpegel dann doch nicht aus)

Wo warste da? Im Kindergarten?

Sind

Dizzy schrieb:

219 Leute auf der Strasse

für dich repräsentativ zum Verständnis von Programmiertechniken?
Du solltest vielleicht das Genre wechseln und Politiker werden.
Deren Vorgehen ist es, Statistiken zu erarbeiten und so hinzubiegen, dass mit diesen "Fakten" die nächste Wahl gewonnen werden kann.

*do not feed the troll*

Dizzy schrieb:

][/b]Ich bin der Meinung zu jedem If gehört auch ein Else.

Da hast du auch gleich im Eingangspost, deine erhoffte Antwort vorgegeben. Ganz gleich, was hier alle anderen geschrieben haben.

EIne Diskussion, die nicht ergebnisoffen debatiert werden kann, macht doch für niemanden Sinn, oder?

ich muss sagen, ich bin da noch viel weniger ergebnisoffen.
Imo kann die Diskussion kein anneres Ergebnis haben, als was bei MSDN spezifiziert ist, wie die Syntax numa ist, und nicht anners - was denn bitte sonst?
Und diskutieren findich nicht von vornherein ganz sinnlos, solange jmd irriger Meinung ist.
Also man braucht sich da nicht festzubeissen - sogar wers nicht kapieren will - der wirds wahrscheinlich iwann später kapieren.
Ich bin da optimistisch: Unumstößliche Gegebenheiten der Realität haben echt gute Aussichten, früher oder später doch von jedem richtig aufgefasst werden, der längerfristig damit zu tun hat.
Aber "Ergebnisoffenheit", oder gar Umfragen find ich iwie - ja: entbehrt nicht einer gewissen Komik

Du meinst so wie Dinge die in der MSDN stehen, seit Jahren nicht mehr gültig sind und auch aus dem Source hervorgeht, dass es nicht (mehr?) stimmt.

Abgesehen davon kann man immer darüber diskutieren ob rein logisch gesehen ein Else immer part der Anweisung ist, ich denke damit war auch nicht gemeint, ob man es explizit angibt oder nicht. Sondern eher unter der Haube.
Abgesehen davon, dass man dazu nichts auf MSDN finden wird.

Der Thread-Titel lautet: "Wie erklärt man jemand eine If Abfrage?".

Kannst du mir bitte nachweisen, an welcher Stelle die MSDN hier unrichtige Angaben macht?:
Vb.Net-Schlüsselworte (den Link gab ich übrigens bereits in post#21)
Oder gar "überholte Angaben" - also hat sich die Syntax von If, Else if, Else, End if in den letzten sagen wir mal 10 Jahren geändert?

Ich wusste, dass du nicht verstehst worauf ich hinaus will.

Mein erster Part war nur umzu sagen, dass MSDN nicht das Maß aller Dinge ist, denn was dort steht sind keine Fakten, was im Code steht sind Fakten und da jetzt alles OpenSource ist wunderbar.
Was nicht gepasst hatte war etwas mit Non-Blocking-Sockets, was Mono implementiert hatte wie auf der MSDN Seite stand, .Net aber nicht(was genau es war weiß ich nicht mehr, ist schon über 5 Jahre her)
Wie gesagt, mehr wollte ich nicht sagen, als dass man MSDN nicht als Unfehlbar nehmen darf(Vorallem auch nicht bei Richtlinien, die man doch manchmal wieder ändert)

Und auf das If/Else/... bezogen wollte ich dir nur erklären, was @Dizzy mit seiner "Meinung" gemeint haben könnte, was du entweder einfach ignoriert oder immer noch nicht verstanden hast, ich wüsste jetzt auch nicht, wie ich das anders/besser erklären sollte. Und wenn ich diese Meinung richtig verstanden habe, dann war diese doch sehr valide und es gibt keinen Punkt auf der ganzen MSDN der dagegen spricht/sprechen kann.

Und ob dus glaubst oder nicht, selbst bei solchen "Basis" Anweisungen, wie z.B. switch case(C# nicht VB.Net) ändert sich doch mal etwas: Stichwort Pattern-Matching

Also zur Syntax der Sprache ist MSDN die Referenz, und das Mass aller (diesbezüglichen) Dinge.

Darüberhinaus gibts noch das Framework - auch da hat MSDN Referenz-Charakter, mit dem kleinen Abstrich, dass angesichts der unüberschaubaren Menge an Klassen, an punktuellen Stellen Obsoletheiten auftreten können, oder sogar Fehler.
Dennoch ist MSDN sogar hier die beste Referenz, dies gibt: am besten gepflegt, am aktuellsten, am vollständigsten, am korrektesten.

@Dizzys Meinung ist durchaus valide in dem Sinne, dass darauf aufbauender Code keine Compilerfehler erzeugt - nur ist sie unvollständig.
Die tatsächliche Syntax enthält numal optionale Elemente, und die sind überaus nützlich.
Und sollten beim Erklären - ich erinnere nochmal an den Thread-Titel - keinesfalls weggelassen werden.

Das Maß aller Dinge ist und bleibt der Source, da der immer zu 100% korrekt ist. Natürlich ist MSDN die einfachere Anlaufstelle(obwohl so langsam wie die bei mir lädt :D). Darüber können wir jetzt auch noch stundenlang diskuttieren und würden vmtl. zu keinem Ergebnis kommen.

Und zu @Dizzy Meinung reden wir glaub ich einfach nur komplett aneinander vorbei. Wie gesagt ich hab davon geredet was unter der Haube abläuft(Ich verweise ebenfalls auf den Thread-Titel, wie du es ja so gerne tust - als ob mir das nicht klar wäre), nicht was Syntax sagt oder MSDN, denn das kann man aus beidem nicht ablesen. Aber auch hier könnten wir (anscheinend) jetzt weiter diskuttieren ohne auf ein sinnvolles Ergebnis zu kommen.

jvbsl schrieb:

Das Maß aller Dinge ist und bleibt der Source

Ja, wo es Sourcen zu gibt (Framework) - ja, meinetwegen - im weitesten Sinne: Code dokumentiert sich selbst.

Aber zu Schlüsselworten gibts keine Sources. Schlüsselworte verhalten sich, wie vom Erschaffer der Sprache als Spezifikation entworfen.
Und diese Spezifikationen sind auf MSDN nachzulesen.
Und in keinem Code kannste diese Spezifikationen nachlesen, weil Code verwendet Schlüsselworte, kann aber keine erschaffen.