Compare this -<p><pre><code> * Just a few spaces per indent level *
To make this work, and yet allow a few indent
levels, the code basically have to have small
indent-levels, so I prefer to have it set to
two spaces per level.
</code></pre>
To this, courtesy of the "Linux kernel coding style" [1] -<p><pre><code> 1) Indentation
Tabs are 8 characters, and thus indentations
are also 8 characters. There are heretic
movements that try to make indentations 4 (or
even 2!) characters deep, and that is akin to
trying to define the value of PI to be 3.
Rationale: [snip]
Now, some people will claim that having 8-
character indentations makes the code move
too far to the right, and makes it hard to
read on a 80-character terminal screen.
The answer to that is that if you need more
than 3 levels of indentation, you’re screwed
anyway, and should fix your program.
</code></pre>
Having used 8-char tabs for a very long time, I now find looking at smaller tab'ed code a somewhat unpleasant experience. It feels like the code lacks enunciation. As if it mumbles.<p>[1] <a href="https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst#1-indentation" rel="nofollow">https://github.com/torvalds/linux/blob/master/Documentation/...</a>
>A function name, and especially local ones, should be short.<p>I have more problems reading code with short names rather than long. C code with one or two letter variable names often looks impenetrable to me.
First of all let me start by saying that all my lash language is tongue-in-cheek. If you need a visual, you can imagine me poking you in the ribs at the bar and having a laugh. I have nothing but respect for Daniel and his work.<p>That said:<p>* Narrower is easier to read<p>Yes, for prose. And no one actually said easier, they said faster. Code is typically full of parenthesis special notations and characters. Nobody's speed-reading code. That doesn't make sense.<p>* Side-by-side works better<p>Marginally. Most code is pretty succinct anyway and you can easily compare it side to side. In real life, this is almost never a problem.<p>* Better diffs<p>Don't conform your code to fit your tools. Use tools that fit your code. There's plenty of good diffing tools and git clients and editor plugins that make this a breeze.<p>* It encourages shorter names<p>Arguably an anti-patern.<p>> I know especially Java people object to this as they’re trained in a different culture and say that a method name should rather include a lot of details of the functionality “to help the user”, but to me that’s a weak argument as all non-trivial functions will have more functionality than what can be expressed in the name and thus the user needs to know how the function works anyway.<p>You shouldn't have to read a lot of code to understand it and locate problems and botlenecks. If your code requires grokking and keeping vast amounts of methods in your head you're wasting valuable cognitive load<p>* Just a few spaces per indent level<p>ok, so I like this. =)<p>* Many indent levels is wrong anyway<p>Absolutely. Make methods and give them proper names. Go Daniel!<p>* Why exactly 80?<p>.. technically not a part of the argument, but I'm glad it's here. 80, 100, 120, 160, 200? It doesn't matter. Either full freedom to express myself to the best of my abilities or it doesn't matter.<p>* Enforced by a tool<p>The root of all evil. A tool for stripping away context and making hackily written code under pressue and time limitations and carefully planned out code look the same to the naked eye.
When I get tired of actually arguing for 80 columns (legibility, shorter names, fewer indent levels, etc) I just say that "God made the VT-100 with 80 columns for a reason" (which is amusingly incorrect on many levels).
I agree with the original poster.
Here is an example of a C++ source I have written implementing the code style I feel more readable: <a href="https://github.com/gioblu/PJON/blob/master/src/PJON.h" rel="nofollow">https://github.com/gioblu/PJON/blob/master/src/PJON.h</a><p>80 columns work better, even when reading the code with the smartphone.
At 80 lines I can stack comfortably 3 windows of code on a medium-size screen. At a large screen, 4 windows of code.<p>It is actually very useful. Function takes parameter that's a class instance, then you call a method on the return value... and you can see the code to all those at the same time.
I completely agree with all of this. I'm happy that someone has taken the time to write these arguments down in one place so I now have somewhere to refer to if the need arises.<p>I happen to use 88 character line lengths in Python which I think accounts for it being slightly less terse than C, but the actual line length is neither here nor there really. It's much more important for a project to just define one, make it reasonably short, and enforce it rigorously.
Very interesting article!<p>I try to stick to 80 but often times find the code is more readable when some particular lines are longer than 80. I dont see any reason to impose an arbitrary historical constraint when it will make the code harder to understand.
I always configure and use line wrap on all my editors, consoles and other text displays when possible.
You have a 1000 chars wide display? Use it all. You are working with multiple windows 50 chars wide each? Use it all.<p>Having long lines simply because you like long lines is usually hard to understand, but the opposite is also true. Each line should be 'one logic instruction', splitting a function call for the last parameter looks just wrong (for me) specially if it is placed below with 70 spaces at the beginning.<p>Try to display heavy 80-chars code in a 70-wide window and you'll see (same as for some emails).
> <i>I know especially Java people object to this as they’re trained in a different culture and say that a method name should rather include a lot of details of the functionality “to help the user”...</i><p>There's this. But there's a stronger argument for more columns in Java: The standard library itself uses very long names, so you can't escape them, and the syntax of the language creates many levels of indentation even when you avoid things like nested conditionals and loops.[1] No matter what you do with your own coding conventions and naming, Java ends up feeling cramped in 80 columns all by itself.<p>In general, though, I heartily agree with the article. I just disagree with the tacit assumption that one size fits all. Make your code as skinny as is feasible, but no skinnier. My Java code's 100 columns, but my only strongly-felt complaint about Black is that I think Python code is happier at 80 columns.<p>[1]: For example: An if-statement within a try-block within a method within a nested class. That's five levels all by itself, probably with no straightforward way to refactor your way out of it.
> Just a few spaces per indent level<p>> To make this work, and yet allow a few indent levels, the code basically have to have small indent-levels, so I prefer to have it set to two spaces per level.<p>I agree with everything else in the article, except this. IMO two-space indentation is the cancer of the JavaScript world. I find it <i>extremely</i> hard to read.
Probably the language can help to "stay" at 80 like C or C++ but I dare Daniel to write Objective-C or Swift and stay at 80 columns, it's possible but it's hard and I prefer to write code than add carriage returns<p>The 80-column war remember me the TAB vs Space dispute, I'm a 4 spaces man :)
> It encourages shorter names...<p>I can't remember my source right now, however I recall a study which indicated that having more descriptive variable names contributed more to the overall perception of code quality and legibility than nearly all other factors. If I recall correctly it was a study into code quality metrics commissioned by a large company. This strongly echoes my own experience. Naming variables like you're paying by the letter contributes heavily to making the job of understanding the code on a line-by-line basis much more difficult for other people.<p>For what it's worth, when I write in C/Ada/Python/Perl I stick to 80 columns. When I'm writing in OOP languages I usually limit myself to 90, and definitely less than 100.
So, my argument against "side by side is easier" might seem niche, but here goes:<p>I prefer tall-screen versus wide-screen for reading - and not just code but reading in general. The article actually hints that this is default for many people whether they realise it or not, because of newspapers and books. When was the last time you read a book with pages wider than they were tall?<p>On my screen, side-by-side terminals snap to 69 columns, but I can easily have 132 columns take up the whole width, and just use top-by-bottom to compare. As it is, I don't have a huge monitor, anyway, so I tend to use workspaces to give me more room, but that's neither here nor there as far as this argument goes.
I try to stick to 80 as well, if it does not work out, I go to the new line and indent. It works neatly with my 80x24 xterm window and tools such as less, emacs, and so forth.
When I put two text windows next to one another on my work monitor it allows lines of 94 characters. Therefore, that is my favorite maximum line length.
In my class at university the line length was 132 because that's what the professor could fit on his screen side by side at his preferred font size. That's as good a rationale as any for these things, particularly in that setting where one person is looking at a lot more code than anyone else.
Linus argued against it half a year ago.<p><a href="https://lkml.org/lkml/2020/5/29/1038" rel="nofollow">https://lkml.org/lkml/2020/5/29/1038</a>