* 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.
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.
[1] https://github.com/torvalds/linux/blob/master/Documentation/...
The first version is calm and honest, does not pretend preference is actually somehow objective universal statement.
His point still stands though - if you ever need one too many indent levels, the code could almost certainly use simplification.
Really? I can't read it as anything but tongue-in-cheek.
I default to the idea everything is potentially-insincere, especially online. Do you not?
Exactly like 80-width code on a similar small editor.
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 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 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.
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.
But I've seen the opposite... Horrors with globals and other re-used all over 1000+ line functions. :/
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.
Heck. I start to itch breaking Python modules when they cross the 1000 line barrier.
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.
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.
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.
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.
> 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.
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
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)
Exactly. Couldn't have said it better
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
It really depends on the language, but 40-columns is actually not bad if you are programming for an 8-bit computer in BASIC.
One should avoid having overly long, multi-statement lines anyway.
https://en.wikipedia.org/wiki/Punched_card
“A 12-row/80-column IBM punched card from the mid-twentieth century”
The hardware was produced to match the fixed limitations.
Note: even with 12 rows a punched card traditionally stored only one line of the source text. That allowed editing by replacing one or more cards.
Also, even more details:
[1] https://en.wikipedia.org/wiki/Punched_card#IBM_80-column_for...
I paid for the whole monitor, I'm gonna use the whole monitor!
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.
80 columns work better, even when reading the code with the smartphone.
Most also write great code, but all of them write impossible to read notes and e-mails everywhere else.
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)
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 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.
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 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.
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).
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.
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.
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.