Qualities of Good Code
By Daniel Taylor on May 28, 2011 20:14
Although knowing how to program is obviously the most important quality of being a comptuer scientist, code architecture follows closely behind. The quality of underlying code will have a great impact on the reliability, scalability, security, extensibility, and maintainability of your program. Basically, without good code architecture, you will run into many problems down the road.
Although knowing how to program is the most important quality of being a computer scientist, code architecture follows closely behind. The quality of the underlying code will have a great impact on the reliability, scalability, security, extensibility, and maintainability of your program. Basically, without good code architecture, you will run into many problems down the road.
Sometimes code is not removed, just commented out. Maybe there are variables that have been left in the code, but are not used at all. There might be closely coupled code or a cyclical class structure. All of this leads to cryptic code that cannot be extended easily making it nearly impossible to come back to in the future to maintain.
This type of code is known as "code bloat," code that is unnecessarily long, slow, or otherwise wasteful of resources. This problem can be solved by refactoring your code or possibly even redesigning your program entirely.
You can find out ways to make your code more efficient by reading this book on refactoring. But for now, let's take a look at some ways to see if your code architecture is well thought out or if it could be improved:
Rip It Apart
Can I rip out large sections of code and move it somewhere else without breaking anything? I have never gotten into doing all of those flow charts, pseudo code and other precoding stuff. I just like to jump right in and get things working. After the framework for every feature is completed, I ask myself where each feature belongs and move it to the correct location. I should be able to move features around easily, taking only a few minutes to fix a few references.
Building scalable code doesn't always mean being able to pile more on. Anyone can pile crap on top of crap. All you end up with is a load of crap that is impossible to maintain. This is known as spaghetti code. Scalability involves not only increasing the size of the code, but also simplifying the code. You have to be able to scale your code up and down if you want to be able to maintain it.
Pick Up Where I Left Off
Am I able to come back to the code after a few months of working on another project? Or do I have to spend a few days recalling how everything works. I almost never document my code unless it is a library class that is going to be used by others. A comment here and there should do the job. Make sure you name your methods properly and give your variables useful names. The most important thing to remember is code should comment itself. You shouldn't have to place comments on every other line. But I am not opposed to writing a big comment block above a section of code describing an in-depth algorithm.
These are my top three most important characteristics that contribute to good code architecture.