A frustrating couple days of coding has crystalized a new rule for me:
If you can’t demonstrate your new feature in three lines of code, you’re not done.
But it works from the client UI? Great. And it’s fully tested? Super! But you’re still not done.
If it took twenty lines of setup code to make the unit tests work, you’re not done. There should be a close to one-to-one correspondence between artifacts in the UI and artifacts in your codebase. Did you add a new command? There should be a single methodthat encapsulates that command. Did you add a new form? There should be a single classwhich can be instantiated in a valid state with a single constructor or factory call.
I’m not saying this just for the sake of style. This is for your own good. It’s so that six months from now, you can look at that feature on the screen and track it to a single point in the code. It’s so that when you’re training the new guy, you can open up a console and type three lines to demonstrate how that feature works. It’s so that when you write a conference presentation on your brilliant code, you can fit the examples on one slide.
Don’t just be a domain expert; be an API designer. A humane one. The brain you may save from imploding is your own.
I don’t have time to go into technical details, but the Facade pattern is your friend.
and those three lines should be
create it
start it
stop it
No destroy or reallocate?
Or:
Create it
Act on it
Show the result of the action.
“I don’t have time to go into technical details, but the Facade pattern is your friend.”
When there is time, can the technical details be spelled out? I can sort of guess at the end result, but I fear I'll miss the true magic of what you're getting at.
Sure, I'll put it on my list of posts to write.
I have a similar rule…
You should be able to explain any given function in your code to your own grandmother. If you can't, then you're not done.
The essence of programming is to be able to break down complex problems into simple sub-problems.
If you don't aquire that skill, you will not be a good programmer. Imo.
I wouldn't like to explain bind (>>=) to my grandmother. Does that make it a bad function?
“When one function loves another function very much…”
how true. Nice tip. Thanks.
Glad you liked it 🙂
Hmm, anything more than two lines is overkill.
The rule is modified for Perl programmers to “13 characters or less”.
I have a similar rule…
You should be able to explain any given function in your code to your own grandmother. If you can't, then you're not done.
The essence of programming is to be able to break down complex problems into simple sub-problems.
If you don't aquire that skill, you will not be a good programmer. Imo.
how true. Nice tip. Thanks.
No destroy or reallocate?
I wouldn't like to explain bind (>>=) to my grandmother. Does that make it a bad function?
“When one function loves another function very much…”
Or:
Create it
Act on it
Show the result of the action.
Glad you liked it 🙂
Sure, I'll put it on my list of posts to write.
Hmm, anything more than two lines is overkill.
The rule is modified for Perl programmers to “13 characters or less”.