Coding for Humans

For this class I'm in I have to read Smalltalk Best Practice Patterns by Kent Beck.  He has an interesting quote in the first chapter.  He says, "[W]hen you program, you have to think about how someone will read your code, not just how a computer will interpret it."  He's right.  The biggest thing I see in new programmers (either new graduates or newly self-taught coders) is that they don't understand maintenance.  In school you never have to revisit a program after you hand it in.  In writing your own code, you don't often revisit it a long time later and you rarely change someone else's code.  In industry, there's a lot of work on old code.  For instance, we have a test shell that began life as a 16-bit application.  The code originally ran on Win 3.1.  That's old.  It has undergone a lot of changes since then and is now Unicode-clean, 64-bit clean, and fully object oriented.  However, some of the old code still survives.  The initial code I wrote to test DVD playback 8 years ago is still used daily.  If this code were written without thought to the next person, it would have been replaced with code that was.  It takes too long to read opaque code.  It's too easy to make mistakes when maintaining it.

Always write your code in the most direct manner possible.  If you can save a few processor cycles but will make the code harder to read, stop.  Write the obvious code until/unless a profiler tells you that code path needs to be optimized.  Even then, comment the code well.  Especially then, comment the code well.  The worst thing is to run into optimized code without comments.  It's sometimes not even worth trying to understand.