That's basically synonymous to generic test driven development, unless you have some magical way of finding errors in code without running some sort of test on it? (Which includes tests like static analysis, valgrind, etc.)
The author's common mistakes scare me for being common. Not that I consider myself a great coder, but come on...
On a personal note, code I write in C++ (especially C++, which I've done a lot of at school) and frequently code I write in Java (which I do a lot of in my day-job) rarely 'works' the first time (though 'work' in this sense is more 'compiles'; runtime is usually pretty good except in C++ with its segfaults that require whipping out gdb and hoping it's not a template error). On the other hand, if I'm using a language I more naturally think in like Python, it's rare that stuff doesn't Just Work at runtime. And when it doesn't work, it's usually because of something I hadn't thought of in the design (and wouldn't even be in any hypothetical pseudo-code written beforehand), and easy to fix. Ahh Python...
That reminds me of an old adage from a former colleague back at H.P. He said start with the null program, and debug it until it does what you want. :)
I do concur with the author's point (3), where he recommends starting with the high-level syntactic forms and fill them out from the top down.
That has more uses than merely preventing syntax errors. I also use it for case-driven development. Often I'll write a routine with this sort of inner dialogue: OK, there are only two cases here. Let me write an "if" for that. Now I'm not quite sure what to do in case 2, so let me focus on the easier case 1. Now here I need to do a three-way comparison of these two strings. OK, the less-than and greater-than cases are easy -- I'll go ahead and do those. The equals case is a little harder. Tell ya what, I'll get to that one later. Meantime, let me go back and address the top-level case 2, because I think I have a bead on that one now.
That sort of thing. And of course, as I go, I develop a test input for each case I've developed.
Also, in those postponed cases, I like to insert a "die" or "abort". That way when I develop a new test input for it, I'll know I'm hitting it because the program will die. Then I can punch into that case and make it handle my new test scenario. I know when I'm done because the code doesn't say "die" anymore -- except when I really do want to assert the impossibility of a certain condition.
The author may unconsciously agree with you: "You know, the rare occasions where everything works on first go and you are pretty sure you made a mistake." [so goes the first line of this blog] Writing blogs without mistakes is hard too...
Comments
I instinctively distrust code that works first time. I advocate error-driven development.
That's basically synonymous to generic test driven development, unless you have some magical way of finding errors in code without running some sort of test on it? (Which includes tests like static analysis, valgrind, etc.)
The author's common mistakes scare me for being common. Not that I consider myself a great coder, but come on...
On a personal note, code I write in C++ (especially C++, which I've done a lot of at school) and frequently code I write in Java (which I do a lot of in my day-job) rarely 'works' the first time (though 'work' in this sense is more 'compiles'; runtime is usually pretty good except in C++ with its segfaults that require whipping out gdb and hoping it's not a template error). On the other hand, if I'm using a language I more naturally think in like Python, it's rare that stuff doesn't Just Work at runtime. And when it doesn't work, it's usually because of something I hadn't thought of in the design (and wouldn't even be in any hypothetical pseudo-code written beforehand), and easy to fix. Ahh Python...
That reminds me of an old adage from a former colleague back at H.P. He said start with the null program, and debug it until it does what you want. :)
I do concur with the author's point (3), where he recommends starting with the high-level syntactic forms and fill them out from the top down.
That has more uses than merely preventing syntax errors. I also use it for case-driven development. Often I'll write a routine with this sort of inner dialogue: OK, there are only two cases here. Let me write an "if" for that. Now I'm not quite sure what to do in case 2, so let me focus on the easier case 1. Now here I need to do a three-way comparison of these two strings. OK, the less-than and greater-than cases are easy -- I'll go ahead and do those. The equals case is a little harder. Tell ya what, I'll get to that one later. Meantime, let me go back and address the top-level case 2, because I think I have a bead on that one now.
That sort of thing. And of course, as I go, I develop a test input for each case I've developed.
Also, in those postponed cases, I like to insert a "die" or "abort". That way when I develop a new test input for it, I'll know I'm hitting it because the program will die. Then I can punch into that case and make it handle my new test scenario. I know when I'm done because the code doesn't say "die" anymore -- except when I really do want to assert the impossibility of a certain condition.
The author may unconsciously agree with you: "You know, the rare occasions where everything works on first go and you are pretty sure you made a mistake." [so goes the first line of this blog] Writing blogs without mistakes is hard too...