Coding style-Rat/Begründung(en) für die Platzierung von Leerzeichen im control-Anweisungen mit C++

Angesichts der folgenden zwei coding-styles, geben Sie bitte einen Begründung (einige vor - /Nachteile), warum würde man möglicherweise vorzuziehen, die andere beim schreiben von C++ code.

( Bitte tun nicht Antwort mit "es ist nicht wichtig"; "das ist ganz einfach, man"; etc. Die Frage ist speziell über die möglichen pro - /Kontra (falls vorhanden) der beiden Abstand Stile unten. Danke. )

//VARIANT A (NO space after control keyword /space before curly brace)
if(condition) {
  //...
}
else if(c2) {
  //...
}
else {
  //...
}

for(int i=0; i<e; ++i) {
  //...
}

...

//vs. VARIANT B (space after control keyword /NO space before curly brace)

if (condition){
  //...
}
else if (c2){
  //...
}
else{
  //...
}

for (int i=0; i<e; ++i){
  //...
}

...

Hinweis: Abgesehen von Geschmack, Fragen, ich Frage dies, weil ich sehe beide Stile in unserer code-Basis und würde versuchen, einige Argumente für die vorzuziehen ist.

Sollte dies nicht sein community-wiki?
Ja, sollte es.
Warum sollte das so sein community-wiki?
Was macht Sie denken, es ist eine mögliche Begründung, andere als die auf der Basis von Geschmack oder ästhetik?
Ich hasse beide. Die geschweiften Klammern nicht ausgerichtet.

InformationsquelleAutor Martin Ba | 2010-12-06

c++coding-style

18

Viele Menschen bekommen sehr davon besessen ist, wo die Leerzeichen, Klammern, Klammern, Klammern, Semikolon und so weiter, während in der gleichen Zeit vergessen, dass das wichtigste an der source-code ist, dass es verstanden werden muss, von einem anderen Menschen.

Den compiler konnte nicht weniger kümmern uns um die Formatierung.

Nach vielen Jahren in der Programmierung von Beruf, ich bin gekommen, um diese eine einfache Regel:

Ist es leicht zu Lesen und zu verstehen, was der code macht?

Ist es egal, wie Sie formatieren Sie den code, wenn die oben genannte Bedingung nicht erfüllt, wird der code von schlechter Qualität.

Habe ich eine persönliche Präferenz zu formatieren, und ich werde nicht sagen, was es ist hier, wie es wirklich egal, was es ist.

Ich finde es nützlich, dass andere Programmierer den code in verschiedenen Stilen.

Natürlich gibt es eine Ausnahme von dieser Regel: Dokumentation und tutorial-Beispiele sollten immer konsistent sein - Sie brauchen, um den Leser zu Folgen, die wichtigen Elemente gezeigt wird und nicht ablenken lassen durch die Formatierung.

InformationsquelleAutor Skizz
14

Da dies wohl viel über Gewohnheit und Geschmack, es könnte schwer sein, keine konkreten Argumente für oder gegen, aber hier ist was ich denke:

Beides funktioniert Recht gut, aber wie würde es Aussehen, Leerzeichen in Funktionsaufrufen? wie diese:
```
len = strlen (somePtr);
```
Dass mindestens ein Raum zu viele meiner Meinung nach.

Dass Leerzeichen in diesem Beispiel macht es sehen eher aus wie ein control-Anweisung als eine Funktion aufrufen, und ich denke, es ist nützlich, um if/else/while/for stand-out ein bisschen.

Aber ich weiß, das ist eine ziemlich subjektive Ansicht. 🙂

+1 - vielen Dank für ein argument Abdeckung die eigentliche Frage
re "Leerzeichen in Funktionsaufrufen" - ich habe es immer vermieden, für den Zweck der Differenzierung von Kontrollfluss - aber, z.B., GNU C fördert spaces_between_functions_and (their, arguments). Dies beginnt Sinn zu machen, wenn das schreiben von code mit GLib/GTK+, wo Dinge wie die some_method(Instance *instance, other params machen Linien ziemlich lange, so dass keine visuellen Hilfsmittel sind willkommen. Mit den letzten schnipseln von GTK+, die ich geschrieben habe (ich begann auf gtkmm), ich habe versucht, und es scheint zu helfen, im Kontext.
Ich habe tatsächlich gesehen, wie deinem Beispiel den gleichen code wie der OP. Ich habe gesehen, codebase, wo JEDER öffnenden Klammer hatte ein Leerzeichen vor, keine Ausnahmen.

InformationsquelleAutor Mattias Nilsson
13

Vor kurzem habe ich ein paar code-Zeile-wenn geändert wurde und jemand vergessen, fügen Sie einige Klammern.

Beim Lesen der Codes, es schien mir, dass der Stil ...condition){ ist schwieriger zu Lesen als der Stil ...condition) { da die letzten ) und Eröffnung { sind leichter zu sehen, wenn durch ein Leerzeichen getrennt. (Bei der Verwendung von Courier New auf VS2005 - Verschieden sein, mit unterschiedlichen Schriftarten, denke ich.)

Ich würde auch behaupten, dass mit if( die Trennung ist ziemlich klar, ohne zusätzliche Leerzeichen, vor allem, weil in einem modernen editor die if sehr wahrscheinlich farbigen anders als die (, aber { wird wahrscheinlich die gleiche Farbe haben.

Hier ein kurzes Beispiel:
```
if (pPointer && pPointer->condition(foobar)){
  SendEvent(success_foobar);
  Log(success_foobar);
}
if (pPointer && pPointer->condition(foo))
  SendEvent(success_foo);
  Log(success_foo);
if (pPointer && pPointer->condition(bar)){
  SendEvent(success_bar);
  Log(success_bar);
}
```
vs. (was ich glaube, macht Sie die fehlende Klammer ein bisschen klarer):
```
if(pPointer && pPointer->condition(foobar)) {
  SendEvent(success_foobar);
  Log(success_foobar);
}
if(pPointer && pPointer->condition(foo))
  SendEvent(success_foo);
  Log(success_foo);
if(pPointer && pPointer->condition(bar)) {
  SendEvent(success_bar);
  Log(success_bar);
}
```
Um es zusammenzufassen, man kann argumentieren, dass die visuelle Unterscheidung in der modernen Editoren ist viel größer heutzutage, z.B. if und (, so dass diese nicht brauchen Räume, während ( und { sind oft gefärbt die gleiche und sind nicht so deutlich sichtbar und daher ein Raum kann in Ordnung sein.

Versierte. Sehr aufschlussreiche Ratschläge, wie der editor wird wahrscheinlich markieren Sie Schlüsselwörter, aber nicht Token wie ein Klammern oder geschweifte Klammer. Neugierig, was Sie bevorzugen: if(...) oder if (...) - und die ist weit verbreitet in der professionellen Industrie?
Hi @Thom - wrt. Leerzeichen zwischen " if " und Klammer öffnen, ich habe keine sinnvolle Einstellung. Nicht sicher, es ist beliebiger Industrie-Konsens über diese Dinge.
Immer setzen Sie die öffnende geschweifte Klammer in die nächste Zeile, und nie über eine einzige Zeile 'if' - Anweisungen löst auch dieses problem

InformationsquelleAutor Martin Ba
5

Ich persönlich bevorzuge diesen Stil:
```
if( condition )
    oneLiner();
else if( complicatedCondition(someVar, otherVar) )
{
    more();
    than();
    oneLiner();
}
else if( otherCondition ) //I would prefer to put this in one if with '&&' between conditions...
{
    if( nestedCondition )
        oneLiner();
}
else
{
  //...
}

for( int i = 0; i<e; ++i )
{
  //... even for one-liner loops which occasionally might happen
}
```
Warum?
1. Klammern ausgerichtet sind
2. Kein Platz verschwendet oneliner ifs.
3. Loops sind klar und deutlich angegeben mit Klammern (immer)
4. Nur die äußere Ebene hat die Leerzeichen vor und nach den Klammern. Immer noch ein Chaos, wenn es mehr als drei Ebenen der aufrufenden Funktion beteiligt, wie some( function(calling(another(function())) )
5. ein einzelnes Leerzeichen nach einem Semikolon und Komma für das einfache Auffinden dieser Arten von Trennzeichen.
6. Verschachtelte ifs Spange brauchen um Sie herum.
Dies ist natürlich rein persönlich, und auch alle Kommentare auf meinen Stil werden ignoriert schamlos 😉

Das funktioniert OK ich denke mal bis einige Programmierer updates es entlang der Linien von oneLiner(); => if (another_condition) oneLiner (); und dann die Dinge gehen ein bisschen komisch.
Dann wird die verschachtelte wenn-muss extra Klammern natürlich. Bearbeiten, hinzufügen, zeigen. Beachten Sie, dass eine einzige zusätzliche Bedingung gestellt werden kann, in die gleiche, wenn mit &&.
Gut argumentiert, aber ich denke, diese Abfälle den vertikalen Raum, das macht das Lesen von code schwieriger. (Nur eine subjektive Meinung, natürlich.)

InformationsquelleAutor rubenvb
1

Ich in der Regel Platz Leerzeichen zwischen allen Betreibern. Es ist einfach schneller zu analysieren, visuell. Vielleicht, wenn Ihr Augenlicht ist besser als meine.

InformationsquelleAutor Puppy
1

Ihrer Frage, es scheint, als ob Sie sind sich bewusst, dass eine Menge Leute werden Ihnen sagen, dass es egal ist. Da Sie bereits wissen, warum Sie darauf bestehen, es muss einen objektiven Grund für die Verwendung eines styles über den anderen?

Wenn Abstand ist wirklich das wichtigste Problem in Ihrem code-Basis, muss Ihr team das beste team in der Geschichte der Programmierung. Wenn nicht, sollten Sie sich keine sorgen mehr um den Ausdruck der Ideen klar und wenn die software dient seinem Zweck.

Nicht "eine", "ein" Grund. Aber es sollte einige Argumente, die so oder so. (Oder nicht, in welchem Fall seine alle Geschmack. Aber ich glaube nicht, dass es ist. Sollte es immer einige Argumente (vielleicht auch schwachen) so oder so, die sind nicht rein auf den Geschmack.)

InformationsquelleAutor Jørgen Fogh
1

Mit dem Aufkommen von modernen IDEs und automatische code-Formatierung, das ist wirklich weder hier noch dort. Und ich wäre nicht Beratung, Großhandel Veränderung der Räume (oder andere änderungen an der Formatierung) für bestehenden code in ein vcs. Entwickler neigen dazu, zu bleiben, um die Formatierung, die Sie mit vertraut sind und, solange der code gibt die Absicht gut, wo einem bestimmten Raum eingelegt ist, ist Total überflüssig IMHO. Was werden Sie wahrscheinlich zu tun ist ärgern Menschen, die gewohnt sind zu tun es eine Möglichkeit, durch das erzwingen von etwas, das ist gekünstelt auf Sie...

Fokus auf der Programmierung, nicht die Formatierung...

InformationsquelleAutor Nim

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.