

Your code should be as boring as possible - emmett
http://broadcast-tower.socialcam.com/your-code-should-be-as-boring-as-possible

======
jharsman
When I read really great code, I often think "This is all there is?". It seems
like there is too little code to do all the things that it does. Or what is
there seems trivial, so simple that it couldn't have required any thought or
effort to produce.

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.

~~~
jwecker
Similarly, in my experience great code solves a problem that would seem very
difficult in a way that seems very obvious but usually only in retrospect, or
as we're reading the code. A corollary would be code that reveals some truth
about the system being coded that isn't obvious except in retrospect.

~~~
dasil003
This comment reminded me of the epiphany I had my sophomore year in college:
that code is a literal (and physical in a sense) representation of an idea or
system.

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.

~~~
alttab
This is the key to effective programming. I like to measure what the code
_ENABLES_ both the end user, and the programmer in the future (design
leverage) - not just what it _DOES_ _FOR_ the user in a literal way.

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)

~~~
chipsy
Or, to turn it into a pithy cargo-cult statement: "Most code is scaffolding
for your future code."

------
jjcm
I think the point he's trying to make is that in the general case, boring code
is _safe_ (boring in the eyes of someone reviewing your code, that is). That's
not to say boring code is better. Remember the fast inverse square root gem
(<http://en.wikipedia.org/wiki/Fast_inverse_square_root>)? Definitely not
boring, but optimal in the situation that it was in.

~~~
joe_the_user
This argument seems rather contrived really.

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...

~~~
wanderr
Code that is unnecessarily repetitive is annoying. Annoying is not boring.

~~~
joe_the_user
It's a matter of taste but I don't think I'm alone in finding boring to be
annoying.

This leads to the paradox:

Boring => Annoying => !Boring

How would you resolve it?

~~~
wanderr
By learning to appreciate boring. ;)

------
yoak
I wonder if "boring" here just means "clear." I had a great case of this
yesterday. We were reviewing a piece of code by someone that could have been
better with a basic algorithm change. It did most of the right things but in
the wrong order, sometimes on the wrong data, and did one major piece
probabilistically were specific computation wasn't intractable.

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
In my coding, I'm starting to think it's better to write code that is wrong
and clear than "right" and unclear. Because then you can understand it quickly
when you come back to correct it later (note: including correcting the "right"
code, due to bugs, problem change, etc).

~~~
shasta
coworker: This code is clearly wrong

6ren: Thank you

~~~
sophacles
Shouldn't that be:

6ren: You're welcome.

?

------
pessimist
"Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not
smart enough to debug it." – Brian W. Kernighan

~~~
gruseom
It's such a great line, and such a classic one, that you don't even notice
that the premise isn't true. It's like the opening line to Anna Karenina in
this respect.

~~~
lukeschlather
Do you mean that debugging is infinitely harder than writing the code in the
first place (since you can never verify correctness) or that debugging isn't
more difficult? In the former case, while it is factually incorrect, in the
general sense it's true.

If you mean the latter, I disagree.

~~~
gruseom
Debugging is not always harder than writing the code in the first place (let
alone "twice as hard" - what does that even mean)?

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.

~~~
lukeschlather
I guess I'm taking it for granted that any piece of code is going to have
multiple bugs in it, and you're going to spend more time debugging than you
did writing. I still don't think you've said anything that shows the maxim to
be false in the general sense, only in the sense that it could be worded a
little more clearly.

But it's a proverb, not a design spec.

~~~
Dylan16807
More time doesn't mean harder.

------
steverb
Principle of Least Astonishment:
<http://en.wikipedia.org/wiki/Principle_of_least_astonishment>

Applies to code every bit as much as UI.

~~~
emmett
There's definitely a similarity between the two principles. That shouldn't be
surprising since code is basically a programmer's user interface to the
computer.

------
jdludlow

      @sorted = map  { $_->[0] }
                sort { $a->[1] cmp $b->[1] }
                map  { [$_, foo($_)] }
                     @unsorted;
    

Sometimes boring isn't as good as awesome. My first reaction to the
Schwartzian Transform was, "Computers can do that!?" Figuring out what this
thing did, and how it did it, made me a better programmer.

~~~
emmett
I completely agree. Interesting and awesome code is how you grow as a
programmer. And it's the interesting code that can really make your program
shine.

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.

------
d0m
I agree that good code is usually quite easy to read and shouldn't requires
big efforts of the reviewer. When I need to read some functions 2-3 times to
understand it.. or when I need to switch from a "calm/boring" attitude to a
"crap, I really need to think hard" attitude, it's usually a sign that it
wasn't well written. It's not necessarily "bad code" but more of a sign that
the programmer didn't reread himself to make sure it was clear.

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_

~~~
btilly
For decades the received wisdom among good programmers has been that long
functions are inherently non-maintainable. However the actual result of
companies that track maintenance information is that if the function is below
200 lines, the length of functions is not significantly correlated with
maintenance cost. (However a high density of logic within the function is
associated with maintenance cost.)

Read _Code Complete_ if you don't believe me.

~~~
thomasz
I don't have that book at hand right now. I wonder if language plays a role
here. Judging from my own experience, a 200 line stored procedure is quite
manageable, but 200 lines written in a c-like language are a tough nut to
crack.

~~~
btilly
I believe that code bases in C were studied. As long as the number of ifs,
loops, etc was small, the length of the function did not hurt maintainability.

 _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.

~~~
AgentConundrum
_As long as the number of ifs, loops, etc was small, the length of the
function did not hurt maintainability._

<http://en.wikipedia.org/wiki/Cyclomatic_complexity>

------
asymmetric
favorite quote: "if you don't find noticing repeated patterns in code fun
you're probably not a programmer."

------
joshwa
OP is blocked by WebSense--

    
    
       Access to this web page is restricted. 
       Reason: The URL Filter category Pornography is filtered.
    

Is the site nsfw?

~~~
johnswamps
Nope, maybe the domain name "socialcam" triggered it

~~~
michaelbuckbee
This seems the most likely explanation, "Cam" is a commonly filtered term.

------
albertzeyer
Very related: Know your compiler and what optimisations it will already do for
you. I have often seen code which is very hard to read because the programmer
has tried hard to optimise it (e.g. reuse same variables etc.).

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>

------
mannicken
Naive and erroneous input. Boring code. Interesting output. Yep.

------
wulf
bla bla bla I will write my code how I like, thank you very much ...

