Code Self Study Forum

Preferred Line Length in Code?

Does anyone have a preference about line length in computer code?

It looks like the typical 80-column recommendation goes back to 1928. Linus Torvalds suggested extending it to 132. (More details here.)

I’m thinking about switching my editor’s guideline from 80 to 100, because it’s a little annoying when my text goes over the line in my editor. It’s usually only happens when my comments have a long URL in them or when I’m building long, single-line strings.

For now, I put this in my .vimrc to highlight both the 80th and 100th column:

set colorcolumn=80,100

and a tox.ini in my projects to stop the Python linter from complaining:

max-line-length = 160

Just checked the file I had open in my editor. The line is 10723 characters. :man_shrugging:

Honestly, I toggle between line wrap - no line wrap (alt+z) in visual studio so it doesn’t bother me too much.

Sometimes I inline a lot of code…so that is why. Looking to clean things up a bit later. Maybe a shorter line lentgh encourages eloquence…

1 Like

I just updated my .vimrc to put a single guideline at column 97 and it still fits when splitting the screen. (The 100th column is off the screen.)

1 Like

I’ve toyed around with this too and eventually landed on using two guidelines: one at 80 and another at 120. I treat the 80 as a friendly suggestion and the 120 as a wrap. This works pretty well because it’s a reasonable length for the screens I use, and when I revisit code in Gitlab, keeping it under 120 makes it easy to read in the browser.

An 80 character limit doesn’t make a lot of sense anymore, imo. I feel like it discourages some really useful practices like clear and descriptive variable names. If I’m trying to stay under 80 characters, I find myself using more generic variables, and I pay the price a few months later when I’m ready to extend that older code.

1 Like

This is a big question, especially when you’re coding in groups or at a big company somewhere. Personally, it feels like it’s language-dependent. Python’s a bit fussy with formatting so it wants what it wants.

Most other languages these days don’t mind so much.

I wrote an article which to me applies to the topic. I prefer creating two big columns within most languages I do. My preferred 2nd-column setting is 45 characters over. See Figure 2 of that article to see what I’m talking about. In short, assignments force the use of that second column; all assignments may be quickly identified.

Obviously, this can create longer lines in many cases. I tend to promote adding a third column over around 70 perhaps for the beginning of line-specific comments.

Because of the squash-for-readability rule, this then makes some lines longer than you’d otherwise have. The upside is that you usually then get to read an entire function within one screenful (vertically).

1 Like

For JavaScript, instead of eslint I’ve been putting a .prettierrc file in every project with these settings:

    "endOfLine": "lf",
    "semi": true,
    "singleQuote": false,
    "tabWidth": 4,
    "trailingComma": "es5"

Prettier isn’t perfect, but it’s good enough, and I can press a key to reformat the file. My main goal is having it be skimmable and avoiding too much thinking about it. :slight_smile:

Here’s what their sample code looks like with those settings:

function HelloWorld({
    greeting = "hello",
    greeted = '"World"',
    silent = false,
}) {
    if (!greeting) {
        return null;

    // TODO: Don't use random in render
    let num = Math.floor(Math.random() * 1e7)
        .replace(/\.\d+/gi, "");

    return (
            title={`You are visitor number ${num}`}
                {greeting.slice(0, 1).toUpperCase() +
            {greeting.endsWith(",") ? (
                " "
            ) : (
                <span style={{ color: "grey" }}>", "</span>
            {silent ? "." : "!"}

I think I prefer one-line/early exits these days.

    if (!greeting) { return null; }


I’m just getting to the point where I don’t love the real estate taken up by simple if/exit statement constructs.