Structure over Function
When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. It feels great to pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.
So what is missing?
You or others will have to read, understand, use and modify your program code. Evolution and change of code is inevitable. Thus, you need to ensure that your code can evolve while its functionality survives.
Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems.
One of the most dominant barriers to evolution is the code's structure. Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote code using badly structured code tends to get degenerate structure as well.
Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it.
Keep your code well organized. Refactor mercilessly, if it needs improvement. Use Patterns to guide your efforts to improve the code's structure. Understand and evolve a system's architecture.
and limit the number of elements or group them at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. After the size, the number of relationships should be minimized. Notice that relationships can be implicit as well as explicit. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page