(Difference between revisions)
|(7 intermediate revisions not shown.)|
When learning to program, the function of a piece of code is the most important thing to get right
after the syntax of the programming language is mastered. Many non-professionals are easily satisfied with code that ( somehow) works. Do not stop there. |+|
When learning to program, the function of a piece of code is the most important thing to get rightthe of . with that () not .
| || |
|-|This early satisfaction with function can be bad. Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Good and bad structure exist at many levels: the amount and order of statements in a loop or conditional; the nesting of such control structures; the statements within a function; the functions within a module or class; the relationship between one piece of code to another; the partitioning and dependencies between subsystems. |+|
| || |
|-|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 professionals can easily understand. |+|
, your program code. code that can .
| || |
|-|There is a well-known cognitive capacity for short-term memory: seven plus or minus two items, meaning that it is easy to grasp between five to nine different things at once but not more. If you need to comprehend more things at once, you either need to concentrate very hard or , usually, your brain starts to group elements implicitly to keep some coherent picture of the whole. |+|
to . at , or of the .
| || |
|-|Try to keep your code organized and use this five-to -nine elements 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 there are not only explicit but often also implicit relationships. 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. |+|
to code and to to . principles as well. , be .
there are also .
and the . as it . .
your code to structure.
| || |
by [[Peter Sommerlad]]
by [[Peter Sommerlad]]
When learning to program, once you have mastered the syntax of the programming language, the function of a piece of code is the most important thing to get right. It feels great to pass the hurdle of getting a program to actually run and do what you intended. Unfortunately, that initial 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 and others will have to read, understand, use, and modify your program code. Changes to code are inevitable. You therefore need to ensure that your code can evolve while its functionality survives.
One of the most significant barriers to evolution is the code's 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 — its overall design and architecture.
Hindrance to change from poor structure comes in many different species. The simplest taxonomy of code structure is in terms of high cohesion (i.e., the Single Responsibility Principle) and low coupling. Both are easy to measure and understand, and yet very hard to achieve. Violation of these principles is contagious, so without an antidote, code that depends on other, poorly structured code tends to degenerate as well. Take low cohesion and high coupling, or other metrics showing structural disorder, as symptoms to be diagnosed and remedied.
Refactoring is the treatment to improve code structure. Automated refactoring, test automation, and version control provide safety, so that treatment does no harm or can be easily undone.
While the need to refactor is almost inevitable — because we learn about better solutions while we program — there are also preventive measures that make refactoring less expensive and burdensome.
Where poor structure can occur at all levels, good structure builds from the ground up. Keep your program code clean and understandable from the statement level to the coarsest partitioning. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve. A user might not initially recognize bad structure, so long as functionality is available. However, evolving the system might not happen at the pace the user expects or desires once structural decay in the code sets in.
Keep your code well organized. Program deliberately. Refactor mercilessly towards DRY code. Use patterns and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture towards doing more with less code. Avoid too much up-front genericity and refactor away from laborious specific solutions repeating code.
As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system is to grow beyond the scale of "Hello, World!"
by Peter Sommerlad
This work is licensed under a
Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page