Auch 200 Zeilen können sinnvoll sein wenn man sie als logische Einheiten auffasst - ohne nicht unnötigerweise hin und her scrollen zu müssen.
@Meniskusschaden hat recht, das sind gut begründete Ausnahmen wobei das "begründete" hier nicht verlauten soll, auch nur irgendeine "zu lange" Methode nur der check styles wegen genauer begründen zu müssen.
Eher sind die einzusetzenden check styles zu begründen - möchte man nicht dass ich diese einfach ignorierend übergehe....
Das Sinn oder Unsinn machen wir halt klar an der Lesbarkeit / Verständlichkeit ab. Die "Regeln" geben nur Hinweise. Entscheidend ist das Code Review, und da ist es dann aber tatsächlich so, das Abweichungen erläutert werden.
Aus dem Grund wird oft mal etwas umgeschrieben, ob wohl es nicht zwingend notwendig ist, denn in diesem Fall mit den langen Funktionen ist es ebenso schnell da eine oder mehrere Funktionen zu erstellen wie später dazu etwas zu sagen.
Eine 200 Zeilen Funktion kann ich mir nicht vorstellen. Ich kann mir auch im Augenblick keinen Extremfall vorstellen, bei dem das notwendig sein könnte. Die etwas längere Funktion z.B. auf Grund einer switch Anweisung (Switch hat ohne case in java 2 Zeilen) und pro case kommen dann 1. case, 2. Befehl / Aufruf 3. break;. 4. Leerzeile -> 4 Zeilen dazu. Ok, Wenn man nur Code Zeilen zählt, dann wird die Leerzeile und die } nicht gezählt, aber man erkennt, dass es hier schwer ist, etwas zu machen.
Und klar: Man kann vieles in eine Zeile schreiben: "case x: doSomething(); break;" aber Ziel ist die Lesbarkeit und da wollen wir nur einen Befehl pro Zeile. (Typische Ausnahme wäre die Validierung, denn da haben wir dasganze if inc. throw Anweisung in einer Zeile.)
Ebenso sollte ja auch eine Zeile nicht zu lang sein. Daher auch oft die Auftrennung in mehrere Zeilen wenn man so typische Builder Aufrufketten hat. Typisches Beispiel, das mir da einfällt, wäre bei der Spring Security:
UserDetails user =
User.withDefaultPasswordEncoder()
.username("user")
.password("password")
.roles("USER")
.build();
Also das oberste Ziel ist immer die Lesbarkeit. Es geht hier nicht darum, Funktionen auf Zwang klein zu bekommen.
(Das erinnert mich an einen Perl Entwickler, den ich mal kennen gelernt habe. Die Kunst ein Perl Script in < 5 Zeilen zu schreiben. Eine Zeile ist ja in der Länge auch nicht begrenzt
)
Die Kritikpunkte an Kommentaren teile ich größtenteils.
Meist sind die Kommentare völlig unnütz (if (i == 1)//ob i gleich 1 ist), dann gehen sie beim nächsten Refactoring kaputt (if (i >= 1)//ob i gleich 1 ist) und wenn sie doch mal nützlich sind, sind sie besser als Methodenname aufgehoben (if (b != null && b.i == 1 && b.xyz() || b.zyx())//validate b). Der Anfänger-Bereich hier ist oft und wunderbares Beispiel dafür...
Ja, also erst zu dem, was ich rausgelöscht habe: Die Dokumentation der API Schnittstelle (JavaDoc und co) zählt hier nicht als Kommentar, der den Code selbst erläutert sondern das ist ja mehr die Erstellung einer Dokumentation.
Und In Code Kommentare dürfen nicht wiedergeben, was der Code macht (das sieht man ja am Code) sondern es muss klar sagen, wieso das notwendig ist. Wenn also irgend etwas sich anders verhält als erwartet (weil die Dokumentation falsch oder unklar war): Da macht ein Kommentar auf jeden Fall Sinn und rechtfertigt manchmal sogar noch einen extra Abschnitt in der Dokumentation. Aber ich gebe Dir durchaus Recht: Der Kommentar
// validating Arguments macht nicht wirklich Sinn, wenn dann klar ersichtlich ein Block kommt mit Validierungsbefehlen.... Damit habe ich sogar ein super Beispiel für Dich gebracht bezüglich: Ist doch eigentlich unnötig.
Ist aber auch wieder ein Zeichen dafür, dass hier vieles eben Absprache in einem Team ist. Das Team muss wissen, was es erwartet.
Fängt ja schon mit der Namensgebung an. Wie schreibe ich was? Für APIs gibt es oft styling guides. Da sind sich dann meist alle einig. Wobei ein Team, das in erster Linie C++ entwickelt, evtl. doch noch Kürzel für Typen haben will bei Variablen und Funktionen (Wäre ja legitim. Die sind es halt so gewohnt. Für die wird der Code so lesbarer sein.)
Aber typische Frage bei .Net war z.B. private Instanzvariablen. Da die nicht sichtbar sind nach außen, hat Microsoft hier nichts vorgegeben. Bei uns sind solche Fields (.Net Name für eine Instanzvariable) dann immer mit _ und kleingeschrieben. Der typische Java Code mit Getter / Setter wäre in .Net dann:
private int _someVariable;
public int GetSomeVatiable()
{
return _someVariable;
}
public void SetSomeVariable(int someVariable)
{
_someVariable = someVariable;
}
// Natürlich macht das so niemand. .Net hat Properties:
public int someProperty { get; set; }
Aber üblich ist auch z.B. der Prefix m_. Manche machen es auch ganz ohne Prefix.
Also mal von unterschiedlicher Schreibweise (Methoden sind PascalCase und nicht camelCase) erkennt man auch, dass hier keine Instanzvariable von einem Argument versteckt wird. Also kein
this.someVariable = someVariable; was ich immer in Java schrecklich finde.
(Setzt ihr eigentlich Lombok ein um das Thema Getter/Setter/hashCode/equals abzufrühstücken?)
Also man kann hier wirklich sehr viel schreiben. Interessant ist, dass es nicht wirklich ein "Richtig" oder "Falsch" gibt. Es gibt aber sehr wohl Anforderungen. Das kann in Schule / Studium der Lehrer/Dozent/Professor sein, der es halt auf eine bestimmte Art haben will und um Job ist es dann ggf. das Team. (Oder so man Einzelkämpfer ist, dann man selbst. Aber man sollte da durchaus auch selbst Wert drauf legen, wenn es keinen Zwang von außen gibt
)
Soviel einfach noch einmal von meiner Seite aus...
