Why use a maximum line length at all?

There are many discussions about what the maximum line length should be (80, 100, 132 are all popular).

But this all assumes there needs to be a maximum line length at all.

I can see why many people don't like horizontal scrolling. But why not let the editor do the line wrapping?

I can see two options:

Lines should be wrapped at specific points to be at all readable: this would probably need some improvements in common editors, but I'm sure that if the rules for readable wrapping are that specific, they could be expressed in code.
It doesn't matter much where lines are wrapped: that's really easy then.

The advantage of letting the editor do the wrapping seems obvious: people can use whatever line length they like (even switching to shorter lines in diff-mode or something).

Responses(3)

For me these are the reasons I prefer to have a maximum line length and no wrapping at all:

1 dimension is a lot easier to handle, scrolling-wise
It is a lot faster to only read in one direction (ask any UI/UX designer about why they put form labels above or inside inputs (for example material design), never next to them)
All our tools are optimized for lines, not columns.
I use new-lines for better version control. Wrapping in the editor will prevent any chance of diffing sanely. Just think of solving merge conflicts with auto-wrap and long lines instead of a vertical arrangement urgghhhhh
I want control over my formatting. If I write a long line and it is auto-wrapped in my view, but in the file still one long line, I might have different experiences based on the editor or IDE I open the file with, so I (and others) will get confused
I can have very situation-specific code formatting.
Scrolling to the left will result in me not seing the other lines (in full), so I have a lot of scrolling back and forth to do, even though all code might fit on my screen if only it had been formatted correctly. Assuming I do not use an editor or IDE with your uber-cool auto-wrap feature, because it simply is not available for me. And no, I will not switch my tools just because someone does not want to do proper code formatting.

Marco Alka Given it's CSR using dipshit made-up tags, there's no way in HELL I'd ever allow that onto ANY project I'd EVER create.

Joe forbid you just type in an <input> and <label> tag normally then target the semantic markup. NO, instead let's just crap all over HTML with invalid made up bullshit tags that have ZERO semantics and REQUIRES client-side JavaScript to even function. 100% Grade A farm fresh manure.

But that's the mouth-breathing asshat broken half-witted idiocy of "Polymer" in a nutshell. POSTER CHILD for everything wrong with modern development and how to tell users to go f*** themselves.

Bah, who are we kidding, that's EVERYTHING on the nube predating scam artists hoo-hah that is webcomponents.org -- it's like the worst of dynamic drive or W3Fools dialed up to eleven. Developers are dumber for this that type of crap even EXISTING!

-I use (for the most part) a 76 character line for code blocks, but when working in HTML I do NOT force word-wraps on paragraph content / flow text.

This mix and match when done consistently makes it easier to find your block level openings and closures, reducing the chance of making mistakes.

The choice of 76 charactes is common for 80 character disply because:

1) Some editors add line-draw characters to pretend there's a window edge, so you subtract 2.

2) Then you have the scrollbar to subtract 1 more

3) Any good engineer is a wee bit conservative so you subtract an extra 1 for good measure. (such a safety margin is called "Mr. Scott'ing")

Another reason is that not all terminal/shell editors even provide wordwrapping, at least not in an easily controllable fashion. This can be exacerbated even further

I'll often hear people say "but I have a widescreen that can display 200 or more characters, so what's it matter" -- typically such folks derp along with all their editor windows open maximized using some garbage tabbed editor, something I personally consider a colossal step backwards in functionality! Yes, that's right, I think tabbed editors are garbage.

When working in HTML, CSS, and JavaScript it is often EXTREMELY useful to have them open side-by-side-by-side in separate windows, or even spanning multiple displays. This is something that tabbed editors crapping the code into a single window often fail miserably at. On my 28" 2560x1440 primary display I regularly have a PHP file (which also has my markup) or HTML next to the CSS and JavaScript each taking up a third of the display horizontally... with the larger font size I prefer this works out to leaving around 77 to 78 characters free on each editor window after window chrome is accounted for.

Manually inserting line-breaks and tabs often just results in more legible and easier to follow code. Like with long IF statements word-wrapping just gets hard to follow. The same can often be said of debugging where it's a lot easier to find "line 128" than it is to find "line 60 character 1802".

I mean what's going to be easier to follow or debug?

if ((_.Node.mask(element, nodeMask) && !callback(element)) || (element.firstChild && !_.Node.eachAll(element, callback, nodeMask))) return false;

or:

if (
    (
        _.Node.mask(element, nodeMask) &&
        !callback(element)
    ) || (
        element.firstChild &&
        !_.Node.eachAll(element, callback, nodeMask)
    )
) return false;

My money is on the latter.

Similarly related is the derpitude of putting attribute/value pairs onto single lines in CSS... making it difficult to tell properties FROM their values at a glance. THIS:

h1 a { display:block; padding:0.4em 0.33em 0.45em 0; letter-spacing:1px; text-decoration:none; color:#FFF; text-shadow: 0 0 2px #FFF, 0 0 0.2em #000, 0.05em 0.05em 0.1em #000, 0.1em 0.1em 0.2em rgba(0,0,0,0.5); }

Is outright idiotic compared to this:

h1 a {
    display:block;
    padding:0.4em 0.33em 0.45em 0;
    letter-spacing:1px;
    text-decoration:none;
    color:#FFF;
    text-shadow:
        0 0 2px #FFF,
        0 0 0.2em #000,
        0.05em 0.05em 0.1em #000,
        0.1em 0.1em 0.2em rgba(0,0,0,0.5);
}

It's just easier to follow. Good formatting habits results in easier to digest, easier to debug, and easier to maintain codebases. ANYONE telling you otherwise probably isn't qualified to write a single blasted line of code!

It is just one of the many concepts I had drilled into me when I started programming four decades ago.

Well formatted code is easier to follow. [TAB] and [ENTER] are your friend.
Verbose code with meaningful variable, procedure, and method names require fewer comments and documentation.
The less code you use, the less there is to break
If you can't document it, you probably shouldn't have written it.
NEVER make assumptions about who the end user is or what they are or aren't capable of.

That last one having a modern equivalent in web development; This is the Internet, the only thing you can know for certain about a website is that you cannot be certain who is going to visit your website...

Thread

Why use a maximum line length at all?

Responses(3)

Recent threads

Search Hashnode

Why use a maximum line length at all?

Responses(3)

Recent threads