Nimmt man an man hat eine sehr lange Methode, die in ihrem Workflow aber einmalig ist. Aber man könnte den Code in verschiedene Bereiche(ca. 5) aufteilen. Die Bereiche selbst sind komplett unabhängig voneinander.

Imho sollte man die Bereiche in Methoden auslagern, damit man nicht den Überblick verliert und sich nicht Alles anschauen muss wenn man nur einen Teil ändern will.
Ein Kollege ist der Meinung, dass man das nicht machen soll, weil der Code an keiner anderen Stelle benutzt wird und dass man dann am Ende 100 Methoden hat und man müsste sie sich eh anschauen um zu verstehen was da gemacht wird.

Wie seht ihr das? Gibt es da best-practices dazu oder muss man das von Fall zu Fall unterscheiden?

Nimmt man an man hat eine sehr lange Methode, die in ihrem Workflow aber einmalig ist. Aber man könnte den Code in verschiedene Bereiche(ca. 5) aufteilen. Die Bereiche selbst sind komplett unabhängig voneinander.

Dann gubt es keinen Grund die Methode nicht aufzuteilen. Siehe
Single Responsibility Principle Eine Methode/Klasse sollte nut einen Grund haben geändert zu werden. Oder anders: Wenn du eine Methode beschreibst und dabei ein Bindewort (und / oder) verwendest, ist das ein Grund diese aufzuteilen.

Es ist dabei egal, wie oft diese Verwendet wird. Es geht auch um die Übersicht im Code.

oder muss man das von Fall zu Fall unterscheiden?

Das muss man auf jeden Fall ;)

Die Bereiche selbst sind komplett unabhängig voneinander.

Wenn die Bereiche unabhängig sind dann lagere sie aus. Die Gründe für die Auslagerung sind dass der Code somit besser Wartbar wird da die unabhängigen Teile einzeln bearbeitet werden können und nur die Signatur der Methode der gleich bleiben muss.

Ausgelagert werden kann zB in eine private Methode denn somit sieht die Klasse von Außen nicht anders aus.

Ich finde da die Prinzipien vom "clean code development" sehr passend, in den ersten Regeln steht schon geschrieben "dont repeat yourself", und da sind sicher auch Teile in der "100Methoden-Methode" dabei, die man sicher mehr als einmal nutzen kann/will.

Es geht auch um die Übersicht im Code.

Sicher, doch kann darunter auch schon die Übersichtlichkeit leiden.

Aber man könnte den Code in verschiedene Bereiche(ca. 5) aufteilen. Die Bereiche selbst sind komplett unabhängig voneinander.

Es bleibt eine Einzelfallabwägung. Entscheidend wäre für mich, wie die Gesamtheit der Projektmitarbeiter es bewertet. Finden mehrheitlich die Leute es hilfreicher, die 5 Bereiche in Methoden auszulagen, dann sollte es getan werden.
Entspricht es aber der Arbeitsweise der Firma, dass alles, was nicht mehr als einmal benötigt wird, auch nicht ausgelagert wird, dann würde ich mich daran halten - Clean Code hin oder her, denn am Ende verläßt du die Firma und keiner kommt mit deinem "Clean Code" Aufbau zu Recht.
Auch wenn alles in einer Methode verbleibt, ist es nicht ausgeschlossen "sauberen Code" zu schreiben.

Auf jeden Fall sollte man deswegen keine Grundsatzdiskussion in einer Firma anfangen, es sei der Projektleiter erwägt, die Arbeitsweise, den Programmierstil etc. zur Diskussion zu stellen - dann kannst du mit deinen Argumenten trumpfen.

Ich bin für die Aufteilung wenn sie sinnvoll ist, und das ist meistens der Fall.

Schon wenn es erforderlich scheint, ein Kommentar einzufügen um den Abschnitt zu erklären, sollte eine Methode mit sinnvollen Namen den Kommentar und Code des Abschnitts ersetzen.

Die Übersichtlichkeit wird verbessert indem viele Variablen nicht mehr benötigt werden und die Schachtelungstiefe geringer wird.

Nächster Punkt ist die Testbarkeit der einzelnen Abschnitte, indem sinnvollere Testfälle oder sogar eine bessere Abdeckung erreicht wird.

... insgesamt frei nach den Gründen für Refactoring (Martin Fowler, Joshua Kerievsky): Vermeidung von Redundanzen, Übersichtlichkeit, Erweiterbarkeit, Verständlichkeit, schneller Fehler finden, schlechtes Design bremst, ...

Etwas Erfahrung macht das ganze sehr effektiv. Als Tools helfen auch DevExpress "RefactorPro" oder JetBrains "Resharper"

Noch ein Zitat:

"Jeder Dummkopf kann Code schreiben, den ein Computer versteht. Gute Programmierer schreiben Code den Menschen verstehen"

Das Aufteilen in einzelne Methoden hat noch einen weiteren entscheidenden Vorteil.

Ihr sprecht hier über ein Design Pattern, das sogenannte Composite Method oder Composed Method Pattern.

Neben den bereits erwähnten Vorteilen fördert die Aufteilung das Schreiben von besserem Code (mehr objektorientiert, kürzere Methoden) IN DER ZUKUNFT, da eben diese Methoden der ganzen Klasse zur Verfügung stehen (oder bei Bedarf auch anderen Klassen durch public Sichtbarkeit) ... Untermethoden, die in anderen Methoden "verankert" sind, ist so etwas nicht möglich.

Ach so, ich möchte noch etwas hinzufügen:

Ich denke nicht, dass dies eine Frage des "Geschmacks" ist, was einem besser gefällt. Sollte diese Vorgehensweise in viel zu vielen Methoden enden, so ist höchstwahrscheinlich zu überdenken, ob die Klasse nicht zu viel erledigen muss und aufgesplittet werden sollte.