Why stick to an arbitrary max length at all?
Make lines as long as is natural for the code without having to horizontally scroll.

120
Mainly I am doing Java and a little HTML and CSS.

Just use the horizontal space provided by modern widescreens of huge size :-)

We had a discussion and settled on 100.

We all use the same size main monitors and same IDE with a standardized settings file. To get max line length we took the number of characters that can fit on a line without horizontal scrolling and took a bit off for indentation.

I go with 100, but still try to fit comments into 80 because I find those are more difficult to read when they break the line or scroll.

120 that's what we use in our company, and I think it fits most of the modern screen sizes

I wouldn't say that I'm sticking to it religiously, just really wanted to know whether that was bugging just me or not and what others in community are using.

I get my favourite readability with 80 :)

80

It's a nice way to have a constraint in your code not to go deep in callbacks or nested statements, not only long variable or method names. These days with wide screen monitors my preference is to have 120 as a soft limit, nicely fits my code and surrounding tools from IDE in one screen. Also fits in GitHub pull request side by side view. It's all about readability, as long as it is not hardly enforced without a valid reason.

For Java, I usually go with 150-200 characters. For Python and bash, I'm in the 80 character camp.

120 for typically longer languages (ts, html). 80 for shell, css, etc. That's mainly just a soft limit so I can fit my editor on half of most screen sizes without losing anything, and the 80 is nice for ssh sessions or vim.

I tend to start it at 100 in Code Style checkers, but I never let that particular rule rise to the level of "throw an error and refuse to build/compile" that some code style rules might deserve.

This is as someone who codes these days primarily in Javascript, followed closely by PHP. But it seems like a fine rule when I've dipped into C#, C++, and Python.

I stick to about 100 chars per line. If it looks like I have to go multiline I'll limit to around 90, but I'm flexible based on how the code looks. I find these limits generally fit within most screen and font sizes I've seen colleagues use. Beyond 100 also starts to become a readability issue with the code -- too much to digest at once.

For comments though I have noline limit and rely on wrapping to format the blocks. It's annoying to edit text that has line breaks in it that aren't meant for paragraph breaks.

Seems like 120 is a middle

I use 120 characters. Almost all displays are able to handle this width. Realistically, I think that you need to do what makes the code clean and readable. What that means is largely decided by the people that are reading your code.

That being said, I think that the number 80 is antiquated and 120 is better for modern development.

We use 120 in our tslint, but there are files where we use tslint overrides - for example ngrx/store selectors sometimes get longish names, and when wrapped, they actually ruin code readability and optical consistency.

Just because machines and tooling can break down constraints, e.g. bigger monitor, better IDEs, etc. that doesn't mean we should neglect the human factor. I think there is a reason why websites, books, or other heavy text mediums have a line length constraint and I think it is because it's easier for humans to read.

baymard.com/blog/line-length-reada...

Too wide – if a line of text is too long the reader’s eyes will have a hard time focusing on the text. This is because the line length makes it difficult to gauge where the line starts and ends. Furthermore it can be difficult to continue onto the correct line in large blocks of text.

Too narrow – if a line is too short the eye will have to travel back too often, breaking the reader’s rhythm. Too short lines also tend to stress readers, making them begin on the next line before finishing the current one (hence skipping potentially important words).

Every now and then, I think it's ok to break the line length rule by a few characters but you should also consider if there is a better way to shorten the long line length.

I noticed that code is much easier to read if it's less than 80 characters wide, so I stick very strictly to that.

I see a lot of 120 in the comments, that's just too wide for my brain to read at once.

No max line length whatsoever. The 80 characters limit is just cargo cult.

I have VSCode set to have a vertical bar at the 75 character mark. I keep it more as a guide rather than a hard rule. If it's going to be past the line by a few words I will then make a line break.
I keep my editor font size pretty large and on my 1080p monitor with the editor taking half the screen 75 characters is off the edge of the screen.

For code, I tend to use 80 as a soft limit and 132 as a hard limit (with rare exceptions): 80 so that I can easily have two or more views side by side, and also in the very rare case that I need to put the code on paper, and 132 so it doesn't get too unwieldy (I think 132 was the traditional limit for landscape paper, too). I also tend to code with line wrapping enabled, so horizontal scrolling is not usually an issue.

For in-code documentation and comments, as well as plain text documents, 72 because that's a comfortable width to read, especially in a terminal.

For more text-centric documents that are meant to be rendered like HTML or LaTeX, I don't usually impose a limit because it's awkward to have to readjust paragraphs just so they fit in a certain width, and the source isn't meant to be looked at by the end user. Line wrapping is a must here.

Not exactly an answer to your question, but an amusing anecdote. I inherited a codebase a few years ago where a previous developer working under a tight deadline was trying to restore some default Bootstrap styling in a CSS file that had been overridden in other places. The "solution" was to paste the entire minified Bootstrap CSS into the middle of the file. So the longest line length in that code was tens of thousands of characters.

It was fun seeing how different editors dealt with that.

Its important the max length when you work with other coders. The code style is more consistent specially if you are using a linter.

What if some one will have a class name 101 chars long? :)

It's also for things like lines being used in email subjects or tickets, and if you spread your logic out across lines, diffs and patches (and therefore your whole VCS) work better. Having overly-long lines isn't the end of the world, but it can be a bit of a smell.

80 is a guide. It's still used as a hard limit (sometimes 79) in a few places and there's no real reason not to use it where you can.

Sometimes languages are verbose, or variable names cumbersome, but that's why it's a guide rather than a rule. On the other hand, it's a small smell if you can't keep your lines to the same length as other developers on the same project...

I like splitting my logic up so that it's easier to remove a line at a time, and I dislike trying to read long, dense paragraphs of any text - let alone code.

Keep calm and use Prettier
Well this helped to get over it and now I use 80.

It helps because:

• I can have other things open vertically along side code and still see the whole code.
• Read the code on GitHub without horizontal scroll.
• If you are used to writing stuff in straight line you can still write it. It will be auto fixed during commit (using pre-commit hook with prettier)

I stick with the ideas put in the PSR-2 :

github.com/php-fig/fig-standards/b...

"There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less."

It always works for me and my style.

120 chars in Python. I find this most useful because of the fact that whitespace matters, and to continue code lines they have to be in parentheses, brackets, or another enclosing language structure, or alternatively (in the worst case) you have to backslash to continue a line. I never backslash Python anymore, I opt to put the code block in parenthesis if I need a line break.

I started in python and they recommend 80 dont know why but it just stuck. Now anything else feels weird lol.

as many ppl mentioned, we are at 120 for both, typescript and python. works pretty well :)

I use 120. I still try to keep it at 80 so that I can view it in a command prompt (if needed) without resizing, although sometimes for things like method declarations, deep indentation (especially in languages that don't have good error handling), and nested loops, the extra bump up to 120 is very convenient.

If your code is ever longer than 120, it's probably spaghetti and needs to be refactored.

I stick to 80 and I'm a bit of a stickler about it - I use a lot of panes when editing, so I'll have multiple files sitting side by side; even on a widescreen monitor, sticking to 80 means I can have 3 panes across instead of just 1 or 2.

With the example you used, you can rewrite to fit in 80 chars comfortably just by ditching fat arrow syntax (which is also a handy way of announcing "this is a pure function" to your teammates).

export function setCommunity(id: string): SetCommunityAction {
    return {
        type: '@@community/SET_COMMUNITY',
        payload: { id }
    }
}

...assuming ActionCreator<X> just means "a function that returns an x"; I don't know the context of the code. In any case, my point is that the response to a line-length code smell shouldn't just be to see if you can put your line breaks in different places; it's to see if there's a better way to write that line that expresses your idea more clearly.

80 column rule is inherited from olden days where punch cards had 80 columns.

Then back when I was in college, my CS professor urged students stick to 80 columns due to small monitor screen sizes. (He used XEmacs with 2 windows on each side mostly).

Given today's monitor sizes and absence of punch cards, there is no reason to stick to the 80 column rule.

Alas, I've seen people writing past 200 columns but that's just pushing it IMHO.

Nowadays, column limit depends on how you or your teammates define them to be.

I usually don't go past 120 columns (using VS Editor Guidelines plugin).

Does anyone know of a VS2019 or VS Code extension (other than Resharper) that automatically can hard wrap long lines by a set limit?

I really would love to limit myself to 78 characters. At first, I'm using 80, because of, when I open a terminal, I always found that by default it opened for 80 characters (I know I can resize it, duh..). But, when editing in nano, using 80 characters will wrap/scroll the line. 78 characters are my chosen default.

The language I use is Go, and it's pretty good for the limitation I enforce myself. But, actually, I'm considering to move to 120. Why? Because in my screen, the editor minus the left panel (project, tabs, etc) consists of around 120 characters.