Functionality & Meaning, or Engineering & (Score 1)

I agree with the author of the article, there are two levels in source code. On the one hand there is the formal side, the syntax level, if you will, which can be quite simply checked by tools. As programming language standards leave certain things undefined just because of the infinite amount of combinations in a language, so do compilers and linkers also. Static analysis tools, like lint, are much more nitpicking and try to uncover probable programmer mistakes for example through uncommon usage of certain structures.

But there is also the higher semantic level present in the source code. How well does the source code express its intent and how well is it structured. That is only directly visible internally, but does most likely have larger than generally understood indirect effects externally. The problem with software engineers is that they listen much too much to what the customers, testers and managers have to say. And all of them focus only on functionality. Most engineers also like to see something working and sometimes they do anything to get something working. Clarity and meaning in the source code are secondary concerns.

The results are clearly visible.

Software systems are working, kind of, but they cannot be changed too readily. Software isn't soft at all, because its internal clarity, maintainability is compromised. Using only simple names for variables (tmp, i, cnt, ret_val, status) makes code not readable, as an example. How much bad naming hurts the understandability of a piece of code is not known but is probably underestimated.

There are certainly rules that could be used to limit the chaos in source code without limiting the necessary creativity. There are issues that 1) are Missing from the source code, 2) Extraneous, 3) make Risky assumptions, or 4) cause Chaos. Some examples:
1) Magic (hard-coded) numbers
2) Comments that repeat what the code clearly says
3) Not checking a pointer for NULL before dereferencing it
4) Nesting too deeply

The funny thing is that such things can be easily checked manually, locally within functions, on paper and massive amounts of findings can be made in almost any programming language. Ticking code (or marking rule violations) shows that almost all software developers are neglecting maintainability in their code. Tick-the-Code is one way of triggering refactoring, and improving the design of existing source code. For more information, check out www.tick-the-code.com.