4 Lazy Ways To Stop Yourself Being Lazy
Here are four tricks I use to try and encourage myself to write the correct code at the right time. - Use the Compiler to catch work that isn't done yet.
- Before writing a method, write the code that calls that method.
- That way, when I try to compile, errors will be reported for any methods that aren't yet written.
- Write a 'TODO:' comment.
- That way I can still compile but can track down the items that aren't done yet.
- Write a Unit Test that catches each problem as it is foreseen.
- That way while my code might compile, nUnit will tell me that the full story is a little more complex.
- Use Debug.Assert statements to hard-code your assumptions. Helps you find when your assumptions are wrong.
You can bounce from any one of these methods to any other. The order can go something like this: - First write 'pseudo code' with each line labelled as 'TODO:'
- Convert the pseudo code into calls to fictional methods/properties. (Methods/properties that aren't written yet).
- Next, write the outline of these methods, but populate them with TODO's.
- Maybe now (or sooner) write unit tests to test the empty methods.
- As the tests are run, add some todo's or even some code to the methods.
- ...Continue compiling, writing, testing, planning -- all together.
The advantage of this kind of approach can be that it helps you capture your thoughts (getting-things-done style) before you get too bogged down in the implementation detail. And it does it in a way that leans on the tools available, to ease the burden on your memory. Sooner or later you do of course have to write the actual code -- but using these tricks to scope out, design and view from a high level, can help you cut down and re-use code, long before you've spent time writing it.
'Mischa Kroon' on Sun, 02 Jul 2006 14:12:53 GMT, sez: Wasn't this TODO driven progamming :P
'Rik Hemsley' on Sun, 02 Jul 2006 18:55:29 GMT, sez: I find this better than calling missing code (can't compile) or writing TODO in methods (can compile but code is broken):
Where you haven't done something yet, throw a NotImplementedException (or equivalent).
Assuming you write your tests first, this will mean your code compiles but your tests fail - which, I think, is most useful. You can use the build but you wouldn't think about releasing it or checking in.
'lb' on Sun, 02 Jul 2006 20:49:12 GMT, sez: >Wasn't this TODO driven progamming
yeh, it's just got two new tool-assisted-features: asserts and unit tests.
i don't mind throwing 'NotImplementedException', but if you've already written your unit tests, is there still a need to throw the exception? the test should fail as is... this is about laziness so adding those throws looks like extra work...
i *do* like visual studio's habit of throwing 'NotImplementedException's inside methods it creates for you, but that's an automated thing, and suits laziness well...
And how about the SapphireInSteel hey?
cheers
lb
'Michael Leung' on Tue, 04 Jul 2006 03:03:21 GMT, sez: Hey Leon,
I haven't commented on here in a dog's age. This seems like a pretty solid way to approach development. I think I'll give it a shot perchance as I'm still not fully drinking the TDD kool-aid. I write tests, but usually after the fact. :)
Oh, and ShappireInSteel?
What about good old (well new) RIDE-ME?
'lb' on Tue, 04 Jul 2006 03:26:40 GMT, sez: Good to see ya back again!
thanks for adding the link to "RIDE-ME" in your name. If i was gonna google that name, i have a vague suspicion that a lot of the result wouldn't be safe for work ;-)
Project ride-me looks groovy!
'Michael Leung' on Tue, 04 Jul 2006 04:42:28 GMT, sez: Thanks buddy! :)
I took about a three or so month hiatus to write RIDE-ME and do some Rails work, but I'm coming back in a big way!
Oh, and results to the RIDE-ME search are definitely not conducive to work browsing. ;)
|
secretGeek .:dot Nuts about dot Net:.
Just Wally
Complete secretGeek Archives
The Best Software Writing I
The Business Of Software (Eric Sink)
