5 Programming Rules You Should Already Know
Posted by Fibonacci on August 9, 2008
It never hurts to remind you these small recipes aimed at programming novices:
1. Keep it simple. As in everything in life there are many ways to solve the same problem, but not like in life, in programming it is better to choose the simplest solution. The benefits of that are: code maintainability, easy to explain to others, easy to understand what you did with your code months ago.
2. Use design patterns. Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.
3. Comments. If in order to understand one’s code is has to be as green as Hulk, he probably didn’t follow the first tip. In many cases more self explanatory variables will do the trick and keep the code on a readable level. There are times when comments serve a purpose though. Algorithms can be hard to grasp and yet impossible to simplify through further abstractions. In such cases, you can explain yourself with comments. The rule of thumb for a good comment – it has to be an answer to “Why?” rather than “What?”.
4. High cohesion and Low coupling. Assign responsibility so that coupling remains low and cohesion high. Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. An element with low (or weak) coupling is not dependent on too many other elements. Cohesion is a measure of how strictly related and focused the responsibilities of an element are. An element with highly related responsibilities and which does not do a tremendous amount of work has high cohesion.
5. Don’t write deeply nested code. Nested code is code containing case/if/receive statements within other case/if/receive statements. It is bad programming style to write deeply nested code – the code has a tendency to drift across the page to the right and soon becomes unreadable. Try to limit most of your code to a maximum of two levels of indentation. This can be achieved by dividing the code into shorter functions.
I would like to hear from you about your experience and other tips.

![Read Linux news feeds [DIGG, LXer, Linux.com, Latest Soft] from within a single gadget, using tabs. See “Linux News” on your Google homepage](http://bergere.googlepages.com/linNews8.png)
Salon1 said
Good post. From a Systems Engineering perspective, comments are often underratted and essential. I like the “why” emphasis you suggested. However, I believe a goal a programmer should always be striving for is to write their code such that comments are not neccessary (e.g., self-explanatory variable names, etc.). Another pet peave I have related to point 1 is programmers that try to see how much functionality they can put in a single line or statement as a demonstration of their ability. This also makes it hard to debug and very hard to modify. I would rather see a single simple straight forward execution per line.
Michael Tim said
I love your site!
_____________________
Experiencing a slow PC recently? Fix it now!
5 programming rules @ Adrian Nițescu said
[...] found on a website 5 programming rules, which I share with [...]