Huge products and clean codes

I have worked with a product which contains over two million lines of code and it has been built since 2001 without any major rewrites. To get there, code needs to be well structured and logical. Working with huge product like this has taught me many things. One of the most important lesson has been that code needs to be very easy to maintain and understand. I wrote up some instructions on how to work with large projects.

How to write understandable code?

In code we cannot show pictures or talk about how our code is structured. Only way to communicate with other coders is the code itself. Because code is the only way, we need to structure it so that it tells the reader what we want reader to know.


I think naming is one of the most important part of programming. With bad naming you can ruin the whole software, or with good naming you can achieve huge readability benefits. Good naming isn't that hard even.

Rules to good naming:
- Describe all what needs to be known into a name. Name can be a long or short, as long it tells reader what for the named object is used for.
- Don't use similar names inside a same code closure. Names which are too close each other can be distractive
- If you don't know how to name your code objects, they might have too many responsible (see SPR)

Here are some examples of bad names
1) a  - dont use short and undescribing names
2) data - everything is data!
3) a2 - dont use numbers unless its necessary (like calling a second comn port COMPORT2)
4) And Or - if your name contains and or or, your code object might have two or more responsible.


Patterns are interesting thing. They are "well known" structures which help programmers to understand how things works. In this vast product we use patterns, but we do not so much as you might think. Patterns are used in critical parts of program, but there are also own "pattern" like structures which are copied across the program. These pattern like structures are very helpful for new developers. For example we are using active record pattern in business classes.

Use pattern to setup a basic structure for a program. If everything is built with different kind of patterns and practices, program won't have a unified feeling.

Common language

Common language is very important in huge projects. It helps to keep in tracks when jumping between classes and methods. It is also very useful when you want to find the point where a certain process begins, or locations where the business case is changed or used. You cannot change words into synonyms between classes or methods. Consistency is everything.

For example if you are using word "invoice" in a class name, don't use word "bill" in next. If term is wrong in first class, change it to everywhere.

Pattern picture taken from


Post a Comment