Lists

It’s as simple as 1, 2, 3…

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.

3 Responses to “5 Programming Rules You Should Already Know”

  1. 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.

  2. I love your site!

    _____________________
    Experiencing a slow PC recently? Fix it now!

  3. [...] found on a website 5 programming rules, which I share with [...]

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>