What is it about JavaScript that makes people want to have hugely long lines?


#1

Currently for performance reasons, Atom only highlights the first 100 tokens per line. (Though @postcasio has a package to modify that value if you want.) One of the ways I help out in the Atom repos is I close obvious duplicate bugs. I have had to close way more duplicates of atom/atom#1667 on the language-javascript repo than any other language package.

What is it about JavaScript that drives its users to create these insanely long lines, typically string or regex literals?

(Note: This is an honest question, not JavaScript snark. Language design is something I like thinking about and I’m wondering if it is an issue with the JavaScript language or the way JavaScript is typically used that causes this problem.)


#2

One problem is that JavaScript doesn’t support free spacing/comments in regex, which makes it easier to split expressions up into multiple lines. Without it, to nicely format a long regex you have to build it in a string, which is very ugly… so people just leave it as a long line. Which isn’t usually a big problem when it’s not very common.


#3

Don’t forget that there’s also minified code that end up in a single line (which doesn’t make sense when you think about it). Sometime I prefer to open a minified file in an editor rather than in the devtools so that I can use my favorite tools to dig into it.

Otherwise, since my python days I took the habit of following the 80 chars limit most of the time (unless when it makes the code less readable) so I haven’t had this problem recently.


#4

You can use a backslash at the end of the line …

/this is a\
long regex/

#5

I’m a newbie, self-taught JavaScript programmer, so please excuse my ignorance. What’s wrong with long lines, and why doesn’t everyone use word wrap?


#6

Word wrap makes files virtually unreadable, at least to me. I read code and parse functions and blocks by following the indentation on the left. This is especially true in coffeescript.


#7

Compare:

// one line, not really long
if ( some_function(x) == another_function(y) || 3+4*5 < 6 || is_nifty() ) {
    ...do stuff...
}

// multiple lines
if ( some_function(x) == another_function(y)
    || 3 + 4 * 5 < 6
    || is_nifty() )
{
    ... do stuff...
}

With the first version, you have to stare at the condition quite closely to make out what it means. You have to read for a while to figure out that it comprises three subexpressions that are connected via Boolean or.

But if you look at the second version, you can quickly see: Oh, the if condition seems to have three parts, connected via Boolean or. And then you can proceed to study each of the three parts.

In the second version, I also used a little trick of mine to put the opening brace in the next line. This way, once you see the “if”, you can scan down and you can easily find the end of the condition (it’s where the brace is). So if you want to look at the condition, you know which lines to look at, and if you want to look at the body, you know which lines to skip.

Different people have different opinions, and some people think that the opening brace should go after the closing parenthesis of the condition, but oh, well.

And that first version is just 75 characters!

Another example is to look at a complex function call:

// All one line.  How many arguments does this function have?
some_function(3 * f(x, y), z, g(4 + 5, 6 / 7, k(8 * 9, whoozle)), 11);

// Now it's split.  Now you know.  Or at least it's easy to find out.
// I am splitting one particularly long argument, too.
some_function(
    3 * f(x, y),
    z,
    g(4 + 5,
        6 / 7,
        k(8 * 9, whoozle)),
    11);

The above one-liner is 71 characters. Of course, the multi-liner looks weird, too, because this was a pathological example. But I think you can see that splitting into multiple lines really helps.

Would word-wrap help here at all? It wouldn’t help at all.


#8

When word-wrap happens, the wrapped line should be indented like a continued line.

Hm. It’s a bit difficult to find a good example because often the indentation is driven by parentheses and the like. Let’s use short lines in this example. Suppose you wanted to split the following line into two manually:

if (some_condition) {
    return some_value || another_value || a_third_value;
}

Let’s say we use lines of 42 characters, because, face it, that must be the only possible answer. Now if you were to split the lines manually, you would get this:

if (some_condition) {
    return some_value || another_value ||
        a_third_value;
}

So, we are using four-space indentation here, the return is indented four spaces. So it seems prudent to indent a_third_value an additional four spaces.

And my proposal is that if you were to make the window narrow, so that word-wrap kicks in, it should do the same thing: the continuation line should be indented one more indentation step than the current line.

That still sucks, but it’s marginally better.


#9

I specifically talk about word wrap in my topic on separating display format from storage format:


#10

Because I love it and because I think every programmer should know it by heart:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea – let’s do more of those!

Emphasis’ mine.

Another way to put it should be:

Whatever is well conceived is clearly said. And the words to say it flow with ease.
Nicolas Despréaux

Long lines in code are like long sentences in prose, it only demonstrates the confusion in the mind of the writer.


#11

A nice side-benefit of manually indenting your code and making it more readable is that it forces your mind to look at the code in a slightly different way, which can help you find mistakes in your code or in your thinking. This has helped me catch mistakes with some frequency, but I mostly code automated test scripts so perhaps the effect is less pronounced when coding other things.