Ask HN: How many characters per line do programmers typically prefer?
80? 100? 120? Something else? Personal preferences preferred over some standard.
33 comments
It's interesting how 80 (the standard number of characters/line) comes from punchcards, where there were 80 columns. Somehow that number stuck and it's still the standard.
Personally, I prefer 120, but I realize it is a preference. That said, I am irritated beyond belief when there is a project mandate that all code be 80 characters and no more. Pretty much everyone has a widescreen monitor these days, and the 80 character limit is a relic from the 4x3 monitor days.
Beyond that, I feel like a character limit that low puts a disincentive on the creation of meaningful variable names and function names. Maybe it's a hold-over from my Java days, but I really strive to name my functions and methods something meaningful. When I'm limited to 80 characters, plus proper tabbing, plus general flow control... it becomes incredibly difficult to stay under 80.
Beyond that, I feel like a character limit that low puts a disincentive on the creation of meaningful variable names and function names. Maybe it's a hold-over from my Java days, but I really strive to name my functions and methods something meaningful. When I'm limited to 80 characters, plus proper tabbing, plus general flow control... it becomes incredibly difficult to stay under 80.
If you use tiling window managers, there is still a good reason to stick with 80.
I've been using some form of tiling manager for 4+ years now (herbstluftwm at the moment, though with stints using i3, awesome, dwm, bspwm and xmonad) and I've never had a problem with lines over 80 characters. I tend to use small font sizes, but I can't recall ever getting into a situation where 100 character lines were an issue. I can't recall any of the mangers I've used having a key combo to open up an 80 character wide terminal, though I could be forgetting.
Do you find herbstluftwm to be better than i3? If so, in which way? I've been using i3 for a few years now, I'm VERY happy with it and I'm curious if/how [0] some other tiling wm can be better.
I've been a huge fan of herbstluft since I started using it. Herbstluft's 'frames' definitely take a little while to adjust to and it took a few days to figure out how to fit hlwm's tools to my normal workflow, but I find the manual partition/automatic tiling within partitions system to be my favorite paradigm by far.
What a widescreen monitor doesn't fix is having to move your head to read those 120 characters. With only 80 characters you only have to move your eyes.
I usually don't have to move my head to read 120 character lines.
For reference: on an iPad, I get 61 characters on a line in the HN input field, and it is about half the screen width in landscape mode. So, an iPad can do about 120 fixed-width characters on a line. I don't think I move my head when reading iPad text in landscape mode.
I expect that people with somewhat normal vision will say the same.
I expect that people with somewhat normal vision will say the same.
It depends; you have to use a good judgement - in general the further away from this 80-120 range the code is, the more doubtful the decision looks. I personally prefer 80, but occasionally have to allow for longer lines.
Initially 80 was a technical limitation - you could do more, but had to make much more efforts than seemed reasonable. Then GUI allowed for more - but there was some inertia of the habit. Gradually some started experimenting with longer lines, finding cases where that's more convenient. Then code guides started mentioning line length...
On one hand, a shorter line is easier to follow with eyes - when you need to go from right side of a line to the left side of the next line, that next line is easier to find if the line itself is shorter. However the code is usually much easier to read in this aspect than prose - line lengths are varying naturally. Yet if you're trying to always keep descriptive names of variables and methods, you're not only adding some verbosity, but also more often have to split lines - and that adds to making code more "blockish".
It seems there are natural limitations - but that still depends on the particular style of the code. Have variable names just right - and you won't need too much lines in a block, so long lines could be ok. Different languages, different conventions for external libraries... It seem to be hard to put a specific number that would be both a good match with existing libraries, work (look) well for all kinds of tasks and across different languages. Sometimes one doesn't even want to sacrifice inner structure of the line - e.g., when several similar lines have important differences which one wants to highlight some spaces are often added, leading to longer lines. Or sometimes line-by-line comments are really useful (say, Minix source code) - which definitely add to line lengths.
Initially 80 was a technical limitation - you could do more, but had to make much more efforts than seemed reasonable. Then GUI allowed for more - but there was some inertia of the habit. Gradually some started experimenting with longer lines, finding cases where that's more convenient. Then code guides started mentioning line length...
On one hand, a shorter line is easier to follow with eyes - when you need to go from right side of a line to the left side of the next line, that next line is easier to find if the line itself is shorter. However the code is usually much easier to read in this aspect than prose - line lengths are varying naturally. Yet if you're trying to always keep descriptive names of variables and methods, you're not only adding some verbosity, but also more often have to split lines - and that adds to making code more "blockish".
It seems there are natural limitations - but that still depends on the particular style of the code. Have variable names just right - and you won't need too much lines in a block, so long lines could be ok. Different languages, different conventions for external libraries... It seem to be hard to put a specific number that would be both a good match with existing libraries, work (look) well for all kinds of tasks and across different languages. Sometimes one doesn't even want to sacrifice inner structure of the line - e.g., when several similar lines have important differences which one wants to highlight some spaces are often added, leading to longer lines. Or sometimes line-by-line comments are really useful (say, Minix source code) - which definitely add to line lengths.
80 is my preference, but the coding standard for my team says 120. I prefer 80 because despite monitors getting pretty large, all the useful docked windows in the IDE eat enough space that there isn't really room for long lines. Plus it's hard to follow long lines even if they aren't cut off by other windows.
80 columns seems like an artificial limit nowadays, but it really helps when looking at multiple files or doing side by side diffs. Unfortunately, I have worked with Java code where there were type signatures longer than 80 characters. Thankfully, Haskell doesn't suffer this defect, so I usually stick to 80.
No limits. I believe in dividing code into multiple lines naturally without regard to how many horizontal characters a few lines of code will end up getting to.
Depends. I usually set a marker around 90 and mostly stay inside it. Func/method type signatures (especially in Swift/ObjC) I'll let run over without worrying as they can get a bit verbose and I don't need to parse them frequently.
Inside the body I'll usually stay under 75 and will split multi param function calls across lines. If lines start to overflow I'll often factor some piece out to another variable to keep it readable.
Switch cases I'll let run long if I can fit them all in as one liners. Having not worked on a shared code base for a few years I've developed a bunch of non standard habits.
Inside the body I'll usually stay under 75 and will split multi param function calls across lines. If lines start to overflow I'll often factor some piece out to another variable to keep it readable.
Switch cases I'll let run long if I can fit them all in as one liners. Having not worked on a shared code base for a few years I've developed a bunch of non standard habits.
80 to 90 for me anything longer gets hard to read
80-85 is what I prefer. I've worked at places where the style guide said 100, but j still kept my lines below that. 100 is too many characters on one line.
Standard typographic convention is 2-3 alphabets on one line. It doesn't quite apply with a mono space font, but 3 alphabets is 78 characters.
When I'm writing hard line wrapped prose, I even prefer to keep it to 72.
Standard typographic convention is 2-3 alphabets on one line. It doesn't quite apply with a mono space font, but 3 alphabets is 78 characters.
When I'm writing hard line wrapped prose, I even prefer to keep it to 72.
Interesting reading this. I stop mine still at generally 78 chars. This allows it to print in a large enough font to be fit on a single 8.5x11" page without any extra wrapping.
I have also used 130 chars as the limit and printing source code on green bar paper. But at least to me, it just isn't worth it, IMO functions should never take more then 1 screen to view and that includes the limit of 78 chars and roughly 50ish lines. This makes code easy to grok and helps to make sure a function does only 1 thing. Not that there are not some exceptions but that is my general rule.
The 78 chars also comes from some older printers that had margin issues and if you went to exactly 80 they would wrap or add a blank line. Yea, I know, mostly stupid today, but it keeps the code super portable, predictable and very readable.
I have also used 130 chars as the limit and printing source code on green bar paper. But at least to me, it just isn't worth it, IMO functions should never take more then 1 screen to view and that includes the limit of 78 chars and roughly 50ish lines. This makes code easy to grok and helps to make sure a function does only 1 thing. Not that there are not some exceptions but that is my general rule.
The 78 chars also comes from some older printers that had margin issues and if you went to exactly 80 they would wrap or add a blank line. Yea, I know, mostly stupid today, but it keeps the code super portable, predictable and very readable.
I avoid going over 80, and try to keep lines even shorter, around 60 is when I start trying to break the line.
I very often put separate function arguments on separate lines.
I'm also always frustrated at the syntax of most non-Lisp languages and how difficult it can be to break lines sensibly. (Infix operators, the ternary operator, JSX, period syntax for property access, etc).
I like to use large fonts because they help me focus. And I also like to sometimes be split screen with a browser on my laptop, so "everyone has a widescreen" is irrelevant for me.
Narrow code when composed nicely still allows widescreen coders to use splitting along the vertical axis, but long lines are difficult for me to deal with with my (perhaps idiosyncratic) ways.
I very often put separate function arguments on separate lines.
I'm also always frustrated at the syntax of most non-Lisp languages and how difficult it can be to break lines sensibly. (Infix operators, the ternary operator, JSX, period syntax for property access, etc).
I like to use large fonts because they help me focus. And I also like to sometimes be split screen with a browser on my laptop, so "everyone has a widescreen" is irrelevant for me.
Narrow code when composed nicely still allows widescreen coders to use splitting along the vertical axis, but long lines are difficult for me to deal with with my (perhaps idiosyncratic) ways.
Depends on the language. 120 for Java. 80 for Python, Puppet and shell scripts. I don't believe in mandating an absolute hard and fast limit but I'd reject a pull request with unnecessarily long lines.
I generally try to aim for 80, but have 120 as my "hard" limit. In find it a good place to have two files open side by side and still have a little bit left over for editor UI stuff.
I program with 2 panes on a 13" laptop, so 100 max, but usually smaller. But i'll never compromise my code clarity for the pure reason of the length of a line. Homemade abbreviations are a no go. I believe every abbreviation should be googlable, or something that is common vernacular in your particular company.
I work in embedded C/C++ all day and have a soft limit of 80 characters per line and 60 lines per method. 99% of my code will conform but no big deal if you go over and don't lose visual appeal. 80/line is nice because you can put a .cpp/.h next to each other on a widescreen monitor.
80
80 because it makes (several) vertical splits in vim and tmux useful. Anything more and things start wrapping in your editor. When composing email or commit messages I usually go with 72 (so you can indent by 4 spaces to center or quote it 3 times).
flake8 (python standard) has 70, which I find to be small and ugly. But then again I'm not a python programmer and I work on 27" and 24" screen iMacs, so yeah even 70 might work.
Code — typically within 50, sometimes up to 120.
XML documentation in the comments — up to 180: I find the smaller wasted height is, the easier it is to work with the code.
XML documentation in the comments — up to 180: I find the smaller wasted height is, the easier it is to work with the code.
120 for me.
Spawn any terminal, any real terminal, and it will be about 80 chars wide by default.
132 chars (derived from old line printers and PCL defaults)
120, at least. It's not 1989 anymore.
120