Good program code first and foremost just “works” as expected, does the job for which it was designed, and provides trouble free operation in a timely fashion. Working, however, is only one component of good program code. There are certainly many other aspects to good program code which must be considered, but how does one evaluate program code to say “…this is good code”.? “Good” program code is an especially elusive label, based upon criteria that is as individual as each programmer. (Now that’s a scary thought – I’m glad Halloween is over!)
In today’s programming world I believe that the toolset used by the programmer to create the code plays an important part in the creation of good program code. I would suggest that the toolset used should create clear and easy to follow code. In addition to that, the ability to produce an application in a basically modular fashion is important – providing both time savings (reusable code) and an ability to test individual components (modularity).
I have known programmers who were obsessed with creating code that was highly optimized — struggling with 20 lines of code that works, to use complex methods to get the code down to 5 lines. The result was code made much more difficult to understand (when looking at it 6 months or 6 years later), as well as code which when executed gave no tangible value to the end product program itself. Why bother? Optimization is good — but at what cost?