Your code should be as boring as possible
broadcast-tower.socialcam.com
broadcast-tower.socialcam.com
Bad code is full of stuff, it twiddles bits here and there, does complicated things in nested loops and works very hard to accomplish very little.
This might make bad code seem more interesting, at first glance it seems like it does more, when in fact it generally does less, just with much more complexity.
That's exactly what I think when I see Peter Norvig's spellchecker: http://norvig.com/spell-correct.html
I know it seems trite.
But I had been programming for years, and I had grokked recursion and pointers, but up to that point I was always sort of thinking of programming as a means to an end, and somehow distinct from the task it was accomplishing. At this point I take it for granted that I can translate my thoughts into this or that programming language, but when I first realized the direct correlation it was like a bolt of lighting.
The code becomes more abstract, more of a model, and the software may become a 'tool'. (You'll find that as you program you will naturally refactor to a more abstract model and things will "click-in" and work the way you want it the first time)
Without knowing that it's a fast inverse square root approximation using the Newton-Rhapson method with 1 iteration using some clever bit twiddling hacks and an initial guess chosen by experiment to be optimally efficient in terms of accuracy and especially for speed you can end up with a lot of problems. First, someone could look at it and spend a lot of time trying to figure out what it was doing before realizing what it did. Second, it could cause people to attempt to replace it without realizing the value of it, causing wasted effort. Third, it could cause people to try to improve it, spending time attempting to find a more optimal first guess, or adjusting the bit twiddling nature in some way. Fourth, and worst of all, it could develop a reputation as a bit of "deep magic" which shouldn't be touched because nobody knows exactly how it works, so nobody ever re-evaluates whether it's worth keeping. As it stands now it's obsolete code given that modern GPUs will perform the relevant calculation in hardware much faster.
Granted, in this specific case a lot of these problems are much diminished (since the company was small, the code and its rationale was well-known by the dev lead, and it's reasonably straightforward to reverse engineer the operation and rationale for the code with some investigation), however this might not be the case somewhere else with some other piece of comparatively magical code.
When you write a bit of WTF code that's actually worthwhile imagine that everyone that worked on the code is now dead and researchers are studying it, what information would those researchers want the most? Now put that in a comment.
P.S. Also, god help you if you happen to be lucky enough to have a chunk of poorly documented "deep magic" code that happens to have a defect in it.
Even the article essentially admits that there are many cases where what is normally seen as boring is actually dangerous - just he redefines these cases as "not boring".
Specifically, repetitious code is the most obvious case of boring and that's not at all safe. He just redefines that as "not boring" because it raises red flags for him. But that's pretty strained reasoning to say the least.
Code that is almost repetitious can also be dangerous because spotting where the changes are can be hard and the repeated parts can lull you into comfort.
Of course, code normally shouldn't be too interesting either but that's a different question.
It seems like it boils down to something like a boring code review indicates safe code because everything that's interesting at that point is a problem.
OK then...
This leads to the paradox:
Boring => Annoying => !Boring
How would you resolve it?
The coder wasn't completely getting our explanation, but the code was so "boring" or "clear" that we opened up an editor, copy-and-pasted some blocks around added a few if statements and expected it to be basically functional. This was a complex algorithm and a complex change, and we offered provisos that we didn't know what that function returned so a "not" might have to go in front, and a variable name would have to be changed and one piece was going to have to operate on a new key in memcache, but it was basically there.
The point is, the code was so well-written that we could read it well enough to do this never having seen it moments before, and our resulting chopping was clearer to the original coder than 20 minutes of histrionics on a whiteboard full of formulae. That's how it should be. :-)
And for any haters in the crowd, it was all in Perl. So much for "write-only" complaints. :-)
6ren: Thank you
6ren: You're welcome.
?
If you mean the latter, I disagree.
Debugging doesn't mean proving there are no bugs. If it did, the quote would be even more wrong, since our inability to do that has nothing to do with how cleverly code is written. But that's beside the point, since nobody uses "debugging" to mean this; it means tracking down and fixing bugs you know about. And it's trivial to see that that's not always harder than writing the code in the first place: some bug fixes (e.g. typos) are easy.
But it's a proverb, not a design spec.
Applies to code every bit as much as UI.
@sorted = map { $_->[0] }
sort { $a->[1] cmp $b->[1] }
map { [$_, foo($_)] }
@unsorted;
When I see an interesting bit of code it's still a warning sign though. Because for every time the Schwartzian Transform was implemented well, 100 programmers reimplemented it badly in a language where .sort_by(func) already existed.
Given a stack trace pointing to that single line of code with an exception, could you immediately figure out what had gone wrong? Would you know what to fix before you even had the code up in the editor?
That's something you can do with well-written production code. It's not particularly sexy to look at, but it's built for debugability.
Split that little kernal of awesome into 7 distinct lines that your CS101 nephew can explain back to you. Then it's ready to go live.
Anyway, for me, the biggest hint for a bad code is big functions. It's somewhat really counterintuitive and I can't understand why people still continue to write like this. And worst, they sparse comments to separate the different sections of the function.. gasp
Read Code Complete if you don't believe me.
However in this does result in language differences. In practice the density of ifs, loops, etc tends to be higher in a C-like language than in a stored procedure. So the complexity of functions tends to go up.
The research cited is, however, quite old and did not include any OO code. Method dispatch can hide an implicit "if", and I don't know whether that tends to affect the maintainability of code in practice.
Access to this web page is restricted.
Reason: The URL Filter category Pornography is filtered.
Incidentally, I got exactly the same thing from "Smart"Filter at work. Like the others, I suspect that having "cam" in the URL makes it look suspicious.
Here is an interesting read: http://www.fefe.de/know-your-compiler.pdf
And also a lecture video: http://chaosradio.ccc.de/camp2007_m4v_1952.html