Repository navigation
meta: Are the limits on line length still necessary? #14176
Description
Activity
Refs (to compare with other popular guides): Airbnb
Quick anecdotal query into GitHub
100 (30 results): https://github.com/search?q=%22max-len+error+100%22&type=Code&utf8=%E2%9C%93
120 (1,678 results): https://github.com/search?q=%22max-len+error+100%22&type=Code&utf8=%E2%9C%93I have found this more and more irritating in code. If your editor wraps then I'm not sure what the benefit is. I'd be +1 on increasing it to 100/120.
For git I think it's different, the 50 char limit encourages people to be concise in the title, which is really helpful when you're doing a
git log --oneline. GitHub wraps the title at 72 chars, so we couldn't go beyond that anyway:
For the git body (and for
.mdfiles, anything that's flowing text really) I think the limit is helpful when reading it unformatted. If you google "best line length for readability" the answers are usually around 72 chars. I think we already don't apply that to URLs of course, so maybe being more flexible in what we care about is the key.I like the Airbnb style @vsemozhetbyt mentioned, ignoring strings and URLs (but not comments) makes sense:
'max-len': ['error', 100, 2, { ignoreUrls: true, ignoreComments: false, ignoreRegExpLiterals: true, ignoreStrings: true, ignoreTemplateLiterals: true, }],
re: git, http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
I don't agree that we have more screen space now, because once the screen got wider, it became possible to put up two tabs side-by-side, which is what I do, and assume most people do, and both are 90 chars wide, as it happens, on my monitor, leaving room if I wanted it for some kindof tool tray to the side.
IMO, most examples of long lines are either poorly written code, or because of long argument lists. With multi-arg functions and long descriptive names, there will always be wrapping, might as well wrap early (and hope people write functions with less args).
Its also hard to follow lines longer than 70 or 80 chars visually, which is why newspapers format text into short columns.
And diff tools do well with inter-line and not so well with inside-the-line text.
Etc, etc.
Reacted by Richard LauReacted by PharapOn the "annoying for those who don't have a wide screen" thing: Do you fall into that category?
This is my normal setup:
I'm sure there are ways I could get 10 chars extra but I don't think that is what we are talking about.
I don't mind 80+ lines when it is clear that no better alternative exists (such as URLs). However, in this case, I strongly believe better alternatives exist.
@AndreasMadsen (from #14173 (comment)), have you tried line wrapping? I often use a narrow editor, and I find the wrapping to be cleaner than what we do now:
Not saying wrapping fixes all problems obviously, just a suggestion.
Reacted by PharapI'd be +1 on extending the commit title to 72 columns, but prefer we keep the commit and code line lengths the same. I find that auto wrapping makes it more difficult to immediately see things the way sticking to a smaller line length does
I prefer the limits the way they are now.
Reacted by Tobias NießenI prefer the current limits as well.
Reacted by Tobias NießenAgree with 120 columns per code line.
Reacted by Pharaphave you tried line wrapping? I often use a narrow editor, and I find the wrapping to be cleaner than what we do now:
It looks like this. Honestly, I can't stand it and would rather scroll. Also, with an argument like that why have a limit at all.
I also prefer the current line length. Why, I feel 80 columns is already overly indulgent. When I was young we only had 72 columns and we were happy, we didn't know any better.
Reacted by Rich Trott, Richard Lau and Marko PappIn my VIM, I have an 80-column warning line and a 120-column error line. That means I usually keep it's length up to 80 and if necessary, it still can't longer than 120.
- The 50 char limit of the title is somewhat restrictive, I am ±0 on this, but I don't have a problem with keeping it as it is.
- 72 chars should be kept as they are IMO, that barely ever causes problems.
- I think lines with more than 100 characters are barely readable. The only reason to have such long lines is to include string literals etc., see Ignore template literals #14173. Everything else can comfortably be wrapped in JavaScript.
The 50 / 72 rule has historic president and many tools are built around them
I am -1 to changing our commit guidelines
I'm +1 to leaving as it is.
It's clear there is no consensus on making changes. I'll go ahead and close this out.
Reacted by Refael Ackermann
I wanted to start a discussion on why we're still enforcing them? Is it possible to extend the limits?
Especially the 80 char per code line. There are style guides that extend the limit to 120 chars, or make an exception for function calls with many arguments, and string literals.
I'm assuming originally it came from narrow terminal windows, and that it's been kept popular under the assumption that one line of code should not do too much. But sometimes it leads to very cumbersome constructs:
a random example taken from
./configure(that is actually a file that is not auto-linted.)while lines that do multiple operations are considered ok
Another example is documentation files, where we don't auto-lint so it's easy to find examples where it was not upheld. Also, AFAIK most editors can soft-wrap lines while files are anyway rendered to something prettier.
Ref: #8327