James's Weblog

Recently in a programming forum I frequent, someone posted some sample code he had written and asked for a critique. He would be providing this code to prospective employers.

If you’re trying to get a job programming, providing sample code is good. However, it’s a little surprising what some people consider to be good sample code.

Your goal should be not only to demonstrate that you can write code, but that you can write maintainable code. Write-once, read-never code is worse than useless; it’s fragile and wastes the time of anyone else who ever tries to modify it.

Quick and easy things you can do to improve your code samples:

• Make your code readable. More whitespace is better than less. More braces are better than fewer. People judge books by covers; make your code look good.
• Document your code. Document your functions’ contracts; what are their inputs? what are their outputs?
• Use defensive programming techniques. Aggressively use assertions to check that inputs are valid. Enforce functions’ contracts.
• Handle errors. (Okay, this one is neither quick nor easy.) In my opinion, handling errors well is probably one of the hardest things about programming. It complicates resource management, it makes code ugly, it’s tedious, no one wants to do it, but it has to be done. If you’re going to submit sample code, take the time to handle errors. Use SESE patterns in C and RAII patterns in C++. At the very least, use comments to acknowledge where you ignore errors.

(Of course, only do the above if you also intend to continue doing them in practice. Misrepresenting yourself is dishonest, okay?)