Reading Code: In praise of superficial beauty
corte.si
corte.si
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.
http://corte.si/posts/code/devsurvey/index.html
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.
(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.
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.
* robust, handles all error conditions,
* more or less well structured, I had no problems reading it, although I strongly prefer different coding style,
* is on par with the best examples of C code I have encountered,
* tricks like jumping into if(0) block are common for error handling in C. Once you get used to it, it reads naturally.
So get over it, people. Just because some code doesn't look like what you'd write doesn't mean it's bad. Try to look beyond stylistic issues.
http://en.wikipedia.org/wiki/Broken_windows_theory
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...
It's remarkably clean and well-written.
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.
Other examples of ugly code: screen, Perl (5.x)
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.
(a) his style is internally consistent with itself, instead of being a scattering of random mistakes,
(b) while his style is different, he doesn't do anything that majorly impedes readability, and
(c) he uses the style for a particular artistic effect, instead of just using it because he is too lazy to press SHIFT.
Incidentally I just checked out the redis code base. Gorgeous:
Just because Vim, Mutt, and Procmail are successful doesn't mean their lack of investment in CQ hasn't hurt them.
* broken transparency (and trailing spaces in copy&pasted emails) when run in screen.
* the hoops you have to jump through if you want to script certain aspects (like opening new mails in their own terminals, http://op-co.de/blog/posts/mulit-window_mutt/)
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.