I can’t scientifically say what makes code “good”, but my gut has a few things to say about it:
- good code reflects the problem it solves
- good code can be easily understood by programmers without experience in your language
- good code is generally short
- good code doesn’t require much thinking to understand
- good code has very little coupling
- good code is cohesive - definitions of functions and types required are not scattered throughout the software
- good code documents any requirements for proper usage
- good code makes just as much sense to you one year from now, as it does now
All of these properties I feel could be summed up simply as: “good code is reusable”, and taken a step further: “really good code is so simple it can be reused by a trained seal.”.
What do you feel are other properties of good code?
Re:
#2 is a slippery slope. The evolutionary end result of that road is VB code written for managers to understand. Instead of “understand”, I would say “follow”.
I often peek at code written in languages I don’t know (very well) in order to find out how it behaves in a certain circumstance. When code is good, I can trace progress and follow the logic without understanding all the minutiae.
But I’d rather not advise well-versed programmers to stay away from the powerful constructs of their language, even if they might be opaque to a novice. Expressive constructs do not obscure or obfuscate good code; they clarify it.
Good code is generally sparse, punctuated with short stretches of terseness where the heavy lifting happens.
Which leads me to:
Good code is generally plain and does not work very hard. Good code is built around well-designed (and well-documented) data structures that lend themselves to a natural solution of the problem.
Re:
> Good code is built around well-designed (and well-documented) data structures that lend themselves to a natural solution of the problem.
That is an excellent point! Too often people don't use appropriate data structures which reflect the problem domain.
good code has separation of concerns
Not sure if this point is necessarily implied by your others or not. Good code is made up of discrete parts--functions,procedures,modules,objects,whatever-- that each do roughly one simple thing. If one part is still too complex, subdivide it further. Not only does this divide a program into manageable sections, but it makes reuse easy even for...er, seals.