programmers.at/ blogging/ posts/ CodingStandardsAreMisleading

Coding Standards Are Misleading

The functional aspect of software is almost always disregarded in coding standards. At best, they focus on technical aspects, but most of them focus primarily on syntax. They explain how source code should be formatted to be readable. It has been proven that maintainability is important. However, consistent and clear syntax gives a fake illusion of clean and understandable code.

Syntax is just an arbitrary representation of software. In a sophisticated environment, you could redefine the syntax of the language easily. E.g. changing the characters for blocks from [] to {} would be one command (two commands if there would be conflicts). Complex redifinitions would be possible, too, as well as displaying and modifying the same code in a graphical way (21st century, anyone?).

We have to think of the source code that we write as just one of several ways to design software. Software does not need to be directly bound to what we write. Software is rather a form of byte code -- semantically correct and independent from any representation. If we think of software as being objects and message sends that exist beyond textual (or any other) source, we have laid the foundation for a language that can evolve and adapt its representation to various display formats or users.

But what does this mean for coding standards?

Well, if the code you write does not have a syntax but will be displayed using the syntax rules of the one viewing it, most (parts of) coding standards have lost their right to exist.

However, software engineering has standards.

Few coding standards imply or mention that programmers will or should also regard the source-level design. But that topic is far too large to be discussed in a coding standard and could fill several books. And, in fact, it already has: There are, for example, works on design principles and smells[1], design patterns[2], refactoring[3][4] and code smell[5][6]. Developers should also be able to chose the right data structures and algorithms for the task at hand -- an issue that fills a lot of other books[7][8][9].

Yet, the most important point has not been mentioned: The reason why we write software. Usually, we program (directly or indirectly) for some kind of customer, even if it's only ourself. Coding standards do in no way specify any goals of or approaches to interaction design, usability engineering or how one might call it. There are, again, various books but since I don't know whether they're worth it, I'll spare you.

Coding standards seem to favor syntax over technical aspects over functionality. A sure way to create conceptually and technically broken software.

References

  1. Martin 2003: Agile Software Development. Principles, Patterns, Practices.
  2. The Gang of Four 1994: Design Patterns: Elements of Reusable Object-Oriented Software
  3. Fowler & Beck 1999: Refactoring. Improving the design of existing code.
  4. Kerievsky 2004: Refactoring to Patterns.
  5. Fowler & Beck 1999: Refactoring. Improving the design of existing code.
  6. Mäntylä 2003: Bad Smells in Software -- a Taxonomy and an Empirical Study
  7. Knuth 1968
  8. Knuth 1969
  9. Knuth 1973