The following is Rod Johnson’s definition of good code. This is just the initial pages of Rod’s great book “J2EE Design and Development”. These are the simple guidelines that obviously have led him to develop Spring.
What is good code? These are a few of its characteristics:
- Good code is extensible without drastic modification. It’s easy to add features without tearing it apart.
- Good code is easy to read and maintain.
- Good code is well documented.
- Good code makes it hard to write bad code around it. For example, objects expose clean, easy-to-use interfaces that promote good use. Both good code and bad code breed.
- Good code is easy to test.
- Good code is easy to debug. Remember that even if a piece of code works perfectly, it’s still a problem if it doesn’t favor debugging. What if a developer is trying to track down an error in imperfect code, and the stack trace disappears into perfect but obscure code?
- Good code contains no code duplication.
- Good code gets reused.
I think there is an interrelationship between above facts. They support together. For instance: Good code is always documented. A documented code is more easy to read and more maintainable. A readable documented code can be reused easier.
By another view, good code is easy to test. An easy to test code let you add new features without tearing it apart.
Developing a good code is not as difficult as maintaining and extending a bad one. Spring learning curve is the cost that companies pay to develop good code. However there are some tasks that should be done by each developer. Developing good code needs to be adhere to the basic rules. It needs to be fanatic about quality and keeping simplicity. Indeed, good code takes more energy to develop. Developing good saves time and money at last.