DEV Community

Cover image for 80 Characters per Line Is a Standard Worth Sticking to Even Today
Nick Janetakis
Nick Janetakis

Posted on • Originally published at nickjanetakis.com

80 Characters per Line Is a Standard Worth Sticking to Even Today

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-today


It's easy to think "wtf, I have a massive monitor, why should I limit myself to a standard that was created for punch cards in 1928 or terminals from the late 1970s?"

Back then it made sense because of hardware limitations, but I'm sure it also aligned well with how programs were developed.

I wasn't programming back then so I can't say this with certainty but I would guess that most programs written back then were very focused on editing 1 "thing" / file at a time.

Current Day Web Development

Think about how you typically develop a web application today. You open up your app in a code editor (I really like VSCode btw) and as you make changes to your code you often look at the results in a browser.

I know it differs depending on what you're programming and what styles you prefer. For example, some people like a TDD style approach so they will be writing tests while also writing code to make those tests pass.

Personally I'm not a fan of the TDD approach, but that's not what this article is about. This article is about discovering patterns on how we edit code when doing typical web development work.

The overall pattern is we're very much focused on looking at and editing multiple files at once. Typically this is at least 2 files but in some cases being able to look at 3 files at once is very helpful. Then on top of that, we have a browser and documentation to look at too.

Context Switching Sucks

I don't know about you but I work much better when I'm not constantly having to do micro-operations such as flipping between 2 files in a code editor.

For starters it makes me feel claustrophobic, but it also plays a role in making me lose my focus. I find it much easier to reason about things if I can visually see all of the things I'm working on at once.

This is partly why I plan things on whiteboards and paper, it's because I'm not bound by a single screen. There's just something very special about seeing the whole thing at once that makes everything click. Is it the same for you too?

Even if it only takes 500ms to switch between 2 files, the lack of being able to see both at once has a huge negative effect on my ability to retain information.

Benefits of Using 80 Character Lines

There's quite a few perks, so let's go to it.

1080p Monitors

1080p is still one of the most popular resolutions for monitors and it just so happens that with most code editors you can comfortably fit 2 code windows at 80 characters side by side, and even have room for a sidebar if you like that sort of thing.

2 code windows side by side on a 1080p monitor at 80 character lines:

2 80 char code windows 1080p

That grey vertical lines you see in the editor panes are placed at 80 characters. I use them as a guide to see how many characters each line is at a glance.

Some people in the industry want to bump the standard up to 120 or even 132 characters but look at what happens to our dual code window layout if we bump the characters to 120 per line.

2 code windows side by side on a 1080p monitor at 120 character lines:

2 120 char code windows 1080p nope

You can't fit 2 windows side by side at 120 characters, and even if you remove the sidebar, you still can't fit it. You end up cutting off so much of the 2nd window.

Having to horizontally scroll to read a full line is also unacceptable.

Now, you can make the font size smaller but in order to fit 2x 120 character windows side by side you would need to use a font size of 10 pixels.

Microscopic font size to fit 2 code windows side by side at 120 character lines:

2 120 char code windows 1080p yep

Even Legolas from Lord of the Rings would disagree with using that font size full time.

1440p Monitors

This is where things get interesting.

I personally use a 2560x1440 monitor at 1:1 scaling and I wrote about how it was the best development environment upgrade I've made in the last 5 years .

One really cool thing about this set up is you can fit 3x 80 character code windows side by side, even with a sidebar. This is with a comfortable font size of 15px too. It's the same font size as the 1080p 80 character dual window set up shown above.

3 code windows side by side on a 1440p monitor at 80 character lines:

3 80 char code windows 1440p

Being able to see these files in 1 view is really useful for day to day web development. Or if I'm doing ops work, I tend to have 2 code windows open with a terminal in the spot where the third code window typically is.

If you do run 2560x1440 at 1:1 scaling you can comfortably fit 2x 120 character lines side by side, but 3 is not even close. I won't even bother showing the picture of trying to fit 3 of them side by side. The font size is comically small.

By the way, if you remove the sidebar you can also fit 2 code windows at 132 characters.

Reading Code

Let's ignore viewing multiple files at once and just focus on reading code.

I don't know about you but I find it much easier to read code when the lines aren't miles long. The further I have to look to the right, the harder it is to read.

I don't think I'm alone here either because think about how newspapers and most modern websites position text. As humans, we can digest text much more efficiently when the sentence length is short. Code line length is no different.

Even when I write these blog posts in markdown, I put hard line breaks at 80 characters because it makes the text so much easier to read. It also means I can split this code window with a browser side by side and get instant feedback as I write.

Writing markdown at 80 characters with a browser side by side:

markdown writing side by side

Technically this could work at 120 characters too, but that would mean shrinking your browser. Being able to see a live preview of the "large" version of your site is important.

Also, don't forget I'm using a 1440p monitor here which has a lot more horizontal real estate than a 1080p monitor. It's very cramped even with 80 characters at 1080p.

Code Linting and Formatting Tools

I am only bringing this up because you might think it's super annoying to always concentrate on limiting your lines to 80 characters, but it's really not bad.

A lot of languages have either built in support or third party packages to help you limit your code length. This works for whatever line length you decide to limit your code at.

This way you don't even need to think about limiting the lines yourself. I still do out of habit but I'm always 1 hotkey away from having a tool auto-format the code for me.

I used to hate auto-format but now I love it because instead of spending 5 minutes trying to finagle a line of code to fit at 80 characters I just let the language author or the community (code standard rules) do it for me with automated tools.

Zooming Way in for Videos

This probably won't affect you on a daily basis but if you happen to record coding videos like me, then this is a pretty big win.

Zooming in to the point where 80 characters fits your whole screen at 1080p is very nice. This will ensure that the font size is large enough so smaller devices can read it, and more importantly, people will be able to read it without having to full screen your video.

Are you a fan of 80 characters per line or something else? Let me know below!

Top comments (18)

Collapse
 
oburejin profile image
oburejin

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.

Collapse
 
kovah profile image
Kevin Woblick

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.

Because not all programming languages are the same and they have different standards. Just take Javascript and PHP. JS is usually coded with 2 spaces while 4 spaces is the common indentation for code in PHP. While 80 chars can be pretty much in JS and a lot of space for anything you code, in PHP you hit that limit after 3 indentations with a class-based method call that contains 3 parameters. Therefore, we at Taikonauten decided to use 80 characters for HTMl, JS,... and 120 chars for PHP as hard limits. Works pretty good for us.

(Quoted myself here)

Collapse
 
nickjj profile image
Nick Janetakis

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.

Collapse
 
codemouse92 profile image
Jason C. McDonald • Edited

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.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
darkain profile image
Vincent Milum Jr

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.

Collapse
 
nickjj profile image
Nick Janetakis • Edited

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.

Collapse
 
cjbrooks12 profile image
Casey Brooks

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.

Collapse
 
david_j_eddy profile image
David J Eddy

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.

Collapse
 
dystroy profile image
Denys Séguret

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...

Collapse
 
jerodsanto profile image
Jerod Santo

You don't want to end up like this guy! 😆🤣😭

Collapse
 
nickjj profile image
Nick Janetakis

Haha exactly.

Collapse
 
mortoray profile image
edA‑qa mort‑ora‑y

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.

Collapse
 
eljayadobe profile image
Eljay-Adobe

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.