

The Elements of Programming Style: "say what you mean, simply and directly" - MikeTaylor
http://reprog.wordpress.com/2010/03/06/programming-books-part-2-the-elements-of-programming-style/

======
Groxx
On the "single wisest" line:

 _“Everyone knows that debugging is twice as hard as writing a program in the
first place. So if you’re as clever as you can be when you write it, how will
you ever debug it?”_

I wholly disagree, given the ridiculously-simple debugging tools we've got
like GDB, and what's in Eclipse and Visual Studio. Certainly, some things are
harder to debug (intermittent errors, multiple threads / processes & their
problems, etc), but more careful programming around those areas is a good idea
anyway. And if you're _over_ -stretching what you know, it could be that the
problem is harder than you think it is, not just that it's hard to debug.

It's also that many people spend _years_ learning to program, but far far less
learning to debug (if any at all. print statements, anyone?). If that's not a
hint at difficulty, what is?

The rest of the suggestions are overall very spot-on, though, and if nothing
else are excellent advice for almost any programmer (as so many violate so
many of these).

~~~
berntb
More than a decade ago, I was good with debuggers. Today, I can't even use the
relevant variants.

That is partly because I'm doing scripting languages these days (no memory
overwrites, etc) and partly because I write my code so it'll be simple to
debug.

IMHO, I'm more productive. And I'm happier, laziness is my favorite virtue.

Disclaimer: I'm doing too little web stuff, otherwise I'd probably be using
Firebug etc all the time.

Edit: One thing from the book I really agree with, is "Parenthesize to avoid
ambiguity."

I put a marker in my beloved C book ("C: A Reference Manual" by Harbinson and
Steele) on the page with priorities for built in operators/functions. Much
later, I removed the dog ear and decided: If I had to look up the parsing
priorities for some built in functions, then I should use parentheses instead
-- for the people reading (including myself).

~~~
Groxx
gdb hasn't changed much in that time, I think. Have you looked at it? A lot of
debuggers are based on it, so you still have access to a gdb terminal. Though
yes, making easy-to-debug code is _very_ useful, and probably good advice in
general. Easy-to-debug is also usually easy-to-understand.

And I hate trickiness without parenthesizing in large one-liners. My limit is
usually 3 or 4 operators. There's no reason to _not_ parenthesize, and plenty
of reason _to_ , especially for later readability.

edit: just realized another possibility. Are you just out of practice?

~~~
berntb
>> Are you just out of practice?

With debuggers -- definitely, and I like it that way. Not with coding; I'm an
overpaid code monkey this downturn (a bit "golden handcuff"-syndrome).

Edit: I might add that I do use profilers.

------
bliss
I'm guilty as hell! Make every comment count will be my new phrase until I
forget it and revert to crappy comments...

------
olliesaunders
Would anyone like to sponsor me to write an updated version of this book?

~~~
ggruschow
Maybe, but you'd need to show you'd be able to show you can be as concise,
useful, and readable. If you're serious, I'd recommend you do a sample chapter
and outline. You could come back to me if you'd like, but you could shop it
around to more traditional author "sponsors" (publishers) then too.

------
olliesaunders
This is £23 (used) on Amazon.co.uk. That's a lot of money.

~~~
telemachos
I found it about three weeks ago (after some other blogger convinced me it was
worth reading) for less than $5.00 at Amazon.com. So I would say give it a
little time and you should be able to find a cheaper copy.

------
greenlblue
This is just good advice in general.

