Umfrage: Java-Experiment


#41

Ah, danke. Jetzt verstehe ich die Philosophie dahinter besser. Man möchte dadurch als Profi erscheinen. Schon komisch, dass das erst mit Java auftauchte und im C und C++ Umfeld unüblich war.
In der Tat war es interner Sun-Codestyle.

Das Problem ist, dass der Code unleserlicher wird.
Aus zwei Gründen. else ist nicht mehr unter if und das else erscheint optisch zum if block zu gehören.
Anfänger ist, wenn man Cargo-Codestyle anwendet. Irgendwelche Regeln, von denen man denkt, sie seinen professionell, die man aber selbst nicht versteht, sondern sklavisch anwendet. Fortgeschritten ist, wenn man sauberen Code schreibt. Z.B. auch alle Methodenargumente untereinander und nicht das erste noch oben und das zweite, dritte etc. dann darunter eingerückt.


#42

Es ist nicht K&R Style, aber der Rest deines Beitrags ist auch nicht richtig. :blush:
Vielleicht magst du in 2 Jahren einiges gelernt habn, aber für mich noch mittlerer Anfänger, scnr.

Edit: Beleg:

https://de.wikipedia.org/wiki/Einr%C3%BCckungsstil#1TBS_/K&R/Kernel/Linux/UNIX/%E2%80%9EWest_Coast%E2%80%9C/Stroustrup/Java/_Sun

Da aber bitte selber “durchwühlen”.


#43

Diejenigen, die nicht den Allman-Stil verwenden, würde ich gerne einen Tag lang beboachten, wie sie folgenden Code debuggen:

if (todayIsTuesday()) {
    doSomethingSpecial();
}

(Wichtiger Hinweis: Der Tag, an dem ich sie dabei beobachte, sollte kein Dienstag sein :smiley: )


#44

Schon komisch, dass Gegner dieses Stils immer mit diesem Argument kommen, obwohl es Unsinn ist. :wink:

Viel richtiger ist, dass dieser Stil aus dem C-Umfeld kommt. Die erste mir bekannte Verwendung ist der Unix-Source-Code von '72 - immerhin 10 Jahre vor der Gründung von Sun und und über 20 vor dem Erscheinen von Java…


#45

Wie ändert sich da durch mehr Zeilenumbrüche das Debuggen?

Ob das jetzt

if (todayIsTuesday()) {
    doSomethingSpecial();
}

oder

if (todayIsTuesday())
{
    doSomethingSpecial();
}

oder auch

if (todayIsTuesday())
    doSomethingSpecial();

ist, ist dafür doch irrelevant?


#46

@mrBrown hat recht.
@ThomasT ist ziemlich unfreundlich, mMn.


#47

Breakpoint setzen, debugger attachen … und dann debuggen wie gewohnt. Zu welchen Problemen sollte das denn deiner Meinung nach kommen Oo?


#48

Vielleicht hätte ich das weiter ausführen sollen. Aber sowas machen zu können

//if (todayIsTuesday())
{
    doSomethingSpecial();
}

finde ich einfach praktisch…


#49

Spätestens bei sowas klappt’s dann aber nicht mehr :stuck_out_tongue:

if (todayIsTuesday())
{
    doSomethingSpecial();
}
else
{
    magic();
}

Aber den Punkt an sich versteh ich, wobei ja jede IDE auch recht flott ein if (/*nextScene != null*/true) draus macht.


#50

@Marco13 fängt doch jetzt nicht etwa an zu trollen, oder? :blush:


#51

Es gibt ja nocht den “schnelles-Auskommentieren-Trick”:

//*/ 
thisIsOftenAdded();
andRemoved();
if (theCodeIsNotPlanned() || experimental()) 
{
    thenYouDoItLikeThat();
}
//*/

Da muss man nur den ersten / hinzufügen oder rausnehmen um den Block-Kommentar zu triggern.

Sowas hier gibt’s natürlich auch noch

boolean experimantal = false;
//experimental = true;
if (experimental) 
{
    String onlyInLocalScope = foo() + " is experimental!";
    System.out.println("should not be used, but in an experimental block, it is OK");
}

damit man das lokale flag schnell duch ein/auskommentieren umschalten kann.


#52

Oder man nimmt halt eine moderne IDE wie Intellij, markiert den Code und drückt [ STRG ] + [ / ].

Warum muss ich bei dem Ding an

    #define true false

denken :smiley:?

Aber das geht bei weitem einfacher. Breakpoint, Debugger an und wenn er hält führe ich an der Stelle einfach den Code aus den ich möchte. Sollte das Ergebnis nicht das gewünschte bringen - egal, ich häng ja im Breakpoint drin und kann während der Laufzeit jeden beliebigen Code ausführen. Hat den ungemeinen Vorteil, dass ich nicht erst neu bauen + meinen Use-Case durchspielen muss :wink:


#53

Das Markieren kann man sich in den meisten Fällen sparen. Für wenige aufeinenderfolgende Zeilen einfach die Tastenkombination mehrmals drücken (IntelliJ springt dann automatisch zur nächsten Zeile). Fürs Refactoring muss man die Stelle auch nicht extra vorher markieren (anders als in Eclipse, zumindest früher).

Seit wir in der Frontendwelt Prettier haben, gibt es bei uns keine Diskussionen um Codestyles mehr. Ich komme inzwischen sogar mit den eigentlich nicht mehr so modernen, aber vom Prettier standardmäßig verwendeten 80 Zeichen klar (in JS können bei 100 oder 120 Zeichen sonst echt schwer lesbare Einzeiler entstehen. Es hat auch den Vorteil, dass ich in IntelliJ Split Screen nutzen kann).


#54

Ich finds eher anstrengend, dass nicht verstanden wird, warum das so schlecht ist. Und dass es emotional (man wird als Anfänger beschimpft, wenn man nicht mitmacht) verteidigt wird. Auf mich wirkt es so, dass man nicht wirklich verstanden hat, warum und wie man Code strukturiert und formatiert. Es geht gerade nicht darum, dass man einen bestimmten Style sklavisch einhält. Sondern darum, leicht lesbaren und verständlichen Code für Menschen zu schreiben. Man schreibt Code in erster Linie für Menschen! Und das zu verstehen, ist für einige anscheinend schwierig, weil Quellcode schreibt man doch für den Compiler …

Der Javastyle ist deswegen schlecht, weil er optisch Zusammenhänge herstellt, wo keine sind. Und dort keine Zusammenhänge herstellt, wo welche sind. Und es ist egal, wie man klammert oder formatiert, wenn man diese Punkte berücktigt.

if (blabal){
  anweisung();
  nochneAnweisung();
} else{
  alternativeAnweisung();
  nochwas();
}

sieht auf den ersten Blick wie ein großer Block aus!

if (blabal){
  anweisung();
  nochneAnweisung();
} 
else{
  alternativeAnweisung();
  nochwas();
}

Trennt optisch. Ist das so schwer zu sehen und zu verstehen?

Zwei weitere Unsitten:

   funktionmitlaengerenName(tollerErsterParameter,
      zweiterParameter,
      dritter);

Warum hat tollerErsterParameter eine Sonderrolle? Auf dem erstern Blick sieht man nur zwei Parameter.
Schlimm ist auch:

public void methode(int paramEins, 
  int paramZwei, 
  int paramDrei){
  int lokaleVariable1;
  int lokaleVariable2;
...

Hier sieht es auch wie ein Block. Zudem nicht mal paramEins optisch gehört.
Solcher Code gilt aber bei vielen als gut formiert und IDEs wurschteln so was hin.

Habt ihr mal Code von anderen warten müssen? Musstet ihr mal Code von euch, der mehrere Jahre alt ist, wieder lesen und verändern?
Solche Formatierungen helfen ungemeint.

Oder bin ich da so sehr ein Exot? Versteht mich wenigstens einer?
Können wir uns, wenn für über Codestyle reden, das berücktigen, warum er gemacht wird, und untersuchen, ob die Anforderungen so erfüllt werden. Fomalitäten wie CheckStyle zu erfüllen? Oder den Mitprogrammierern oder sein zukünftiges Ich das lesen zu erleichern?


#55

Du hast zwei Probleme. Zum Einem ist das falsch (die JCC’S verstoßen nicht gegen das Lesbarkeitsprinzip), zum Anderem hast Du dich gerade mit mir angelegt (was immer nicht gut ist :wink: ). :slight_smile:


#56

Das stimmt. Genauso schlimm sind try-catch Blöcke. Wenn die Methoden und Parameter unübersichtlich und zu lang werden ist das schrecklich zum lesen.

Ich formatiere dass dann im Zweifelsfall aber so

if (blabal){

  anweisung();
  nochneAnweisung();

} else{

  alternativeAnweisung();
  nochwas();

}

Behält die Konvention bei (der Lesefluss wird nicht unterbrochen) und macht es lesbarer.
Dein Ansatz macht es zwar auch lesbarer aber bricht die Konvention, ich persönlich finde das ungewohnt und stört mich beim lesen.
Jetzt ist natürlich die Frage ob mein Ansatz so viel besser ist, denn ich habe (genau wie du) natürlich kein Problem eigenen Code zu lesen.


#57

u.U, weil es da kein objektives schlecht gibt?

Das war eine einzelne Person, die du dabei wohl getrost ignorieren kannst…

Deine Punkte kann man auch genau gegenteilig auslegen.

} 
else{

Dies zieht Dinge auseinander, die zusammen gehören - das else gehört eben zum if, und kann nicht alleine stehen). Außerdem ist eine geschlossene Klammer ist für mich immer das Ende eines Block, nach dem man einfach blind den neuen beginnen kann - hier nicht möglich, der relevante Teil zieht sich semantisch über zwei Zeilen.

Für mich sieht das auch nicht wie ein großer Block aus - das ist deutlich eingerückt (zumindest, wenn man mehr als zwei Spaces nutzt) und dick und fett von jeder IDE markiert.
Außerdem folgt es den Konventionen, und unkonventioneller Stil ist immer erstmal hindernd beim Lesen. Üblicherweise reicht es, im Team den Konventionen zu folgen, aber zumindest mich stört sowas beim Lesen.

Naja, es ist der erste Parameter, er hat also sowieso ne Sonderstellung :stuck_out_tongue:

Bei mir werden aber in beiden Fällen Argumente bzw Parameter gleich eingerückt:

 funktionmitlaengerenName(tollerErsterParameter,
                          zweiterParameter,
                          dritter);

bzw:

public void methode(int paramEins, 
                    int paramZwei, 
                    int paramDrei) {
      int lokaleVariable1 = 42;
      int lokaleVariable2 = 21;

Allerdings wäre ne Studie, die Einrückungsstile und deren Einfluss vergleicht, sicherlich interessant…
Vielleicht reicht es schon, einfach mal Projekte auf Github zu untersuchen und prüfen, ob’s ne Korrelation zwischen Codestil und Fehlerhäufigkeit gibt, wobei man dafür ne sinnvolle Metrik bräuchte, ob Issues reichen?


#58

Dein Beispiel untermauert diese Aussage nicht wirklich. Ein else gehört zu einem if. Ohne das if macht das else keinen Sinn. Also besteht hier ein Zusammenhang.

Nur für dich - weil du es so gewohnt bist. Ich finde es eher unübersichtlich, da das else beim lesen eher “überraschend” kommt. Was mir bei dem ganzen aber am meisten sauer aufstößt ist die extra-Zeile. Meiner Meinung nach hat das else keine Berechtigung alleine zu stehen. Sowas macht eine Methode optisch nur größer. Deswegen halte ich ja auch überhaupt nichts vom Allman-Stil! Hatte es mal kurzzeitig ausprobiert, weil IDE so voreingestellt (c# halt). Aber mir ging das mächtig auf den Sack das gefühlt die hälfte meiner anzeigbaren Zeilen für Klammer auf Klammer zu drauf gehen. Da wird man ja schon fast zu genötigt ewig lange Methode zu schreiben um lines zu sparen. Hat dann nicht lange gedauert, bis ich meine IDE umgestellt habe.


#59

Auch “ich werde nach Code-Zeilen bezahlt”-Stil genannt :stuck_out_tongue_winking_eye:


#60

Das wäre der Fall, wenn man auch die öffnende Klammer auf eine neue Zeile packen würde.

Ich verstehe dein Argument übrigens. Vor 20 Jahren (;-)) habe ich auch so C++ programmiert. Jede Methode musste kompakt und kurz sein.
Ich sag dir was: hat sich auf Dauer nicht bewährt. Es war anstrengend den Code nach 15 Jahren zu verstehen. Ich hatte in der Tat alten Code neu gebraucht.
Im neu gemachten Code (btw. java und c++) habe ich dann großzügiger geschrieben und logische Blöcke optisch getrennt. Hat sich bewährt.
Um Methodenanfänge optisch zu erkennen benutze ich Kommentare. (javadoc oder kleiner).

Ansonsten spricht für den Sun-Style nur die Gewöhnung. Klar, verstehe ich. Wer mit Java programmieren gelernt hat und es nur so sieht, gewöhnt sich dran und findet es gut.
Aber wer von C(++), Python, Präprocessor kommt der findet es gut, wenn es else in einer Spalte wie das korrespondierende if und geg. endif steht.

Das Argument dass ein else zum if-Block gehört und daher dahinter muss lasse ich nicht gelten. Jeder weiss, dass ein schlüsselwort else ein korrespondierendes if haben muss.

Ansonsten: mal dran gedacht die Schriftgröße zu ändern? Ich schreib überall mit 9pt Lucida console.