* 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.
To this, courtesy of the "Linux kernel coding style" [1] -
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.
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.
> Maybe in context of old C, but in java you have two nestings just for being in class method. So as a general point, it does not stand anyway.
In reference to your above point. You’re saying modern Java makes you start out at 2 levels of indentation. I’m saying your modern monitor’s width compensates.
Sure, you can set it to 4 and a properly formatted code will just adjust. That's granted, but irrelevant. The question is in usability of different tab sizes.
There's a happy medium between function names being 2 letters and function names being a full damn sentence.
I personally prefer common things to have short names, less common to have long names. That's how natural languages work, and i think it makes a lot of sense. If everything has a long name, it ends up being hard to pick out the important bits. If everything has a short name, it also becomes a bit impeneterable.
> 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.
I agree.
Short names don't make code readable, they make typing less work. In my opinion this means the author used the wrong tool. If you don't want to type long names, use an IDE with auto-complete. Don't make the reader suffer from your laziness.
Naming is difficult. Naming requires intelligence. There is no simple set of rules to follow to do it right for much the same reason there is no simple set of rules for writing a novel or any other creative work. Being good at it is partly due to experience and partly talent.
Is a single-letter name for a function ever correct? Absolutely. Is it always correct? Obviously not. Knowing when to use shorter names versus longer names is a big part of being a good programmer.
I prefer single letter or short names if they don't have a specific purpose. Like for just another simple for loop, I'll use "i" instead of "elementIndex".
But if there's more to it, I prefer a proper name, even if it's used only on the line right below it.
The point is to make the code as self-documenting and readable as possible. It's always trade-offs. Sure 5000 column lines are not good. But strict 80 columns can also reduce readability. Similarly superlong or supershort identifiers aren't always good, but can be.
Some linters (eg ESLint) have rules you can enforce for cyclomatic complexity (which is often the problem with long functions, rather than the length itself). In the service I maintain, we enforce a cyclomatic complexity of 5, which is pretty low but it yielded good results
Good question, I suppose it would? On the other hand we do have chunky switch statements (as it allows exhaustive type checking in Typescript), so not so sure now that I think about it, I'd have to check
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.
That said:
* Narrower is easier to read
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.
* Side-by-side works better
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.
* Better diffs
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.
* It encourages shorter names
Arguably an anti-patern.
> 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.
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
* Just a few spaces per indent level
ok, so I like this. =)
* Many indent levels is wrong anyway
Absolutely. Make methods and give them proper names. Go Daniel!
* Why exactly 80?
.. 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.
* Enforced by a tool
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.
>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.
Because code is harder to read that prose I think that favoring short lines is better. It forces you into breaking your code in more digestible bits rather than a 500 char single-line monster statement. Honestly it's very similar to the argument against very deep indentation (forcing you to break your code in subfunctions) so I wonder why you feel differently about this.
>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.
I don't understand what you mean. Succinct how? If you have only ever encountered succinctly written code I envy you.
And it's not just about comparison, I generally have two or three different code listings side-by-side, or maybe some code on one side and a manpage on the other for instance.
>> It encourages shorter names
>Arguably an anti-patern.
Agreed. Sure you shouldn't go overboard java-style but very explicit names are never a bad idea. That being said even a very long symbol will seldom exceed 30 chars in my experience, so it's not really an argument against 80 columns either.
We all agree on indentation.
>> Enforced by a tool
> 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.
Now that I 100% disagree with. If your code is supposed to be a quick hack and a placeholder then add a comment saying that, relying on subtle formatting cues to judge the quality of some code seems very fragile.
Tool-enforced coding style is good. It saves puppies. It makes waterfalls taller. It makes the air taste sweet. And more importantly it means no more bickering and bikeshedding about coding style.
Uniform code will always be more readable than a codebase where everyone has their own idiolect.
I often find myself working with Fortran, you know, back when punch cards only had 80 columns.
Let me tell you my friend, nothing about it is "more readable". In fact, you are likely to find lots of dirty tricks to make the code fit om cards which ends up obfuscating things.
> It forces you into breaking your code in more digestible bits rather than a 500 char single-line monster statement. Honestly it's very similar to the argument against very deep indentation (forcing you to break your code in subfunctions) so I wonder why you feel differently about this.
Breaking code into digestible bits is only a solution when you can use it.
I believe it is good if you take it as a guideline not as a rule.
Having extensively programmed in SQL, I've had to deal with monstruous pieces if code. And sometimes there is no way to refactor them. Sometimes because of quirky performance, sometimes because of legacy, sometimes because higher-ups decide to incur tech debt. Views, functions, CTEs and temporary tables help but are no panacea.
In SQL, you can quite easily enforce a line length limmit (though you might want to break it at times for table style readability) but enforcing a line count limmit is unphesable.
I imagine enforcing a line length limmit on a language with line breaks as instruction separators to be a cripling rule. Yes, you can store things in variables, you can split code into functions, and all of these might help readability but they might also hinder readability.
Anytime you work with things resembling wide two dimensional arrays (arrays, consecutive assignments of functions with the same signature, members of a structure, etc.), linebreaks in any other place other than between rows of the array are a hindrance to readability. You can break the line at predetermined points (e.g.: after the fifth, ninth and twelveth parameter for a particular function) and if there is code between the "rows" or if you need comments this approach is preferable. But if the "rows" are consecutive and there is nothing to explain in comments and the languages does not allow you to colapse "columns" and you need to do this often enough, then enforcing a line length limmit is harmful to readability.
Rather than blindly following a rule like 80 char limmit, I prefer to try to stick to the prefferd conventions of each language. If there are none appliable, find what works for the project. Line length limmit is helpful, but not paramount.
> >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.
> Because code is harder to read that prose I think that favoring short lines is better. It forces you into breaking your code in more digestible bits rather than a 500 char single-line monster statement. Honestly it's very similar to the argument against very deep indentation (forcing you to break your code in subfunctions) so I wonder why you feel differently about this.
That's the thing. It forces a limitation on me that's not designed for making code more legible.
Look at this example from the curl project: https://imgur.com/gallery/yialLe7
Making the code legible has nothing to do with the number of chars. It's about the effort. The 80 chars limit is not helping.
> >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.
> I don't understand what you mean. Succinct how? If you have only ever encountered succinctly written code I envy you.
I do end up re-writing a lot of code =).
But I'm not shy about fixing it where I see it. Legibility and skimability are the two major driving forces.
But comparing once method to another in code and implementing algorithms is almost never a problem on a big screen. I find that it's very seldom something interesting happens on the far end of 150 characters. That's usually debug output or some line I'm not gonna be interested in any way. I'd much rather fit an entire class in one view than having 2/3 of my screen empty as I scroll up and down.
Particularly with something like rust_fmt. shivers
>>> Enforced by a tool
>> 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.
> Now that I 100% disagree with. If your code is supposed to be a quick hack and a placeholder then add a comment saying that, relying on subtle formatting cues to judge the quality of some code seems very fragile.
See the image above and find me a formatter that will let me keep that thing legible.
I'm not against formatters or formatting. I'm against the rust_fmt way. You're cover up the signal with a bunch of whitespace vertical noise.
Code comments are also an anti-pattern in my mind. If you need to put comments in your code, you aren't done yet. Use a method and make it describe what it's doing. Comments are an absolute last resort.
> Tool-enforced coding style is good. It saves puppies. It makes waterfalls taller. It makes the air taste sweet. And more importantly it means no more bickering and bikeshedding about coding style.
Huh. I've been wondering what all these puppies were about.
> Uniform code will always be more readable than a codebase where everyone has their own idiolect.
I find it wont. Not really. It'll just disguise all code to look the same and force you to actually read code to figure out what's going on rather than just skimming it.
Besides, healthy discussion within a team are a good thing. We might come around to each other opinion. Something extraordinary maybe makes sense for us. The conformist view of one size fits all is .. just wrong. imho.
>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.
You speed read code all the time - when working on a codebase you can pinpoint the exact segment of a line you're interested without even parsing the whole line. For example if you're trying to modify an argument that's being passed from parent scope - you navigate there and just go to the argument on the caller - you don't read the previous arguments or call definition, you don't read surrounding lines, etc. you just know where you are and what you want to change.
Having a limit on width is very useful - but 80 is too constraining because of indentation and using descriptive names (assuming you don't obfuscate your function names, like you said an anti-pattern).
I personally like 120 characters :
- beyond that and the editor takes up too much horizontal space and my eyes need to jump too far from line start to end, I've worked on a ruby project that had unconstrained line length and it was a nightmare even after a year spent on the project
- below that I have to break too many lines that shouldn't really be broken, worked on a project in JavaScript that had 80 character limit as well a long time ago and it was a complete mess, it directly impacts the way you organise code and not in a good way IMO
> Nobody's speed-reading code. That doesn't make sense.
Well, I speed-read code all the time.. it's a necessity in my role as independent consultant. Clients have a lot of half-baked/unfinished projects, and I'm called in to get it progressing. Speed-reading enables me to assess the state of the existing code and suggest a way to move forward, without breaking the bank up front.
That said, for me column width is irrelevant for speed-reading. The typical time-killer is lacking separation of concerns and poor naming conventions (God classes, or worse, God files with 20 classes)
I skim code a lot. like A LOT. But I don't _read_ it. I try and figure out where I am by looking at context and clues and only drill down into the important looking tricky buts. It kinda sounds like we're on the same page here
> That said, for me column width is irrelevant for speed-reading. The typical time-killer is lacking separation of concerns and poor naming conventions (God classes, or worse, God files with 20 classes)
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).
When I get tired of actually arguing for 80 columns, I just say that using 80 columns is actually too many columns, as it excludes developers who program on systems with 40 columns; it's no chance that the most sold home computer in history had 40 columns.
Without arguing about 80 columns being optimal or not, this is the author's habit:
> I frequently have two or more editor windows next to each other, sometimes also with one or two extra terminal/debugger windows next to those. To make this feasible and still have the code readable, it needs to fit “wrapless” in those windows.
It's not clear whether the terminals are horizontally next to each other, however one must consider that in his calculations, there is the presupposition of extra programs (other than the editor) horizonally stacked on the same screen. The sky is the limit, with such presupposition.
I still contend that 40 columns should be the maximum, as in addition to the editor, any sane, productive developer should keep one or two terminals, the team chat, and the music player stacked horizontally on the same screen. /s
A minor nitpick - it's a 80x12 bits, not character rows. It held one 80-column line on each card. When I did it (a looong time ago) the reader printed the line on the top of the card.
The cards were one of the reasons CRT-based terminals such as the 2260 and 3270 had 80 characters per line (VT-52 had 64 and there was some 3270-like terminal w/ 40 columns.
Never said anything else. The rows I've mentioned were clearly the rows of bits (represented by presence or absence of a hole). From a pure theoretical point of view it still appears to be wasteful (as the used character set encodings didn't use all representations of 12 bits), but there were "good enough" reasons behind that decision too: It all started from the design of the tabulating punched card from the 19th century, and from every digit 0-9 having its own row, and two more rows for other marks. The hardware depended on these properties.
125 years ago, the logic I've described was already there, 12 rows but still less columns on this card:
But how often do you really have 80 columns? With indentation you chip away on the left side and with a few indentation levels you have not as much space left.
Code I can somewhat understand. Notes and email though should be soft-wrapped where line length is totally up to the client.
On mobile: get a 60 char line followed by a 20, and repeat
When editing in a basic editor: changing any text half way through a paragraph requires manually removing and re-adding the line breaks (if they're lucky)
I prefer the approach used by markdown. Use whitespace to define semantic elements, ie. headings, paragraphs. Encourage hard wrapping in the "source" file to improve readability on simple/dumb displays (e.g. cat, less, nano etc.). Encourage fancy rendering of semantic elements where possible including user-defined line length, line/paragraph spacing etc.
At 80 lines I can stack comfortably 3 windows of code on a medium-size screen. At a large screen, 4 windows of code.
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.
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.
Depending on the project, I would go as far as 120 characters for Python. Normal small Python scripts, somewhere around 80 - 90 seems plenty.
Working with class, using something Django, I'd go up to 120.
It doesn't really matter though. What matters is that your team pick something and agree on it. The large scale Python projects I've worked on all required that code be run through flake8, but with a custom line lenght, normally 100 to 120.
I use 80col/8space tabs with Python code. I don't recommend it. I use it because when I started a project on which I'm still working I was using it and it's lead to very ugly code though much of the blame is mine rather than the format's.
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.
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.
Try to display heavy 80-chars code in a 70-wide window and you'll see (same as for some emails).
> 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”...
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.
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.
[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.
> 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.
I agree with everything else in the article, except this. IMO two-space indentation is the cancer of the JavaScript world. I find it extremely 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
The 80-column war remember me the TAB vs Space dispute, I'm a 4 spaces man :)
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.
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:
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?
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.
[1] https://github.com/torvalds/linux/blob/master/Documentation/...