My country‘s National elections are set for May 10th, a day we all expect to cast our vote for a much looked-forward-to new President. Lately, though, there have been whispers that the elections might have to be postponed due to problems with the brand spanking new Automated Election System (AES). Understandably, this is causing quite a panic here, and a popular Presidential candidate even threatened another People’s Power Revolution should he lose the election.
Yep, a revolution… because of bad code.
So what went wrong? Besides “defective” flash cards, there are problems with the source code of the AES, which include the following:
- Improperly terminated database transactions.
- Source codes are not properly commented. “The Ballot Production source code modules as submitted on 8 Feb 2010 did not have within themselves one single comment or internal documentation.”
- The software inventory provided by Smartmatic is inadequate. One software “contains a solicitation for beer” for the software’s creators, which brings into question the software credibility.
You can view the entire list here. Now, any programmer worth his salt knows that these are all very basic “problems”, easily avoided with clean, well-written code.
Number 3 on the list,
“contains a solicitation for beer” for the software’s creators
was a particular LOL moment for me, but more immediately obvious was that this is lazy coding.
I’ll admit that I’ve been guilty of writing lazy code in the past- which brings me to my post today. We may not be working on source code for an entire country’s National Elections, but as programmers we should always be striving to write the best code possible: clean, well-written, and as bulletproof as possible. This means no lazy code, whether you’re writing XHTML or PHP, and whether it’s for your Aunt Betsy or the Pentagon.
Tips for Writing Good Code
Comment.
You want to document your code well. See number 3 in the list above? I would be upset, too, if I was submitted code without a “single comment or internal documentation”. And it’s not just for others, it’s for yourself. For an excellent guide on commenting code, read these successful strategies for commenting code. At the same time, don’t comment self-explanatory code.
Write Meaningful Code.
My regular readers already know how I feel about this. Write code that makes sense, and try not to be too cryptic. For example, get_main_ingredient () instead of main_ing ().
Optimize Your Code Properly.
Lazy code is often bloated, a surefire sign that the coder didn’t optimize properly. Well-optimized code can make a huge difference in the performance of your application. At the same time, the keyword here is “Properly”- because there is the danger of over-optimization. Knowing what to leave in is just as important- maybe even more so- as knowing what to take out.
Check, Re-Check, then Check Again.
When you’ve written similar code over and over again, and a deadline is looming, it’s easy to “forget” to check your code. But there’s really no excuse not to. For web documents such as HTML and XHTML, for example, there’s the W3C Validator– and, my recent favorite, Ideone, which lets you compile and run code online in over 40 programming languages. Oh, how I love the Internet!
What are your tips for writing code?
