I have started to move in the other direction for C#. A long sequence of code that flows in one direction should be kept in one method if possible. Good reasons to break up a method are things that are
not readability but other things such as re-use testability. If the methods are only called in one place and not performing a piece of work that is testable, then they shouldn’t be methods.
But
DoAll() {
DoA();
DoB();
DoC();
}
Is simply not better in any way than
DoAll() {
// A
...
// B
...
// C
...
}
Private methods will blur this somewhat. The key to readability is not having to jump around. Ideally of course methods are both short
and reusable, readable without jumping etc, but given the choice between a 100 line method or the same code broken into 10 methods of 15 lines each (yes, more lines), where each method is only called once from a main method, I’d rather read the first. The 100 lines might indicate some
other problem with the api (a chatty Dx12/win32-like API for example).
This obviously varies from case to case, I think one of the worse things a team can do is enforce hard rules that invariably lead to “style rule-induced damage”.
But
Is simply not better in any way than Private methods will blur this somewhat. The key to readability is not having to jump around. Ideally of course methods are both short and reusable, readable without jumping etc, but given the choice between a 100 line method or the same code broken into 10 methods of 15 lines each (yes, more lines), where each method is only called once from a main method, I’d rather read the first. The 100 lines might indicate some other problem with the api (a chatty Dx12/win32-like API for example).This obviously varies from case to case, I think one of the worse things a team can do is enforce hard rules that invariably lead to “style rule-induced damage”.