I prefer the Python rule of 79 characters tops per line, but I lean more towards 120 characters. I think helper methods (private methods) are useful, but having a bunch of methods called one after the other like you point out seems pointless. My other rule of thumb is: DRY, if I'm repeating code, it should be a helper method. Otherwise if it's a one off method, it shouldn't be broken out unless it helps me follow the flow better.
About a year back I moved from 120 back down to 100. The rationale was that, even on a large monitor, it was difficult to fit multiple source files side-by-side at a font size I could read comfortably. On a laptop monitor, it was hopeless.
I also noticed, during code reviews, that people read and digest statements that are broken up into multiple lines much more carefully than they do compound statements that live on a single line. Leaving me to think that line width is not just an aesthetic matter. It's really a very impactful decision that can have an important, if subtle, influence on overall software quality.
> About a year back I moved from 120 back down to 100. The rationale was that, even on a large monitor, it was difficult to fit multiple source files side-by-side at a font size I could read comfortably. On a laptop monitor, it was hopeless.
It very much depends on the screen. With a 32 inch screen you can fit three 120-column views at the equivalent of 100 DPI at default zoom. Or even better, six 120x40 views.
Yeah that's one argument I have heard, I guess I try to go 79 and if it gets lost and I'm at 120 I am not gonna cry about it too much, but anything over 120 characters is pushing it. But yeah, some super long lines I try to bring back. I do know about the split screen thing since PEP-8 outlines some of these things for Python code and I've read a lot of articles about why PEP-8 makes sense.
