No doubt a lot of people agree with this post, but I feel compelled to point out that he doesn't actually present an argument, just a claim. He simply states that a lack of superficial beauty is the best indicator of a lack of code quality and then says it is such basic advice that it needn't be given.
It may be true, but aside from preaching to people who already believe this to be true, what does this post give us? No statistics examining Github projcts and correlating inconsistent indentation with defects measured.
So while the claim may be correct, I can't support this post. An interesting post would present evidence or at least hypothesize a mechanism for the relationship. For example:
Does inconsistent code correlate with multiple programmers working over a long period of time, adding kludges and hacks tht dilute a design?
Are sloppy indentors sloppy thinkers on everything?
Does poor architecture have a social effect that repells good coders, until sloppy coders are the only people that will work on it?
Personally, I suggest that one (not necessarily the only) mechanism in play on some cases is that good programmers are interested in a wide spectrum of good practices, and there is a correlation between any two random good practices on this basis alone. I wager a dozen bottles of craft brewed beer there's a statistcal correlation between consistent code style and test coverage but absolutely zero causal relationship between the two.
A good case for one of these or any mechanism would find me far more interested. Until then, it's folklore. It might be true, but it isn't going to persude people as much as confirm what people think they already know.
Also, it's crucial to establish whether there's a causal relationship. Because if not, there's a danger that everyone will rush out and go cargo cult, formatting their code and writing style guides, with the result being highly readable dreck. If you want to write quality code, we can't settle for an ndicator, we need to know which practices create quality.
I'm the author of this post. It would be interesting to see if one could find some objective way to measure a correlation between defects and stylistic sloppyness. A few years ago, I whiled away some time by extracting a huge amount of data from Github projects and writing a post showing some interesting differences between languages:
It shouldn't be too hard to use the same sort of technique in this case. One idea would be to use the number of unclosed bugs on Github per line of code as a proxy for software defects. Then you could ask if there's a correlation between unclosed bugs and, say, inconsistent indentation or formatting. There are all sorts of sampling issues here, but it might be interesting to play with - if anyone wants to collaborate on something like this, drop me a line.
As for mechanisms and causation, this is of course harder. It's not difficult to come up with hypotheses - it seems trivially obvious that code that is harder to read would cause coders working with it to make more mistakes and address issues more reluctantly. Proving it is something that probably should be tackled somewhere more formal than a blog post, though.
i remember when i was at university, studying for my phd, working with the smartest people i have ever known. what surprised and depressed me most was that they were so inconsistent. i wanted all these brilliant people to share my politics, which i felt obviously right. they didn't. i wanted them all to be nice people. they weren't. they weren't even consistently beautiful. the only thing they had in common was that they were all very smart.
it would be so nice if simple, visible, easy to measure, but ultimately facile appearances were strongly correlated with deep, complex, hard to measure, but important traits. life would be so much simpler.
And what about the other side? If I apply every formatting trick, keep my methods short, and document everything (not including the "increment i" documentation), does that mean I have mastered software development? I think not.
Proving it is hard, I would hate to apply that standard to my own posts! I was trying to call for some hypotheses. Even if unproven, a hypothesis for the mechanism is useful, becuase it spurs more focused debate, and maybe someone else will prove or disprove it.
I don't agree with the original author that this kind of superficial beauty is the best indicator of a lack of code quality. However, I like to use the following slightly devil's advocate-y argument that readability usually matters more than just about any other property of code, including correctness and good performance.
(In the absence of any standard definitions, let us take "readability" to mean "ease of extracting useful information from the code" and "maintainability" to mean "ease of making useful changes to the code".)
First, observe that most software projects are developed over an extended period and evolve over time. As a basic approximation, assume 75% of development time on such projects is spent performing maintenance on existing code. Assume also that half of that maintenance time is spent understanding that existing code.
Now, even if the code today has positive attributes such as correctness and good performance, those properties will only be sustained if the code's maintainability is good, because code is typically changed several times after it is originally written and if it is too difficult to make useful changes during maintenance then quality and efficiency will be reduced. Moreover, given the proportion of maintenance time spent on program comprehension, good readability is a necessary (though not necessarily sufficient) condition for good maintainability.
Thus, readability is paramount, because without it you can't have good maintainability, and without that you won't sustain any other desirable properties in the long term even if your code has them today.
The exception is when future maintenance of the code is low priority or irrelevant, for example if you're about to ship something that can't easily be changed once it's out the door, at which point obviously you care greatly about things like correctness and performance today.
The above argument doesn't say anything about whether "superficial beauty" actually affects readability as I have defined it. However, it would not be unreasonable to guess that it does, given that good visual design and typography have been shown to affect comprehension and reading speed under many different conditions. While I know of no research addressing the general influence of cosmetic presentation on bug count, there has certainly been research done into more specific questions. For example, in one study, using indents of 2-4 spaces measurably improved program comprehension relative to using either no indentation or indenting by 6 spaces (even though subjectively some programmers preferred the larger indent).
I haven't tried to present this as a rigorous argument with sources because I'm not sure the detailed statistics really affect the general gist of what I'm saying anyway, but FWIW all of the assumptions and figures I've chosen are based on extensive personal study of resarch literature, so they're definitely a reasonable starting point.
I'd have to agree that if the example code in this article is the worst code you can come up with within a large complex team based project you should count your lucky stars.
I fully agree with this post. And it would not surprise me if parallels could be found with the so called 'Broken Windows' (no pun intended ;) theory from criminology.
That is, similarly to how a messy, run down environment invites anti-social behaviour and crime, the less tidy a code-base is the more corner-cutting will be invited on more structural levels as well...
I completely agree with this post. Beauty of code is directly indicative of more meaningful quality metrics. I don't think this is merely a chance correlation either. I think beauty itself is our minds way of noticing certain qualities that have proven to indicate quality.
I think calling it "superficial beauty" undermines the quality he's looking for, which in my opinion is "human readability". A human has to make multiple passes to parse something like this, and that's entirely unnecessary.
OpenSSL isn't the best example to use. Cryptographic code is quite challenging to write because it needs to factor in timing analysis attacks (via cache misses, branching with different execution times, etc). For this reason, use of normal programming approaches may be incorrect from a security standpoint.
How do IDEs factor into this theory? It's easy to make pretty code these days in a variety of languages without actually writing it yourself.
The other factor that comes into play is time to implement. Most startups are always in crunch mode of one type or another. Everything needs to be done last week, so getting it done quick is more important than getting it done right (this is the manager's viewpoint, not mine, but it is a popular one). So you do it and you tell yourself you'll fix it later, but later comes and you're on to the next deadline, so it never gets re-written. Are you a bad programmer?
I appreciate the idea of beautiful code, but it doesn't survive contact with the real world, especially if the real world is running scrum.
I get the gist, yes there is some code that is really really ugly and almost incomprehensible at times (I'm looking at you Perl jk) but on the more granular level of "not ugly" code I feel like beauty is somewhat in the eye of the beholder.
One thing I get very tired of is people pushing their stylistic choices as the beacon of good code. I think its hard for us to at times be accepting of code that is not in our style because it can require a bit of an adjustment to comprehend it. I've seen so many tiffs over seemingly meaningless things like placement of curly brackets its absurd.
The example code in the article does have some stylistic things you could nitpick on and could be pointed out in a code review but if that sets off your alarm bells I would highly advise that you don't work at a place that does heavy outsourcing if you want to maintain your sanity.
Totally. A programmer who doesn't care about code style is like a writer who's fine with misspellings and sloppy punctuation. The story (or algorithm) can still be awesome but the way it's expressed matters a lot when other people will be forming opinions from it.
A counterpoint might be that Vim, Mutt, and Procmail are all highly popular, long-lived projects. Making the case that code quality isn't the be-all and all-all.
Of course not. It's probably not even the #1 priority for more than a handful of projects. But I think the relevant question to pretty much everyone is: "do investments in code quality pay off?"
Just because Vim, Mutt, and Procmail are successful doesn't mean their lack of investment in CQ hasn't hurt them.
Few people seem to contribute to the actual Vim code base though, considering the amount of coders using the software. Several complete rewrites have been started - with a better code quality perhaps the efforts could've been put into Vim development.
I agree with the major points in the post, and even think that code format guidelines like K&R for C, PEP8 for Python, and jslint for Javascript should be freely broken by experienced programmers whenever the beauty of the code is unambiguously improved.
Incidentally I just checked out the redis code base. Gorgeous:
Rather than bitch about the work that someone generously donated for your benefit, why not roll up your sleeves and contribute a patch that makes things "better". With FOSS you get what you pay for.
Think about submitting a pull request to a major project reformatting the code and renaming a lot of variables.
This will touch so much code that reviewers will consider it high risk. But it doesn't fix any bugs, add new functionality, or refactor the code to make something else easy. It's risky now with a hard-to-quantify payoff later. On top of that, our current tools make this painful, a pervasive patch like this will produce a lot of merge conflicts unless handled carefully.
I see a lot of forces acting against rolling up our sleeves and fixing code beauty on a non-trivial project with a lot of users and committers.
You may as well repeatedly shoot yourself in the face for all the good cleaning up code will do. It's indented like a train-wreck because someone wanted it that way and they will likely fight you tooth and nail to keep it as it is.
Code generally is bad either because the writer doesn't care or was in a hurry, or because they don't know better and they think they /are/ writing good code. If it's the former they might accept a patch to clean things up, but if it's the latter I doubt they would.
It may be true, but aside from preaching to people who already believe this to be true, what does this post give us? No statistics examining Github projcts and correlating inconsistent indentation with defects measured.
So while the claim may be correct, I can't support this post. An interesting post would present evidence or at least hypothesize a mechanism for the relationship. For example:
Does inconsistent code correlate with multiple programmers working over a long period of time, adding kludges and hacks tht dilute a design?
Are sloppy indentors sloppy thinkers on everything?
Does poor architecture have a social effect that repells good coders, until sloppy coders are the only people that will work on it?
Personally, I suggest that one (not necessarily the only) mechanism in play on some cases is that good programmers are interested in a wide spectrum of good practices, and there is a correlation between any two random good practices on this basis alone. I wager a dozen bottles of craft brewed beer there's a statistcal correlation between consistent code style and test coverage but absolutely zero causal relationship between the two.
A good case for one of these or any mechanism would find me far more interested. Until then, it's folklore. It might be true, but it isn't going to persude people as much as confirm what people think they already know.
Also, it's crucial to establish whether there's a causal relationship. Because if not, there's a danger that everyone will rush out and go cargo cult, formatting their code and writing style guides, with the result being highly readable dreck. If you want to write quality code, we can't settle for an ndicator, we need to know which practices create quality.