This article was originally posted on June 5th 2018 at: https://nickjanetakis.com/blog/80-characters-per-line-is-a-standard-worth-sticking-to-even-...
For further actions, you may consider blocking this person and/or reporting abuse
We stick to 120 and it's working good for us, yes, screen can crop some chars in the end of the line, but it's usually some JSX attrs or something not very important at a glance. Also, with TypeScript lines become longer very fast and having all attrs on new line sometimes create more noise than I would want.
In my opinion this rule should respect language/framework/... that in use in project.
Can't really relate to the given arguments but as I wrote in another thread on Hashnode, this topic is highly subjective and hardly depends on the developer itself and/or the used stack.
I am not really a fan of having two or three columns with code side-by-side and also not having the editor and browser side-by-side (mainly because the browser dev tools alone take up half of the monitor).
In my opinion, the limit may also be set based on the programming language.
(Quoted myself here)
I do a lot of programming with Python and Bash which typically uses 4 spaces. I also work with Ruby, Elixir and Node on a regular basis at 2 spaces.
Never had a problem with 80 characters on the 4 space languages. Maybe PHP is different?
Even on Python code bases with many thousands of lines of code, I very rarely have to think about the 80 character limit, everything just fits naturally.
That's with using very descriptive variable and function names too. I never abbreviate for the sake of line length.
Excellent points. For myself and my development team, I enforce an 80/120 rule: "stay under 80 characters whenever practical; stay under 120 characters at all times".
The reason for the compromise is, one shouldn't sacrifice good coding practice and style to adhere to this! It's a rare phenomenon, but once in a while, you'll see a maddening piece of bad practice whose only justification was "80 character limit!" Still, I've yet to see an exception to 120-characters, ergo the 80/120 Rule.
I go with 100 on the soft limit, and treat 120 as a soft, but stronger limit. There are always some odd cases where it ends up being better.
For comments/api-docs I actually prefer having no limits at all and relying on auto-wrap. It's more natural to write prose that way.
I feel like almost every issue raised could simply be solved by having more than 1 monitor.
At work I have a pair of monitors. At home, I have three monitors. This helps a TON.
I personally use Sublime Text and dont have a dedicated font size. If a particular document is too wide (none of my own, as I keep my text width within sane limits), ctrl+mousewheel scales the text up and down effortlessly. As I switch between different views for various reasons, I do this all the time. This also works in the browser as well, plus in applications like MS-Office.
I have 2 monitors, but I wouldn't open VSCode (or Sublime Text) across both monitors. Each monitor is configured to act as an independent display.
I often have documentation or some type of browser open in the 2nd monitor.
I started my development career using 80 characters, but I slowly found myself drifting to 100, and then finally 120, where I've stayed a while. While I totally get that you can't have 2 files at 120 characters side-by-side, you can stack them vertically. Maybe it's just me, but having any more than 2 columns in my editor feels too cramped.
Excellent article Nick. Well laid out and presented. The screen shots definitely help drive the points home.
Like you, I as well have had to do side-by-side editor layouts. Tracing call stacks from user browser to API middleware to ORM being able to visually see the function calls makes it easier to mentally comprehend what the program is doing.
As @kovah pointed out, and I agree, the line limit is limited by the language. PERSONALLY I like 80, will bend to 120, but do not like anything over 120. 132 is either to small on larger screens or require negative azoom in small screens.
GReat writing, I look forward to the next one.
You should be aware this is really related to the language you use.
In Go and python, I'm happy with 80 columns.
When coding in rust, 80 columns would probably be enough but the standard fmt configuration is 100 and a common way to read and write really help us communicate.
When coding in JavaScript, I like to set the limit at 100 too.
In Java, you just can't so I fix the limit at 120 columns...
You don't want to end up like this guy! 😆🤣😭
Haha exactly.
I have comfortably coded with two windows side-by-side, with larger than average fonts, with 100 char lines, for nearly two decades.
80 characters is short, and I'm not convinced it was every really a standard.
When I use an IDE, I use a proportional font. (Gasp! Shock! Heresy! Blasphemy! A witch!)
The 80-column constraint becomes irrelevant, except if you have to work on a team. And the team imposes a coding standard of 80-columns. (Or 100, or 120, or whatever.)
These days I expect my IDE to handle soft line wrapping properly.
I had started using proportional fonts a long time ago, after reading Bjarne Stroustrup's C++ book where he had used a proportional font for all the code examples (back when most programming language books had all their code examples in a monospaced font).
My favorite proportional font for programming is Input font, by David Jonathan Ross released by Font Bureau. It's free, and has some customization options to tweak it to one's preferences. input.fontbureau.com/
There is a surprising shortage of good proportional fonts suitable for programming. I've taken a few popular fonts, and tweaked them using Fontographer, to make them suitable for programming for me (I never released them into the wild, for obvious reasons). But I'm glad to have found Input, which I like better than all my one-off attempts.
When I'm using Vim (which is often), which is not proportional font friendly, I use Fira Code, by Nikita Prokopov adapted from Mozilla Fira. github.com/tonsky/FiraCode
Historical trivia: C used to have a character line limit of 509 characters.
80 is too restrictive for me, and I found myself wasting screen real-estate on larger monitors.
I wish my work monitor was 1080px wide. Probably why I prefer using my 4K iMac at home.
Couldn't agree more!
I must confess that I only started using this rule because of Prettier’s line length limit. Now I am actually liking it.