
80 chars per line is great - jaimebuelta
http://wrongsideofmemphis.com/2013/03/25/80-chars-per-line-is-great/
======
cletus
At Google, our Python style guide dictates 80 characters with 2 character
indenting [1]. Java is the only exception at 100.

Even 100 can be awkward to fit into. Lord knows I've renamed variables to
avoid splitting a line on several occasions.

But what a lot of posters here seem to miss is that it isn't about the width
of screens for editing, it's about the width of screens for _reviewing_ so you
need twice the real estate.

Add in doing interactive merges and you need _three_ times the width.

This really comes down to the principle of enforcing a common style (for an
organization or project). A lot of people rail against "arbitrary limits" and
"arbitrary style guidelines" as it's something extra they need to learn and
adds no value (according to them). I've seen people here for 6+ months again
still fighting this.

Such things (IMHO) have value as it adds a reasonable level of consistency
across teams, it avoids commits on files due to stylistic changes (which may
or may not be automatic from IDEs, etc) and, most importantly, defuses a lot
of the aesthetic-driven boneheadedness that we engineers are prone to.

The last point is really important. Otherwise you'd have engineers and groups
fighting over where to put curly braces, 2 space indents vs 4, whether tabs
are OK, etc--none of which actually matters.

So if you feel your creativity somehow stifled over 80 characters, I'd
strongly suggest you just abosrb it, get over it and move on to things that
actually matter.

[1]: [http://google-
styleguide.googlecode.com/svn/trunk/pyguide.ht...](http://google-
styleguide.googlecode.com/svn/trunk/pyguide.html#Line_length)

~~~
rayiner
Lines of > 80 characters are really the last jabs at the dying corpses of
typography and taste in the digital world. Typographically proper paragraphs
are not wide across, because that forces the eye to move more while reading.
This is a basic fact that has been known for literally longer than we've had
printing presses.

Wide lines are barbaric, and I'd go so far as to say that languages that can't
be rendered comfortably in 80 character lines are nothing more the primitive
tools of barbarians.

~~~
5h
> Wide lines are barbaric

I agree utterly, and enjoy the irony that I read your comment displayed as
<http://i.imgur.com/iJNs9SV.jpg> ... a full 258 characters ... HN could do
with some responsive css to max-width comments above certain viewport widths!

------
npsimons
I love how a lot of responses here are of the condescending tone of "we aren't
using vt100s anymore, grandpa", as if advocates for the 80 column limit are
still running VIC20s in their mom's basement. I see this argument pop up a lot
against things like vi and Emacs as well.

Yes, we realize that monitors are bigger, resolutions are higher, etc ad
naseum. None of that matters. What matters is code readability. So what if you
can fit 120 characters in your code editing window? I can fit more than 400
across two monitors, should the new line length limit be 400? Why stop there,
why not just let lines be endless and have the editor wrap them? Answer these
questions, and you've answered why people still like the 80 column guideline,
or even care about code formatting at all. Code is only incidentally written
for machines to execute; it should be written for people to read.

~~~
ak217
Yeah, but code readability has little to do with line width. I could show you
perfectly unreadable code that fits in 80 characters because it's legitimately
pre-indented by 40 and has to go to one word per line or shorten variable
names to fit in 80, and wonderfully easy to read code that goes out to 160
(often because of some literal data that would otherwise just increase the
vertical length).

Also, it's funny to me that people talk about horizontal line length impacting
readability, but never seem to talk about _vertical_ length impacting
readability as well. To me it's critical to keep related code clustered
vertically as closely as possible without too much brevity: having to
scroll/split view to see related pieces of code incurs a cognitive overhead.
Arbitrary line breakage imposed by the 80-character limit gets in the way of
that. (And don't get me started about teams that treat this as a _limit_
instead of a _guideline_.)

It's critical to give programmers the tools to make their code readable (good
languages with good grammar and idioms), not arbitrary restrictions that try
and fail to accomplish that indirectly.

~~~
ajross
> _I could show you [...] wonderfully easy to read code that goes out to 160_

I'm calling this bluff. No, you can't. If you actually have evidence I'd truly
love to see it.

Ridiculous line length is actually one of the most reliable code smells I
know. Seeing something like that, I can virtually guarantee that it's an OOP-
gone-wild mess of needless abstraction, tightly coupled data structures spread
across a dozen files. It's going to be a spaghetti mess of nested if()
constructs used where clean data-driven logic would have been better. It will
be filled with commented-out-code. And it will probably have indentation that
lies, lined up in incorrect columns waiting to fool the developer.

Clearly you feel differently. Prove it. :)

~~~
ak217
[https://github.com/kislyuk/dmtk/blob/master/scripts/compareP...](https://github.com/kislyuk/dmtk/blob/master/scripts/comparePulseData.py)

Feel free to criticize. That code has lots of shortcomings. Compromised
readability due to line length is not one of them.

~~~
ajross
You can't be serious. Check lines 388-400. Now, even ignoring the fact that
_github itself is chopping those lines because they're too long_ , they're
simply not meaningfully readable. The ridiculous repetition (which is the
proximate cause of those awful line lengths) totally obscures the meaning.

Note all the repeated use of this weird dictionary name
"my_stats[condition][strand]". This thing appears, often multiple times, on
ever line of that loop. You're telling me that this couldn't be made more
readable by using a simple local "stats" reference name "st"? Repetition of
expressions is the sign of lazy code, it's the same kind of thought process
that gives us cut-and-paste bugs.

Note likewise the repated use of "kc_stats[condition]". Same deal. Same
treatment.

Note likewise the oddball commented out line (assigning a tuple of
m2_ci_lo_fwd, m2_ci_hi_fwd) which is disabled without explanation. Remember my
list of attendant symptoms?

And, on the design side: note the mean/median/stdev calls. Those are generally
pretty well-defined properties of "sets". Why is there a "Metric" postpended
to the method names needlessly? Surely the reader would understand
"st.stdev()" already, right? And _why do the methods take five named
parameters?_. That's insane -- they should take _zero_. It looks like this is
trying to pass in some extra "stuff" (maybe to control some side effects, or
to filter the data) to what should be an idempotent operation on a fixed piece
of data. If you have to filter, or if the object does some extra counting or
whatever, those should be set up on the data ahead of time.

This code is crap. Sorry.

~~~
ajross
Just because I'm feeling bored today, here is that same loop (around line 388)
"cleaned up" to work inside 80 columns. I added a "metricGenrator" abstraction
to the API because it seemed like a sane addition to clean up the "too many
arguments to mean()" problem, but all other changes are is pure syntax. I
_dare_ you to argue that this isn't more readable than the original:

    
    
          my_stats = {'Modified': {'+': {}, '-': {}}, 'Control': {'+': {}, '-': {}}}
          for condition in 'Modified', 'Control':
            for strand in '+', '-':
              st = my_stats[condition][strand]
              kc = kc_stats[condition]
              kc = kc.metricGenerator(metric, ref_pos=ref_pos, trim=opts.exp_trim,
                                      coverage_ceiling=opts.coverage_ceiling,
                                      strand=strand)
              st['mean'] = kc.mean()
              st['median'] = kc.median()
              off = st['stdev'] = kc.stdev()
    
              if use_se:
                kc.setOpts(ref_pos, metric, trim=0.0,
                           coverage_ceiling=opts.coverage_ceiling, strand=strand)
                off /= sqrt(len(kc._getMetricData()))
    
              st['spread_lo'] = st['mean'] - off
              st['spread_hi'] = st['mean'] + off
              my_report_row.extend(st['mean'], st['median'], st['stdev'],
                                   st['spread_lo'], st['spread_hi'],
                                   st['coverage']])

~~~
arh68
I don't know if this was easy or quick for you (less than an hour, in any
case), but you seem to prove the parent correct: "That code has lots of
shortcomings. Compromised readability due to line length is not one of them."
Maybe you're simply an amazing programmer, but to jump in and refactor a small
bit of code deep inside something you've never seen before proves to me that
the initial code was indeed readable.

In either case, both examples are literally geometrically square, which I
think drives readability more than line width. When the long lines poke out
and don't relate to other long lines, it's hard to read. If all the lines are
long and share structure, it's just verbose, but reasonably easy to read. With
that perspective, I'd say the parent's code isn't a great example of long-line
code: it doesn't demonstrate a _need_ for 160 chars; I'll agree with you.

~~~
ajross
I started typing a longer response, but honestly I think the clearest answer
here is just sarcasm:

Some of us have a higher standard for "readable" code than "can be refactored
so that it doesn't suck". :)

------
kstenerud
80 characters is an accident of history, an accident that should be corrected.
With an 80 character limit, you need to be mindful of the length of your
identifiers. You start compromising recognizability in the name of fitting the
line to an essentially arbitrary length (drop a few vowels, maybe use a less
precise word).

Using a width limit to coerce into indenting less is just plain silly. If you
don't want high levels of indentation, put THAT in your coding guidelines.
Don't rely on side effects.

~~~
GhotiFish
This isn't about the indentation. Look at the examples. you can see that allot
of his code is indented heavily.

This is about the amount of time and distance required to scan my eyes across
a line to understand its meaning. How much do I have to read to understand a
simple concept?

This is also about the amount of screen real-estate i have to use. We arn't
programming on VT100 terminal any more, damn right. NOW I get to have the
compiler output and continuous integration output to my left. The directory,
class structure and documentation to my right.

I also get to split my screen to have two editors open for comparing snippets
of code line by line.

Merge conflicts and diffing are hugely common operations. merges have three
parallel windows open at once!

You, still, only have 80 characters to work with.

~~~
ajanuary

        This isn't about the indentation.
    

From TFA:

    
    
        Also, having the mandatory indentation whitespace increase the line width is a good visual way of minimising the nested loops in your code and suggesting, in a subtle way, to refactor anything that is indented more than about four times.

~~~
scarmig
Your line from TFA is 241 characters, making it a pain to read....

------
ak217
Screw arbitrary limits.

Personally, I prefer the 120 characters per line _guideline_. Most code I see
starts looking very ridiculous when trying to accommodate the 80 characters
max width, and it starts becoming hard to follow lines when exceeding 120
characters. So, to me a _soft_ 120 characters guideline is the nice medium
between the fact that it's no longer 1980 and the need to make lines easy to
read.

Also, in most cases readability has almost nothing to do with line width (in
fact it can suffer greatly from too much line breakage), and everything to do
with how the programmer chooses to structure their code, aided by language
idioms.

~~~
epochwolf
I do the same thing. I set a vertical guideline to 120 characters. Depending
on the codebase I'll turn on wordwrap at 120 characters too.

~~~
heidar
I like a 80 column soft limit which I usually stick to and a 120 column hard
limit which I use when I feel splitting the line and indenting would harm
readability.

------
d23
I had to fight with my team over the 80 character limit, but they eventually
gave in. It works great in nearly every editing environment, and I've started
trying to use it as much as possible in non-python projects as well. I can
neatly fit two windows side-by-side in my IDE and read them both easily. I
just can't go back to the old way of having the ends of lines hidden off-
screen.

~~~
Evbn
Do you code on a netbook? 2x120=140. At 7px each, which is generous (even if
you are using some non-proportional font for archaic reasons or misplaced
machismo) that is under 1000px wide.

~~~
awj
I have a 27 inch monitor and _still_ prefer an 80 character limit. It rarely
forces me to mangle code and allows me to have four different files open side
by side. It's especially useful for frontend development where I'm going to be
editing html, css, and javascript almost all at once.

This "hurr durr, we aren't on terminals anymore" argument is dumb. You aren't
arguing with crotchety old geezers or people with stupid hardware choices.
Quit assuming the people who disagree with you are idiots.

~~~
marssaxman
With you here. I don't even know how big my monitor is, but more horizontal
space just means I can open up more code windows side-by-side, which means I
can see more context at once. All to the good.

------
bluedino
With the long variable/class names used these days, and the availability of
clear, small fonts and 16:9 displays, 80 columns seems silly. But I'm against
raising it, even to 100 columns. 100 really isn't much more than 80. And then
you start to lose things like being able two view two pages of code side by
side.

The other problem is that 100+ column lines are just flat out hard to read.
It's hard to follow text that far across these screen. A few years ago when I
was working with Objective-C I came across methods used with each variable on
one line and really grew to like that.

It's similar to the way source code is laid out in books. But is that because
the code is more readable that way, or is it a consequence of the layout?
Books are taller than they are wide and usually have generous margins.

~~~
vadman
I use a soft-ish guideline of 100 columns per line, but I mostly code in C# at
work, so normally namespace/class/try-catch is already 3 indentations, and 80
chars is simply not enough for everything.

I do my best to keep it between 80 and 100 chars. With a horizontal screen
resolution of 1920 pixels, 2 pages of such code fit nicely side by side.

------
nonamegiven
I think the three file views side by side image is one of the best arguments
I've seen for 80 chars. But I'm predisposed to like that image, because I like
80 chars.

~~~
balloot
So why not make it 60 characters? Then you could have _4_ files side by side!

But seriously - I guess there is some workflow where you would like to have 3
files side by side, but I certainly have never felt like that is something I
need. I would much rather have readable, verbose variable names, which I have
found to be the first thing to get axed in an 80 char column setup.

~~~
snprbob86
Three files side by side is extremely common for those of us who have to
regularly resolve merge conflicts. You put the common ancestor in the middle
and the diverging changes on either side, then you edit both sets of changes
in to that middle buffer.

~~~
balloot
I resolve merge conflicts as well. Every system I've ever used gives you one
file with delineated chunks (<<<<, === >>>). Never once have I said "this is
too difficult - I need three windows open." And even if I did say that
sometimes, I can't imagine optimizing the character width of my code for that
one use case.

~~~
nonamegiven
The most definite thing that should be taken from a thread like this is that
it usually boils down to personal preference. In fact I'd say that personal
preference in these matters should take at least as much preference as any
available emperical studies. If you're in a group, and you don't get your way
in the coding standards meeting, accept it and move on. _You can do it_! :)

------
richardlblair
The thing people miss here is the "Python related". If you need 120 characters
on a line then you completely missed the "zen" of python.

Having to go beyond about 85 characters is a good indication that you probably
need some refactoring in your _python_ code. As the idiome states, "Flat is
better than nested."

Your if, in an if, in an if, in a for, in a method, in a class is probably
complete garbage. Even in other languages, if you are so nested that you
legitimately need 120 characters then you likely need to refactor. Your code
that is nested to oblivion will prevent anyone from being able to give you a
thorough code review which opens you up to unnecessary risk.

~~~
obviouslygreen
This is painfully presumptuous. Generalizing others' code and constructs as
"probably complete garbage" and suggesting that a 120-character line implies a
"need to refactor" is either profoundly naive or grotesquely smug.

I love Python, but programming languages don't have "zen," and reality is
never so ideal that an 80-character line -- in and of itself -- can ever be
assumed to imply anything useful.

~~~
Chris_Newton
Thank you for making that point.

I used to work on some code that did a lot of subgraph matching. Subgraph
matching in general is computationally expensive, so ideally you do it
heuristically, searching for more likely elements of the subgraph you’re
looking for first so you can skip over edges/vertices that have no potential
as early as possible. Even then, if you’re looking for a complicated subgraph
then you’re going to have a bunch of conditional logic that runs _lots_ inside
deeply nested loops one way or another.

That kind of code is often unwieldy, simply because the algorithms it
implements are unwieldy. However, arbitrarily factoring out some of the inner
levels into separate functions, which might have little meaning in themselves
and little potential for reuse out of context, just means when you’re trying
to review/update the code you need to look in more than one place to find it.
On top of that, you’re also incurring a bunch of relatively heavy function
calls (many parameters might need to be passed in for context) right in the
middle of deeply nested code or you’re trusting your optimiser to inline them
reliably.

So these days, whenever I see someone quoting dogma about how more than _n_
levels of nesting are bad and your code needs refactoring if you hit their
personal arbitrary limit, I cringe a little inside. Not all real world
algorithms fit neatly into a dozen lines of code and a level or two of
looping.

------
CapitalistCartr
Long ago, I wrote Web pages to be served from OS390. Because it still enforced
the 80 char limit from punch cards, I had to adhere to it, also. But no fancy
editors for code directly in the machine. And when any line ran over 80, it
would only render the first line of HTML. Took me hours to figure that one
out.

But I never ran across anything I couldn't make decent inside those 80
characters.

------
jspiros
I find the 80 char limit nice as a suggestion/warning, a way of saying "are
you sure your approach should require lines of code this long?" So, a good way
to make sure that someone is writing readable code, which is otherwise the
overall goal of PEP8. But, sometimes there are lines of code that are
perfectly readable, maybe even more readable, despite exceeding 80 characters,
and which become less readable by doing line continuations. (I would argue
that line continuations make everything less readable, almost all of the
time.)

The other rule that I personally ignore, and when I'm managing a project I
have my developers ignore, is the suggestion to use spaces instead of tab
characters for indentation. Of course, with Python, you must use one or the
other, but I prefer tabs.

In both cases, it comes down to my belief that individual coders should have
the ability to customize their experience without forcing it on everyone else.
When you use spaces instead of tabs, and indeed, when you use line
continuations, you're forcing your (the author's) exact view of the source
code on everyone you're working with. If you use tabs, and don't use line
continuations, others with specific needs (2 character tabs, 4 character tabs,
8 character tabs, 60 character-width editors, 100 character-width editors,
etc.) can, with any modern editor, customize their view (using variable-width
tab stops, and soft line wrapping) to what they're comfortable with.

------
VLM
I think its a given that we'd all agree that writing portrait mode or
landscape mode you still fundamentally take about the same number of square
inches to do it.

One observation is a fixation on horizontal space never on vertical. If you
can't make sense of the big picture without scrolling vertically then you're
probably doing it just as wrong as requiring horizontal scrolling to see the
little picture.

Two interesting analogies:

RISC vs CISC. Doing something RISC like with simple little operations but the
order and block control are super important? Go "RISC" landscape mode. Doing
something ridiculous complicated at the operation level? Go "CISC" portrait
mode and only do one "weird thing" per line.

Another interesting analogy is I've been in this game since 1981 and the
physical display ratio has consistently gotten shorter and fatter every year
(kind of like my body, sorta). Like it or not, the style trend is that someday
our display hardware is only physically going to be capable of something weird
like 800 characters across and only 8 lines up and down. You might have a 10
inch tall display but if 6 vertical inches are taken up by window bars and tab
bars and ribbons and 25 toolbars and a bottom status bar, well you're only
getting 4 vertical inches. Doesn't matter much if you like it or not, you'd
best get used to it as styles don't seem to be changing, not even the 1st or
2nd derivative of the ratio over time...

------
larkinrichards
I really like the 80 character limit for readability, but I'm also a fan of
what it does to git commits (and any other diffs). When I have to wrap code,
say, function calls, I often use one line per keyword argument. When you have
to change or add arguments later on, git recognizes that only one line -- the
argument -- changed, instead of the entire function call changing.

------
Kaivo
What about other languages? I find it harder in C/C++ when I have functions
with too much parameters. It's almost less beautiful to look at. Do you change
parameter names to shorter ones, add usings to avoid explicitly stating the
scope, tab at 2 spaces instead of 3/4, increase the line cap to 90/100?

On a semi-related subject, what about the vertical limit of the code? I often
heard that a function should fit in one page, but that also depends on the
screen resolution. Also, the 80 chars rule would increase the amount of line
instead. How do people deal with that in general?

~~~
nmcfarl
Yeah - I was thinking about a Java codebase I was looking at a while back that
had ultra verbose variable names like
"BackupCopyOfLedgerUsedInWorstCaseScenarioProjections" You couldn’t even do a
simple addition in 80 characters.

This limitation seems fairly language specific, and has a lot of side effects
for the rest of your style guide.

------
k_bx
I'm ok that people don't use email/vim/sublimetext2 with splitting panes, but
don't people use meld / kdiff3 for reviewing they're changes? And on my
1366x768 120-chars would be too wide to show in meld.

~~~
dbrgn
I much prefer colored unified diffs in my terminal (e.g. those from git) over
side-by-side tools with multiple panes.

------
caioariede
I love to work with a 79 chars per line limit.

For those using vim, I use this snippet to automatically split my window at
startup:

<https://coderwall.com/p/suj3fq>

~~~
q_revert

        set colorcolumn=80 
    

is another nice way to keep yourself within the bounds, it also has the bonus
of not being a hard limit, just a visual indication that you're overstepping

edit: (already mentioned)

------
struppi
When I can freely decide, I set the column indicator in eclipse to 100 and set
eclipse to not enforce this limit (maximum line length=1000, never join
lines). I prefer it like this because there are circumstances where longer
lines make sense for me. Anyway, I try to keep lines as short as possible
because I usually use a very large font for coding and have 2 files open next
to each other...

------
niggler
In vim (appears the author is using macvim) you can use

    
    
        :set cc=81
    

to mark the 81st column and visually nag when you go over 80 chars

------
NateDad
100 characters seems a pretty reasonable compromise. Keeps lines from getting
too long and hard to follow, but you're not splitting lines all the time just
to keep under the limit, which also reduces readability.

If you're having trouble fitting two 100 character wide files side by side,
there's two things you need to do:

#1 - get a screen with a decent resolution. 1920px wide should be standard for
any developer worth his salt. Yes, this means "don't develop on a 13 inch
laptop screen"... you're a developer, this is the main tool to do your job,
make it a decent one.

#2 - use a real font. Courier New (or whatever the corollary is on Linux/OSX)
is not a real font. I prefer proggy fonts
(<http://www.proggyfonts.com/index.php?menu=download>)... they are incredibly
more compact and still very readable... you get significantly more characters
on the same line.

~~~
jaimebuelta
Author here, just for reference, I use a iMac 27'' and Menlo 11 (I also have
an extra screen, where I put other info, like mail)

I anyway use the same setting when I use a laptop, though is not my main
workplace.

------
ratsbane
80 characters seems like such an arbitrary restriction. Once upon a time we
were limited to 80 characters but we were also limited to monochrome ASCII
text. Just as syntax highlighting improves readability, I think the
_occasional_ use of longer lines _where appropriate_ improves readability -
the shape of the code gives your eye additional clues about where you are in a
section of code, allows you to have more lines on the screen at once, find
what you're looking for faster, and isolates details that aren't crucial in
getting the big picture. E.g. - inline lambdas or anonymous functions,
strings, etc.

When I work on a codebase with formatting standards I try to follow them. This
is 2013, though, and when I work on my own stuff I format it to get the most
readability on my Macbook or 32" 1080p desktop screen, not a VT100 from 1987.

~~~
jimktrains2
> When I work on a codebase with formatting standards I try to follow them.
> This is 2013, though, and when I work on my own stuff I format it to get the
> most readability on my Macbook or 32" 1080p desktop screen, not a VT100 from
> 1987.

And then someone working on your code on an eeePC will have a great time!

~~~
cabirum
The options are: use smaller font size, enable word-wrap, buy a higher-
resolution display (or two), use your IDE to auto-format code according to
your preferences. I don't really see anybody using eeeePC for serious coding
in 2013.

~~~
jimktrains2
> use smaller font size

Makes the code harder to read

> enable word-wrap

Makes the code harder to read

> buy a higher-resolution display

Increases cost and I can't take an external on the subway/train.

> use your IDE to auto-format code according to your preferences

So, make it 80 to 120 chars per line myself

> I don't really see anybody using eeeePC for serious coding in 2013.

Because the year means sooooo much. Who are you to choose when and how I code.

~~~
cabirum
> Who are you to choose when and how I code

I'm asking the same question when 80 chars limit is enforced on me.

~~~
jimktrains2
80 to 120 char has other advantages over just screen size. It's easier to read
as well. Working on a team is giving and taking of everyone's capabilities.
I've had to work on teams that use odd tabbing, but I do it because that's
what others use.

------
njharman
> combined with the use of whitespace in Python, makes the code much more
> compact and readable

Because of Python's significant indentation is exactly why I can't stand 80
char limit. Breaking lines, causing "false" visual structure destroy's
Python's readability.

Seeing more logic vertically is far more important than horizontal.

I've been on teams that choose horrible names, used strange constructs, etc.
just cause they fit on 80 char. Also wasting huge amount of time getting shit
under 80char. Oh, and 80 char leads to people using import from over import
(to avoid fully qualified names), which introduces bugs (name conflicts) and
tons of confusion / lookup time wasted figuring out "process" is from some.lib
and is not local,, or the one from some.other.lib

------
ajanuary
Personally I find the splitting in the for loop much harder to read, though
the smatch splitting is fine.

I would favor splitting only if you're indenting to line up with the first
couple of tokens. In those cases the pattern is obvious as soon as I start
reading, and my brain switches to scanning vertically. I find it jarring to
have to switch from having read most of a line to suddenly scan vertically.

It seems like the example doesn't demonstrate the point that precedes it at
all. Apparently in this example an 80 character limit doesn't promote re-
factoring, it promotes splitting lines. Which makes the justification for 80
characters being a typical line length + 4 indentations a bit weak and 80 is
back to being arbitrary.

~~~
nonamegiven
I don't quite like the loop split, but that's because I've never like
"continue the next line under the first argument of the series." It makes next
lines start at inconsistent places and makes it harder to read. I usually bend
that rule and follow the four space indent 90% of the time.

But I do like the loop split better than the non-split, despite the above.

I like the smatch split too. It looks like how you'd arrange bullets in a
bullet list, one below the other, so you can see/scan them at a glance,
without having to labor over where the next item is in a single line.

------
tonyblundell
Rules are there to be broken.

I stick to 80 chars 99% of the time because long lines are more difficult to
read.

But if a line ended up being 84 characters wide I wouldn't go replacing
variable names or hacking a single function call onto multiple lines to fix
it.

No one has died yet :-)

------
Glyptodon
I hate the the 80 character limit. I never follow it, though using 2 char
instead of 4 char indentation might help.

The main reason I hate it is pretty simple: I think it encourages using
cryptically named variables. I find that using properly descriptive naming
often leaves lines around 90 to 100 chars, particularly with 4-space indents
and several arguments or a chained call. I also don't find the suggested
practice of implied multi-line via unclosed parens leads to good readability
in many cases.

That said, I agree there should be some limit. My usual practice is to set it
at 120 chars, though I find it rare for a line to exceed 90 to 100 chars.

------
ioquatix
The only consistent method is to not wrap text at an arbitrary limit. Everyone
can follow this and it is very clear. Readability may or may not be
compromised. Dictating an arbitrary line width is exactly that: an arbitrary
standard. If it works for you and your team, great, but ultimately it is a
totally arbitrary choice.

Also, I believe that text editors are generally catching up in this regard and
doing a good job of intelligently indenting code that wraps over multiple
lines. This means you can choose an editor width that suits your needs rather
than having it dictated by someone's arbitrary choice.

------
dbrgn
I agree that we need a limit, but in my experience 80 characters is often too
limiting and sometimes causes wraps that make the code _less readable_ instead
of more readable.

I use a vim colorcolumn at 80 characters as a soft limit, but the hard limit
for my projects is at 100 (or 99, to be exact). This has proven to be a nice
guideline to write readable code, versus the 80 hardlimit that forces you to
write short code (which sometimes is less readable than a clean & clear line
with 90 characters).

------
vph
The problem with 80 chars/line and Python, in particular, is list/dict
comprehension. Naturally, as they replace a whole loop, comprehensions pack
much information into one line. Consequently, there are many times when a
list/dict-comprehension line that are clean and meaningful but had to be
broken into 2 lines.

And that isn't nice.

~~~
jaimebuelta
Having a list comprehension in 2 lines is really a problem? I find very
readable something like

    
    
      result = [something(value) + value * 2
                for value in values]
    

I mean, I prefer one line, but if it has be in two (or more lines), I don't
see the problem really

~~~
mst
Actually, with a minor tweak this gets even more readable -

    
    
        result = [something(value) + value*2
                    for value in values]
    

I find indenting the subcaluse makes my eye flow naturally over the code. I'm
normally doing this in perl, and often end up with functionalish code that
looks like

    
    
        my @result = map { something($_) + $_*2 }
                       grep { valid_candidate($_) }
                         @all_candidates;
    

but the same principle seems to apply nicely to both languages.

------
mgrouchy
80 character lines is perfect. Allows me a reasonable number of splits in vim
and most importantly makes diffs/code that I get in my email readable.

That being said, as with all things(especially guidelines), apply common sense
liberally. Which in Python is one of the guidelines of pep8 on writing
readable code.

------
philwelch
At 80 characters, I often find myself worrying about line length more often
than worrying about the problem I'm trying to solve. 120 is fine. Also, I
orient my (widescreen) monitor vertically so I don't have anything side by
side anyway, just top and bottom where I can see more lines of code.

------
Grue3
It's great for a language that is not whitespace-significant. Python requires
hacks like backslash just to do a line break, which makes both alternatives
(with/without line break) equally ugly.

------
cabirum
Ideally, IDEs should automatically take care of how to represent the code
according to user's preferences. Also, IDEs can save files according to
project's guidelines.

------
wyqueshocec
I like to have my font size rather large. It reduces eye and neck strain for
me and makes the long days more ergonomic.

An "80 char/line" guideline is nice for that.

------
cmars
I mostly agree, but SQLalchemy queries and the occasional complex conditional
could cause one to reconsider or start making allowances.

------
cabirum
80 chars ought to be enough for anybody, right?

------
artificialidiot
With default bells and whistles your IDE provides enabled, you'd be lucky to
have a 79 char wide editing area.

There are modern options though:

1\. Disable unnecessary stuff on your IDE. 2\. Don't use a IDE, use a
dedicated editor. 3\. Don't use an editor from a VGA console. 4\. Stop
pretending you code on a vt100.

I see no wrong with a sensibly long line which is longer than 79, just as I
see no wrong in keeping multiple parts of code visible at all times. There
shouldn't be hard limits or carved to stone guidelines.

------
the1
what? do programmers still layout their code using whitespaces manually? use
code editors that support declarative stylesheet for layout and enable
intuitive structural modification.

~~~
tonyblundell
I prefer to be in absolute control of the layout. It's not that big a task.

------
jlebrech
what about having a limit for the number of lines, 200 lines?

~~~
jotux
In mission-critical systems line limits are common. The first public example
that comes to mind is the NASA JPL C Coding Standard(<http://lars-
lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf>). Check out Rule #25:

>Functions should be no longer than 60 lines of text and define no more than 6
parameters. [Power of Ten Rule 4]

>A function should not be longer than what can be printed on a single sheet of
paper in a standard reference format with one line per statement and one line
per declaration. Typically, this means no more than about 60 lines of code per
function. Long lists of function parameters similarly compromise code clarity
and should be avoided.

>Each function should be a logical unit in the code that is understandable and
verifiable as a unit. It is much harder to understand a logical unit that
spans multiple screens on a computer display or multiple pages when printed.
Excessively long functions are often a sign of poorly structured code.

------
Chris_Newton
I agree completely with the author that readability is paramount and
artificial limitations are often questionable.

Having said that, whenever this topic comes up, we always seem to fall into
the same trap of comparing one dubious representation (very long lines) with
another (awkward breaks to avoid crossing an imaginary limit). Beyond a token
comment on not nesting too deeply, and a token reply that sometimes deep
nesting really is tidier than artificially separating the inner levels
somehow, we rarely consider whether _what_ we’re representing is fit for
purpose. Does it really make sense to take the basic syntax we use for short
expressions like

    
    
        short_name(easy_param, other_param)
    

and try to apply it to longer expressions like

    
    
        full_project_name.useful_package_name.handy_function(first_param,
                                                             second_param,
                                                             third_param)
    

or something more complicated than a single function call? This leads to a
debate where the most radical alternative proposed might be something like

    
    
        full_project_name.useful_package_name.handy_function(
            first_param, second_param, third_param)
    

If you look at well typeset mathematics, which suffers a similar problem of
scalability, there are often (at least) two different conventions for
representing the same mathematical expression. For example, maths set using
the TeX family probably has one version designed to read neatly in-line with
other text, but another version designed to be clearer when set as a
standalone display that might cross several lines.

There are many tools for tidying up those displays, aligning things in logical
ways. There are also conventions for breaking expressions too wide to fit on a
single line, and sometimes those conventions do opposite things when setting
an expression in-line to in displayed form, for example when deciding whether
to leave a trailing + at the end of one line or move it to the start of the
next. There is also a general idea that if you’re dealing with a lot of
expressions that don’t fit, you should be looking to define self-contained
parts of those expressions separately, and incorporate them indirectly using a
more concise notation within the larger expressions. There are even subtle
cross-references like numbering the key equations (only) and then adding a
note like “by (1) and (2)” in the margin to help the reader navigate a
complicated series of results. All of these ideas fit _within_ the broader
typography of setting a paper or thesis, where you still want good general
readability in terms of (physical) line lengths, numbers of columns, use of
tables, positioning of displayed content, and so on.

In programming, we have some of the same basic ideas, particularly separating
out smaller parts of a larger whole as separate functions or variables for
exposition, but we haven’t really developed the same depth of typographical
conventions. Almost everything is based on the idea of taking that basic
syntax that works on a single line for relatively short expressions and trying
to make it work for arbitrarily large expressions across many lines with
nothing but a line break and fixed tab/space characters as tools.

I think this is partly because our text-based editors typically don’t separate
the meaning of our code from its layout. Even ideas like elastic tab stops,
which might be everyday alignment tools in programming languages that use
meaningful indentation, are still esoteric. A few functional languages promote
ideas like “let x in y” or “x where y” syntax to help separate out
subexpressions, but on the scale of functions separation implies creating a
new self-contained function to do part of the work, which comes with its own
scope, which means explicitly passing values in and out when they were already
conveniently available in the all-in-one function.

I don’t see the controversy over X characters per line limits going anywhere
until we get over these more fundamental problems of conflating code
layout/presentation with code meaning. We need to be able to express the ideas
in our programs systematically and have our editors and diff tools and code
review software present those ideas in a suitable layout that adapts to both
the idea itself and its context. Sadly, that’s not going to happen as long as
we keep asking questions like how wide a tab stop should be, and not asking
questions like whether we should even have tab stops at all.

~~~
rdtsc
Not being able to fit the code in 80 columns easily (for me at least) is a
smell test for potential problems code.

Now it depends on languages, I am thinking of Python, C and Erlang here.

If you use too many:

    
    
      full_project_name.useful_package_name.handy_function(...) 
    

is there a way to alias it to a function local name such as my_handy_function
= <the above>. Maybe there isn't (again it depends on language here as well).

> I think this is partly because our text-based editors typically don't
> separate the meaning of our code from its layout.

You need a better editor. That is a solved problem. I like emacs the best. I
imagine vi is just as good. It knows how to indent code based on the
semantics. It knows you are in the middle of the list or just started a code
block and does the right thing. (And I don't mess much with the default, an
editor that does most thing reasonably form then on I assume whatever else it
does to my code is now the new "right thing").

> A few functional languages promote ideas like “let x in y”

It kind of proves my point -- if you have functions that are going past the
end of the screen, you need to think a bit about the code (also of course
depending on language here, but most languages allow this). Break it up into
functions. For functional languages like Erlang, they really encourage short
functions that are 5-10 lines long. Use function clauses and pattern matching
(with guards) to lay out the logical structure and so on.

~~~
Chris_Newton
_is there a way to alias it to a function local name such as my_handy_function
= <the above>_

I agree, though of course a single function call is a trivial example. It
would be nice if we made more use of intermediate variables for exposition to
simplify complicated expressions more generally, too. But somehow this sort of
idea rarely seems to get promoted whenever long lines come up in discussion.
:-(

 _You need a better editor. That is a solved problem._

I respectfully disagree. Current editors, even the most flexible, rarely do
more than automatically sorting out line breaks and indentation, and rarely
provide more viewing options than collapsing blocks and jumping around to one
cross reference or another. I am challenging the assumption that even the same
symbols in the same order are necessarily appropriate in different contexts.

I think there is a parallel here with the idea that a variable or function
name can be relatively short if it’s only used locally with the full context
available, but it might be better to use a longer, more detailed name or to
add full qualifiers like which package/module/scope the entity lives in if
it’s going to be used more widely. This is a simple case of adaptation that
many programmers would apply instinctively, but it illustrates the basic
principle that using the same name/representation for an idea regardless of
context isn’t always helpful.

 _Break it up into functions._

But at the moment, breaking something into functions for ease of presentation
typically equates to breaking something into functions to establish an
independent scope, to allow wider reuse, or for other non-presentational
reasons.

For example, most languages offer no way to break down a moderately long
pipeline algorithm into stages without separating each stage into its own
function, complete with manually passing all of the context in and passing all
of the results back. If many stages depend on much the same general context
for that algorithm and the stages don’t make much sense outside of the
algorithm as a whole, might we not consider some sort of lightweight,
presentational way to split things up for better readability, without implying
all the side effects and maintenance overheads of full functional
decomposition?

