“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).
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).
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?
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.
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.
“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).