Recently I had an opportunity to watch a talk from Mark Shuttleworth at Linux Tag 2010. The subject of open-source was naturally approached together with discussions about Ubuntu. Since I am not that involved with Linux I could not follow all the details. Anyway, I thought it was particularly interesting when the topic of source-code quality was touched.
I really liked what was said with regards to code review. It is relatively common when programmers outside to the project or simply less experienced have their code reviewed by the core people. What could not be perceptive at the first sight is that this practice can also be extremely useful in the reverse way. Thus, learning becomes much more motivating since the new programmer is directly exposed to what is considered a model of good code quality within a given context.
Surely this is a practice already used in several teams in many projects. But maybe not as much as it could be. So if your team have not used it yet it might be worth to consider this item for the forthcoming discussion on improvements in the development process.
Continuing on the subject, I also began to reflect whether there is any widely accepted definition and especially adopted in practice of what is source-code of good quality. I think that in most professional environments that point is considered important at least in theory. But how does that reflect in practice? Also, does the meritocratic system applied (intentionally or not) on the involved engineers consider this factor in a fair manner?
I venture to say that a lot of software engineers have gone through a situation in which they were blamed for having delayed the development of certain software. Yes, estimates are not easy to make. Still, one of the reasons that may cause them to fail is when they are based on a simplistic and purely comparative basis of a component or library written by a particular programmer within a particular time frame. Eventually such programmer might even end up being taken as an example because she performs her tasks quickly and “efficiently.”
The problem in this kind of situation is that the mere fact that someone managed to write some code in some time means next to nothing if issues related to the quality of the code are not evaluated. Besides the obvious factors which are that the software meets the desired requirements and contain few (perhaps zero) bugs, the list below summarizes my main expectations of a good code.
- First, the code should be highly intelligible and clean. Understanding a program is easy for any computer, but not always for a human being.
- There should be good code reuse. Snippets which are very similar, long functions, abuses of inheritance, overloaded classes, among others, are not good indicators.
- Not too complex changes which are not trivial either should be easily supported by a flexible basis.
- Extension points should be provided. Ideally as generically as possible.
- The features of the programming language in question must be properly used. Both the knowledge of the definition and structure of the language, as well as the API, should be visible.
- Unit tests for the main components. Depending on the case even broader tests.
- The code should have a single ‘face’, since programming techniques/coding style to architectural patterns. This promotes the conceptual integrity of the code.
It may be that the above are not news to anyone. However, one could take a wild guess saying that in most projects they are not taken into account from a deep perspective. This may be due to a lack of vision (of the importance of the issue) or even due to the lack of expertise and technical knowledge to conduct a detailed and precise analysis.
Moreover, there is a complicating factor: time. Not always you can reach a definitive conclusion regarding the quality of a code if you do not go through moments when it is necessary to deal with extensions or any kind of maintenance (including, of course, bug fixes). In such cases the ease or difficulties encountered in real tasks can contribute significantly to a final verdict. And for that to happen the software needs to have gone through relevant stages of its life cycle. There is no substitute for time.
I have seen many initiatives aiming to improve quality of a product with focus on management or procedural models. Although they do help (how much depends on the case I guess), they do not always act directly on the essence of the problem (actually, the solution) which is the quality of the source-code. To invest in the quality of a product it is fundamental to invest, among other things, in the quality of the code. Therefore, have good code reviewers who really understands programming principles (such as algorithms and data structures), who are very familiar with the programming languages and technologies involved, which are aware of well known design and architectural practices, and who like to study.
Leandro Melo
