If you need to scroll to see a complete function then it is too long. Keep an idea as viewable on a single page. Functions can always be broken down and/or inlined.
Nice theory. Sometimes even works.
Sometimes doesn't work, and sometimes fails spectacularly. In my previous job, we had a 6000 line function. It was perfectly readable, mostly bug free (I remember funding one bug in it, not counting typos and superficial things), and the simplest way to structure the task. We seriously thought about breaking it up into two dozen functions, but then we decided that (a) the individual functions would no longer make sense, as they don't solve an identifiable and describable problem, but instead could only understood in the context of the larger function; (b) the big function carried a significant amount of internal state in it as local variables (all of which was actually needed, we audited that), and that meant that the smaller functions would all have very complex calls, with a dozen parameters; (c) the smaller functions having to change state of the larger function would have been hard to handle, either by using reference or pointer parameters, or packaging changes in complex (object) return types.
Admittedly, that is the extreme example, and I've never seen anything this complicated. But that function handled an extremely complicated work flow (which involved humans, hardware and software interacting).
Sure, we could have completely recoded it, for example into a state machine, with a pool of state at the center, and a variety of control flows (perhaps interlocked threads) handling the interactions. But orchestrating all these participants would have been hell, and bug prone.
If you've got an if/else construct that is longer than three choices then review it as a candidate for indexed jumps (either thru case/switch or via indexed function pointers)
Sometimes that works, and sometimes it is even idiomatic. Sometimes it is crazy, makes the code flow unreadable, and hides control in places where people will least expect it.
In your post, you are focused on code structures, such as long functions and if/else/while statement. I think what is actually more important is to look at data and state. What variables are in scope? Are there every any variables that are in scope (can be read or written) but their content is either undefined (for reading) or irrelevant (for writing)? Which pieces of code look at variables, and which pieces of code change them? And by this I don't so much mean local variables (the loop index "i" is not very important or dangerous), but variables that have longer lifetimes, that are kept in complex data structures or even globally.
Since the beginning of my career (nearly 50 years ago) I have been a proponent of Jackson Structured Programming, which had its bloom in the 70s in COBOL practice. If you know what data a program has in memory, and what that data means, and where it comes from and where it goes, you have won 90% of the war. The rest is then coding rather simple instruction flow.
Conserve vertical screen real-estate.
Do if (x) {fn()}
This one I completely agree with. Having as much code AS IS REASONABLE on the screen at once helps the brain see a bigger part of the picture, which helps it analyze the often complex job the code is doing. The issue here is "as is reasonable". I agree that wasting lines just on braces is bad. My favorite C style (which nobody else likes, but I can live with that):
C:
if (foo)
do_one();
else {
do_two_a();
do_two_b(); }
No curly braces needed for single line blocks, and put the necessary curly braces on the same line as the code they are grouping. This only works if you have a good linter that checks indentation, and you treat every indentation warning as an error that needs to be fixed immediately, before even attempting to compile.
On the other hand: If a piece of code consists of three blocks, each of which is 5 or 6 lines long, and they have identifiable different purposes, then "wasting space" on a blank line is a good idea, because it helps the brain see the structure right away. Similarly, a complex 30 lines of code deserves a 5-line comment at the top explaining what it does and why and how, even if that makes it not fit on a single screen any longer.
With modern monitors, a lot of these concerns are just not relevant any longer. Restricting the width of code to 80 characters is silly, 100 fits on most good computers (even laptops, with two source code windows side by side).
One thing I wonder about is why we haven't started using proportional fonts for coding. Clearly we need fixed-width spaces to get the indentation at the beginning of the line right, but after that, proportionally spaced characters are easier to read and more compact.
But I guess there will be people having reasons for that)
