The tyranny of the Hollerith punched card
Personally, I agree with the author and generally have argued against hard line-length limits.  Today&#x27;s computers have different screen characteristics than even 15 years ago and we&#x27;re at a much greater loss of vertical length than horizontal length so it bugs me when I pull up code that has less-readable statements broken apart over ten lines, doing one thing, and leaving 80% of my screen empty when readability would have been improved by leaving parts of those ten lines on a single line.<p>I can understand the benefits, though, to having sane rules around &quot;how much can go in one line&quot;, I just think the overall width of a line is of way lower importance than breaking things up into logical parts -- especially in C# in code that avoids LINQ statements[1] where method chaining can result in some extremely wide, difficult to parse, code.  I write almost all of my software on a Widescreen 1080P display where vertical real-estate is vastly lacking and horizontal real-estate is greatly underutilized.  I use a pragmatic approach over artificial hard barriers and the assumption that I&#x27;ll be using my display to look at code the way I do 99% of the time - one or two code files on screen at a time (but almost always a single code file).<p>My code still tends to <i>mostly</i> prefer vertical orientation.  I use these simple rules:<p>(1) Avoid same-line chaining (Even &quot;ToList&quot; or &quot;ToArray&quot; gets its own line).  Line up the dots of the calls with the previous line&#x27;s dot to make it easy to see it&#x27;s a part of a chain.  This results in &quot;wider&quot; code but makes that code able to be parsed quickly while not wasting vertical space.<p>(2) Avoid more than one statement per line (conditionals excluded where readability requires -- doing if (isThis &amp;&amp; isThat &amp;&amp; string1==string2 &amp;&amp; string3==string4) would put the two string comparisons on two separate lines usually).<p>(3) Omit (yes, omit) braces for single statements that don&#x27;t have indented single statements below them.  This gets me yelled at sometimes, but my IDE enforces code formatting for me, so the drawbacks of &quot;accidentally having a statement appear to apply to a conditional that it doesn&#x27;t&quot; don&#x27;t happen and with the lack of newlines-for-newlines&#x27;-sake in my code, code that&#x27;s indented for branched statements is easily discernible from code that has a newline due to chaining or some other reason.<p>(4) Break the rules if readability is improved and avoid religious wars.<p>At the end of the day, I can live with nearly any code formatting ruleset.  I read code more than I write it and I end up reading code that follows a large variety of rules so I try not to be a pain in the ass about it.  If I haven&#x27;t been the most substantial contributor to a project, I follow the other person&#x27;s rules.  If I have, I <i>hope</i> that they&#x27;ll follow mine.  The result has been few, if any, arguments over &quot;tabs vs. spaces&quot; theology.<p>[1] I have never liked the LINQ statement format as I find it hard to follow &quot;What&#x27;s Being Done&quot; so I have, with rare exception, stuck with method chains.