DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 967,611 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for Maximum line length in your code
Evaldas Buinauskas
Evaldas Buinauskas

Posted on

Maximum line length in your code

Until now I've always tried to stick to 80 characters per line and it worked just fine in plain ol' JavaScript, however after adopting TypeScript it feels like it's not enough with all these type declarations, sometimes code becomes harder to read, an example:

export const setCommunity: ActionCreator<SetCommunityAction> = (
  id: string
) => ({
  type: '@@community/SET_COMMUNITY',
  payload: {
    id
  }
});
Enter fullscreen mode Exit fullscreen mode

Whereas if limit would be 100, this becomes more readable:

export const setCommunity: ActionCreator<SetCommunityAction> = (id: string) => ({
  type: '@@community/SET_COMMUNITY',
  payload: {
    id
  }
});
Enter fullscreen mode Exit fullscreen mode

Of course this is a single example that was frustrating me.

What max line length do you use and what are the reasons behind it?

Top comments (54)

Collapse
 
johnkennedy9147 profile image
John Kennedy

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

Collapse
 
stenpittet profile image
Sten

In my case it comes in handy when I have 2 files opened side-by-side. I switched to 120 from 80 and it works pretty well for me.

Collapse
 
buinauskas profile image
Evaldas Buinauskas Author

This usually comes from tools like GitHub or VSTS. These will enforce horizontal code scrolling on code comparison if lines are longer than {x} characters.

Collapse
 
khophi profile image
KhoPhi

Now that's the principle.

I think there shouldn't be any definite edged-in-stone approach to maxlengths.

In my case, I simply turn on the text wrap in whatever IDE, and it fits what's right in the viewport.

Collapse
 
monknomo profile image
Gunnar Gissel

I like max lengths because I usually work in an IDE with other devs. A shared max length means we can all format our code on save, and it doesn't mess each other up

Collapse
 
donis profile image
donis

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.

Collapse
 
bosepchuk profile image
Blaine Osepchuk

We find than 120 is the most readable while still short enough for all the ways our code is displayed (screen, diffs, Bitbucket, etc.).

80 chars gets hard to read when you have longer, more descriptive names like we use in our code.

Collapse
 
justinctlam profile image
Justin Lam • Edited on

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.

Collapse
 
vinaypai profile image
Vinay Pai

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.

Collapse
 
pmcgowan profile image
p-mcgowan • Edited on

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.

Collapse
 
mcccclean profile image
Tom McLean

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.

Collapse
 
xowap profile image
RΓ©my πŸ€–

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.

Collapse
 
moopet profile image
Ben Sinclair

I know that, like you, I don't like reading overly-long lines.

There's been a lot written about the readability of lines < 60 or > 100 (approximately) in things like blog posts and newspapers and I think that it makes sense to apply the same knowledge to code too.

Collapse
 
gyandeeps profile image
Gyandeep Singh • Edited on

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)
Collapse
 
buinauskas profile image
Evaldas Buinauskas Author

Yep! I do use prettier to format my code and have pre commit hook. This works really well.

Collapse
 
dance2die profile image
Sung M. Kim

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

Collapse
 
daersk profile image
Daersk

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.

Collapse
 
moopet profile image
Ben Sinclair

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.

Collapse
 
weswedding profile image
Weston Wedding • Edited on

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.

Collapse
 
jwalzak profile image
Jason Walzak

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.

Collapse
 
hdennen profile image
Harry Dennen

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.

Collapse
 
dmfay profile image
Dian Fay

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.

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.