encoder: spagetticode in methoden strukturieren & ordnen

Beitrag lesen

Ich habe schon Code gesehen der mehrere tausend Zeilen pro Klasse hatte, da sollte man mehrere Klassen draus machen.
Ich habe Methoden gesehen die etliche Seiten zu scrollen hatten, die sollte man dringend aufteilen.

Andrerseits wenn eine Methode über drei Seiten geht, aber trotzdem gut strukturiert und nachvollziehbar ist, kann das in bestimmten Fällen auch sinnvoll sein. Alles auseinander zu reißen, viele Parameter an einzelne Methoden zu übergeben und beim lesen dauernd hin und her springen zu müssen ist ja auch nicht per Definition schön.
Der von Rolf erwähnte Code mit nur max. 4 Zeilen pro Methode mag schön aussehen, aber ist er auch nachvollziehbar? Es gibt Dinge die brauchen nunmal Code, was versteht man davon noch wenn man nach bereits vier Zeilen schon wieder woanders hin springen muss? Was passiert zum Beispiel mit einem case Statement mit vielen Fällen?
Also wo will man dann eine Zahl als Grenze fürs meckern festlegen?

Solche fest gezurrten Regeln verfehlen den Sinn der Sache. Vor allem wenn dann noch absolute Zahlen im Spiel sind. Sich gedankenlos daran zu halten macht nichts besser. Da geht es nicht anders als dass es eben länger wird.

Meldungen zum Programmierstil nutze ich höchstens als Hinweis, manchmal sind sie ja wirklich hilfreich. Manchmal aber auch nicht, dann nehme ich mir die Freiheit sie zu ignorieren oder auszuschalten.