Welche Programmierstil bevorzugst du?

 - (Psychologie, Programmieren)

Das Ergebnis basiert auf 22 Abstimmungen

# 1 50%
# 2 50%

11 Antworten

# 2

Die ersten 10 Jahre meiner Karriere als Software-Entwickler habe ich meinen Stil hauptsächlich nach Methode Nummer 1 formatiert.

Die letzten 25 Jahre hingegen bevorzuge ich einen Stil, der sehr an Methode Nummer 2 angelehnt ist.

Der Grund ist einfach, dass bei Methode 2 sinnlose Zeilen vermieden werden, die nur eine einzige Klammer enthalten, und ansonsten keinerlei semantischen Mehrwert haben, bzw. zur besseren Lesbarkeit beitragen.

Man hat mit Methode 2 also mehr Zeilen mit wirklich sinnvollem Code auf dem Bildschirm im Blick.

Allerdings kann man nicht immer auf seinen Wunschstil bestehen, und normalerweise hält man sich sowieso an die Guidelines, die vom aktuellen Projekt vorgegeben sind.

Evtl. kann man beim Checkout und Commit den Stil automatisiert anpassen bzw. umwandeln, aber das ist bei vielen Buildprozessen nicht machbar bzw. unerwünscht.

Aber an sich ist Methode 2 m. p. M. n. einfach effizienter. Da wirst du aber nahezu unendlich viele Meinungen zu Gesicht bekommen.

Soll jeder den Stil nutzen, mit dem er / sie / es am besten klar kommt ... wie gesagt - soweit das im Projekt überhaupt möglich ist ... wenn nicht, dann passt man sich eben einfach an. :)

# 1

Mir ist bewusst, dass Variante 2 Standard ist, aber ich habe öffnende und schließende Klammern am liebsten auf einer Spaltenebene. Das erleichtert mir das Zählen, falls ich irgendwo eine vergessen haben sollte.

Das ist mir eine Zeile mehr wert.

ich drück dann immer „%“... dann sagt vi mir, wo die Klammer hinführt...

0
@RIDDICC

Das sagt doch schon viel aus, wenn die IDE dabei helfen muss, die Klammern zu finden.

3
@Suboptimierer
  1. hä?
  2. es sagt eigentlich eher was aus, wenn da überhaupt mal ne Klammer fehlt...
  3. aber wenn es mal passiert, dann sind meist so 20 Zeilen betroffen... bei deinem Stil vllt sogar 30... das überschaut man nich so leicht...
0
@RIDDICC

Ganz allgemein gesprochen ist es auch der Job der IDE, mir beim Programmieren zu helfen. Von daher sagt das jetzt eigentlich nichts aus.

Ich nutze übrigens gerne Addons, die Klammern in unterschiedlichen Farben einfärben (zusammengehörige Klammern haben die selbe Farbe) und finde das - neben einer sauberen Einrückung und einem Blick darauf, dass man nicht so viel verschachtelt - recht hilfreich. Für VS Code wäre das https://marketplace.visualstudio.com/items?itemName=CoenraadS.bracket-pair-colorizer-2 , vielleicht gibt's sowas für andere IDEs auch.

1
@bluebird5

Wenn man sich auf die Position stellt, dass es die Aufgabe der IDE ist, Klammerungen hervor zu heben und falsche Klammersetzung direkt zu visualisieren, dann ist es in der Tat nur eine Frage der Vorliebe.

Ihr wisst ja: Theoretisch kann man auch alles in eine Zeile schreiben.

Ich finde es halt manchmal auch unpraktisch. Wenn irgendwo steht

if(a==b){
  c=d;
}

Dann kann ich nicht direkt testen, wie das Programm ohne if sich verhalten würde, indem ich die Zeile einfach auskommentiere

//if(a==b){

funktioniert nicht.

0
@Suboptimierer
Dann kann ich nicht direkt testen, wie das Programm ohne if sich verhalten würde, indem ich die Zeile einfach auskommentiere

In der Situation würde ich den kompletten if-Block auskommentieren. Letzten Endes ist es aber wirklich Geschmackssache (genauso wie bspw. Tabs vs. Spaces oder ob private Klassenvariablen mit einem Unterstrich beginnen sollen), es sollte nur Projekt- bzw. sogar firmenweit einheitlich sein.

0
@bluebird5

Was meinst du damit, dass du den gesamten if-Block auskommentieren würdest?

Wenn der gesamte Block auskommentiert wird, dann würde der komplette Code nicht ausgeführt werden. Ich meine aber Situationen, in denen die Abfrage (die Bedingung) nicht stattfinden soll, sondern immer der Rumpf des ifs ausgeführt werden soll. Dafür sind dann zwei Kommentare notwendig.
Wenn man die öffnende Klammer jedoch in einer Extrazeile stehen hat, dann kann man die Zeile mit dem if problemlos auskommentieren.

1
@Suboptimierer

Whoops, hab dich falsch verstanden, ich war irgendwie auf dem Trichter, dass du den If-Block nicht ausführen willst.

In dem Fall würde ich den if-Block mit einem

if (true || a == b) {

temporär kurzschließen, aber ich komme in der Praxis selten in die Situation, dass ich einen if-Block ignorieren möchte.

0
@bluebird5

Das ist ja noch mehr Arbeit als zweimal // zu setzen. ^^
Aber so meine ich das, ja.

Was auch gehen müsste, ist {// voran zu stellen:

{//if(a==b){
0
# 1

#1: wenn man von unten sucht, findet man leichter den Beginn des Blocks, weil nach genau einem Zeichen Ausschau zu halten ist.

# 2

Kontrollstrukturen in einer Zeile ohne ; oder { sehen für mich einfach verloren aus.

Noch dazu nimmt die Extraklammer Platz weg.

# 2

Definitiv #2.

Aber wenns mir sinnvoll erscheint, dann auch "#3":

for(int i=0;i<20;printf("%d\n",i++));

^^