Warum ist so viel Code so? - Seite 3

 
RaptorUK:

Aber bedeutet das nicht, dass der Code, wenn sie um Hilfe bei der Syntax oder Logik bitten, nicht " ... syntaktisch und logisch korrekt sein wird;" ?

Ja, da haben Sie recht. Aber im Zusammenhang mit der Diskussion über mehr (oder weniger) effektive Kodierungsstile/-praktiken ist der wichtigste Aspekt, dass der Code syntaktisch und logisch korrekt ist, unabhängig vom verwendeten Kodierungsstil. Ich denke, man kann es auch so ausdrücken, dass der Stil dem syntaktisch und logisch korrekten Code weichen muss - die primäre Frage ist nicht, ob der Code gut aussieht und leicht lesbar ist, sondern ob er syntaktisch und logisch korrekt ist, um die Aufgabe zu erfüllen, für die er geschrieben wurde :)

Ich stimme auch mit // Kommentaren überein. Man kann nie zu viele // Kommentare haben, sowohl um die Gedanken des ursprünglichen Programmierers hinsichtlich der Einzelheiten der verschiedenen Code-Teile aufzufrischen als auch um anderen zu helfen, den Code nach der Fertigstellung/Implementierung zu verstehen.

 
Thirteen:

Ja, Sie haben Recht. Aber im Zusammenhang mit der Diskussion über die mehr (oder weniger) effektiven Kodierungsstile/-praktiken ist der wichtigste Aspekt, dass der Code syntaktisch und logisch korrekt ist, unabhängig vom verwendeten Kodierungsstil. Ich denke, man kann es auch so ausdrücken, dass der Stil dem syntaktisch und logisch korrekten Code weichen muss - die primäre Frage ist nicht, ob der Code gut aussieht und leicht lesbar ist, sondern ob er syntaktisch und logisch korrekt ist, um die Aufgabe zu erfüllen, für die er geschrieben wurde :)

Ah OK, ich verstehe, was Sie sagen wollen ... schön präsentierter Code nützt nichts, wenn er nicht funktioniert ... aber vielleicht ist er leichter zu korrigieren ?
 
RaptorUK:
Ah OK, ich verstehe, was du sagst ... schön dargestellter Code nützt nichts, wenn er nicht funktioniert ... aber vielleicht ist es einfacher zu beheben?
Richtig. Mit anderen Worten, Kodierungsstile/-praktiken und Präsentation, die größtenteils die Wahl des Programmierers sind, sind ein Mittel zum Zweck (das Ziel ist syntaktisch und logisch korrekter Code) :) Wenn der Code vom Programmierer (und später von anderen, die den Code nicht geschrieben haben) leicht gelesen und verstanden werden kann, ist es viel einfacher, syntaktische und/oder logische Fehler zu erkennen und zu korrigieren.
 

Ich schließe meinen Code, wenn er fertig ist und funktioniert, aber es ist einfach, ihn mit ein paar Leerzeilen wieder zu öffnen, wenn ich ihn weitergeben oder diskutieren muss. Ich denke, dass ein Kodierungsformat die einfache Identifizierung einer fehlenden Klammer und die einfache Identifizierung von if else-Paaren unterstützen sollte, wenn es einen komplexen if else-Baum mit mehreren Verzweigungen gibt. Ich habe mir den K&R-Stil nie zu eigen gemacht, deshalb würde ich gerne sehen, wie die K&R-Kodierer es machen.

 
SDC:

Ich schließe meinen Code, wenn er fertig ist und funktioniert, aber es ist einfach, ihn mit ein paar Leerzeilen wieder zu öffnen, wenn ich ihn weitergeben oder diskutieren möchte.

Warum sollte man ihn überhaupt schließen? Ich verstehe wirklich nicht den Sinn von zusammengequetschtem Code. Wenn man ihn öffnen muss, um ihn weiterzugeben oder zu diskutieren, was bedeutet das dann?

SDC:

Ich denke, ein Kodierungsformat sollte die einfache Identifizierung einer fehlenden Klammer und die einfache Identifizierung von if else-Paaren bei einem komplexen if else-Baum mit mehreren Zweigen unterstützen. Ich habe den K&R-Stil nie übernommen und würde daher gerne sehen, wie die K&R-Codierer das machen.

Bei der K&R-Methode wird die untere Klammer an der übereinstimmenden Bedingung ausgerichtet. Ich persönlich verwende

1. Konsistente Einrückung

2. Für einzelne Anweisungsklauseln entweder Klammern und Einrückungen ODER sie folgen der Bedingung ohne Klammern.

if (flag) {
   i++;
}

OR

if (flag) i++;

3. Benutzen Sie einen anständigen Programmeditor, der geschweifte Klammern berücksichtigt.

Passende Klammern sind kein Problem - der größte Teil des Linux-Kernels ist in diesem Stil geschrieben, und es ist der Java-Standard. Allerdings sehe ich den Reiz des Allman-Stils, da ich beim K&R-Stil oft eine zusätzliche Leerzeile nach der Bedingung einfügen würde, um den Code zu entrümpeln. Hmm ich könnte bekehrt werden :)

 
ydrol:

Warum sollte man ihn überhaupt schließen? Ich verstehe wirklich nicht den Sinn von zerquetschtem Code. Wenn Sie es öffnen müssen, um zu teilen/diskutieren, was bedeutet das?

Für K&R-Stil, die untere Klammer richtet sich mit der Bedingung übereinstimmen. Ich persönlich verwende

1. Konsistente Einrückung

2. Für einzelne Anweisungsklauseln entweder Klammern und Einrückungen ODER sie folgen der Bedingung ohne Klammern.

3. Benutzen Sie einen anständigen Programmeditor, der geschweifte Klammern erkennt.

Passende Klammern sind kein Problem - der größte Teil des Linux-Kernels ist in diesem Stil geschrieben, und es ist der Java-Standard. Allerdings sehe ich den Reiz des Allman-Stils, da ich beim K&R-Stil oft eine zusätzliche Leerzeile nach der Bedingung einfügen würde, um den Code zu entrümpeln. Hmm ich könnte bekehrt werden :)

Ich schließe ihn einfach, damit er weniger Platz auf dem Bildschirm einnimmt. Ich möchte so viel davon gleichzeitig sehen, wie auf den Bildschirm passt. Ich brauche keinen Klammerabgleich, ich formatiere ihn so, dass, wenn ich den Cursor hinter einer Klammer platziere und ihn mit der Pfeiltaste vertikal die Zeilen hinaufführe, wenn er eine andere Klammer berührt, diese das Klammerpaar ist. Wenn ich ihn hinter einer else-Klammer platziere und dasselbe tue, wenn er eine if-Klammer berührt, ist das das if else-Paar.

In diesem Codeabschnitt ist leicht zu erkennen, dass die dritte else-Klammer mit der ersten if-Klammer, die zweite else-Klammer mit der zweiten if-Klammer und die erste else-Klammer mit der dritten if-Klammer verbunden ist, da die Klammer(n) hinter jeder else-Klammer vertikal hinter der entsprechenden if-Klammer angeordnet sind. Ebenso ist leicht zu erkennen, welche if's keine else's haben, weil jede if-Klammer vertikal mit der entsprechenden schließenden Klammer in der Gruppe hinter dem else aufgereiht ist. Ich behaupte nicht, dass alle anderen den Code auf diese Weise formatieren sollten, nur weil ich es mag, aber für mich ist es kompakt und logisch.

      if(downtrend)
      {if(High[i] < LineDownBuffer[i+1])
       {if(DeMarkerHighBuffer[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
        }else
        {if(DeMarkerHighBuffer[i] < LineDownBuffer[i+1])
         {LineDownBuffer[i] = DeMarkerHighBuffer[i];
       }}}else
       {if(High[i] > LineDownBuffer[i+1])
        {LineDownBuffer[i] = LineDownBuffer[i+1];
         LineUpBuffer[i] = DeMarkerLowBuffer[i];
         downtrend = false;
         uptrend = true;
      }}}else
 
SDC: Ich schließe meinen Code, wenn er fertig ist und funktioniert, aber es ist einfach, ihn mit ein paar Leerzeilen wieder zu öffnen, wenn ich ihn weitergeben oder diskutieren muss. Ich denke, dass ein Kodierungsformat die einfache Identifizierung einer fehlenden Klammer und die einfache Identifizierung von if else-Paaren unterstützen sollte, wenn es einen komplexen if else-Baum mit mehreren Verzweigungen gibt. Ich habe mir den K&R-Stil nie zu eigen gemacht, deshalb würde ich gerne sehen, wie die K&R-Kodierer es machen.

Ich kann dies nicht für jeden Programmierer beantworten, der k&r verwendet. Ehrlich gesagt, je mehr ich mir Ihr Format ansehe, desto mehr gefällt es mir. Hätte ich den Allman-Stil übernommen, könnte ich mir durchaus vorstellen, Ihre modifizierte Version zu verwenden. Die geschweiften Klammern reihen sich untereinander auf, so dass die öffnenden und schließenden Klammern nicht mehr eine ganze Zeile in Anspruch nehmen. Man kann mit dem Cursor über das "i" beim "if" fahren und fehlende Klammern finden, man muss sich nicht mehr um die Konventionen der Tabulator- und Einrückungsgröße kümmern, der Modus ist kompakt {die meisten deiner Codes sind auf dem Bildschirm zu sehen}. Also ja, es ist ziemlich cool, nur auf den ersten Blick, weil ich es nicht gewohnt bin, schien es verwirrend. Und das ist der Kern der Sache.

Mir scheint, dass viele amerikanische Programmierer den [KnR & Allman]-Stil übernehmen, während der Whitesmiths-Stil bei Europäern beliebt zu sein scheint. Whitesmith ist auch der Standardstil für Mt4. An diesen Stilen ist nichts auszusetzen, aber wenn ich jemandem helfe, muss ich mich immer wieder daran erinnern, meinen K&R-Stil zu ignorieren und mehr an Whitesmith zu denken. Das oder einen Code-Formatierer verwenden.

Warum jemand "komplexe if else-Bäume" schreiben will, ist mir unbegreiflich. Wenn jemand den ganzen White_Space und die Formatierung in einem komplexen if_nest weglässt, sieht es so aus, als ob er versucht hätte, einen Snake | Spaghetti | ZigZag über die Seite zu ziehen. Das erste if beginnt in Zeile 1 und endet in Zeile 300, etwa 150 oder %50 dieser Zeilen werden von geschweiften Klammern gehalten. Warum erstellen Sie nicht einfach eine Funktion anstelle der "komplexen if else-Bäume"? Dann lassen Sie Zeile_1 tatsächlich in Zeile_1 mit if( false ){ return; } enden.

 

Danke ubzen Ich bin froh, dass jemand mein Format mag lol. Ich benutze if else sehr oft, wahrscheinlich weil mir, als ich mit dem Programmieren angefangen habe, jemand gesagt hat, dass if else schnellen Code macht, also habe ich es mir angewöhnt, das so zu machen.

 
SDC:

Danke ubzen Ich bin froh, dass jemand mein Format mag lol. Ich benutze if else sehr oft, wahrscheinlich weil mir jemand gesagt hat, dass if else schnellen Code macht, als ich mit dem Programmieren angefangen habe, also habe ich mir das angewöhnt.

Es ist nichts Persönliches


In Zeiten wie diesen wäre es gut gewesen, einen formalen, durchgesetzten Standard zu haben, an den sich jeder hält ... dann würden wir alle das Gleiche tun und wir würden alle Ihren Code mögen. Und bevor Sie fragen: Nein, ich bleibe bei meinem Whitesmiths-Stil... wenigstens weiß ich jetzt, wie ich ihn nennen soll, danke ubzen

 
Gern geschehen, SDC und RaptorUK. Die Codierung ist ein viel leichter zu diskutierendes Thema als Winning_EA. :)