Programming Best Practices
* Nguồn: Thomas Hintz
Theo Thomas Hintz | 04 Jun 2010
Less Code Is Better
The less code that you write, the less that you have to read, the less that you have to maintain, and usually the program will be simpler, and will often run faster.
It finally compiles! You just finished that big hairy part of the project, and it seems to work! Yeah, there are a few messy areas and some parts are a little hazy, but you got it done!
…you just found a bug. It won’t be too bad to fix, just go in and add another if-statement to detect for the special case, and you’re good to go!
If it’s broken, don’t fix it. Rewrite it.
95% of the time you are better off rewriting all of the code. That little if-statement that you are adding, to fix an innocuous bug, may seem harmless, but it should be signalling disaster to you. It most likely means that your abstraction wasn’t quite correct. So now you are making it a little bit harder to read. You are adding a little bit more code. It only takes a few minutes, and rewriting it would take hours or even days.
In the long run, you would’ve been much better off not fixing it, but rewriting it. Now that you have found a few more bugs, and added a few more patches, and it’s been a few months, the code is getting hairy. Now you are having a hard time being sure that the new code isn’t making more bugs. And it’s taking longer and longer to work with the program.
If you would’ve just rewritten it to be correct, all these times, then you would have great code, solid abstractions, you would know the code inside and out, it would be readable and maintainable. After rewriting it a few times, the code just flows as well. It no longer takes as long to write it as it first did.
Sure, sometimes you end up dumping the project or you didn’t end up making things that much worse, by not rewriting it, but it’s near impossible to guess when the 5% will be. Don’t play that game. Just rewrite it.
Code Is For People To Read
Only as a side-effect is it for computers to run. The easier your code is to read, the better understanding you will have of it. You will have less bugs. It will be more maintainable.
Sure, coding super fast, inline assembly makes you feel macho, but being macho doesn’t help when CPU architecture changes, and you have to go back in, and decipher the mess you made.
Do it the right way. If you don’t have enough time to do things right, then don’t do them.
It almost always costs more in the long run, to do things less than correctly. Most often the reason for incorrect code, is trying to do too much in too little time. This is the beginning of feature creep. You are entering the world of hazy abstractions.
Do yourself a favor, stop coding.
Stop Designing, Start Coding
Instead of spending all of your time on the whiteboard, drawing up elaborate plans, start writing code. Yes, your code is going to suck. It is going to be a mess. But what’s the rule when our code is a mess?
Your program will always be better off if you spend a day writing it 6 times, rather than designing it 6 times and writing it once. Writing code, and forcing yourself to rewrite it if it is incorrect, forces you to figure out the abstractions, and allows you to do deal with the real problems, instead of guessing what they will be.
You aren’t building a car. You can forget to hook up the brakes and still live.
* Nguồn: Thomas Hintz