
Ask HN: How many characters per line do programmers typically prefer? - baccheion
80? 100? 120? Something else? Personal preferences preferred over some standard.
======
56k
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.

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

~~~
dman
If you use tiling window managers, there is still a good reason to stick with
80.

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

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

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

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

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

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

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

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

------
pivo
80 to 90 for me anything longer gets hard to read

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

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

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

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

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

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

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

------
spajus
80

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

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

------
networked
Poll:
[https://news.ycombinator.com/item?id=11570745](https://news.ycombinator.com/item?id=11570745).

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

------
stevesun21
120 for me.

------
_RPM
Spawn any terminal, any real terminal, and it will be about 80 chars wide by
default.

------
amaterasu
132 chars (derived from old line printers and PCL defaults)

------
icedchai
120, at least. It's not 1989 anymore.

------
tenismyanswer
10

------
paulddraper
120

