The words or the language, as they are written or spoken, do not seem to play any role in my mechanism of thought. The psychical entities which seem to serve as elements in thought are certain signs and more or less clear images which can be 'voluntarily' reproduced and combined. .... This combinatory play seems to be the essential feature in productive thought before there is any connection with logical construction in words or other kinds of signs which can be communicated to others. (Albert Einstein in a letter to Jacques Hadamard)
Jean Labrosse, the well-respected author of the µC/OS-II RTOS, recently published an article in Embedded Systems Design entitled Adopting C programming conventions. If you've read the article, you can easily understand the stir it might create. Some of the ideas he advocates are not generally accepted as "good practice" among most embedded developers. It is no surprise that the comment section that follows the article is full of gripes and is largely devoid of praise.
Ironically, the source code for µC/OS-II is cited by many as a prime example of beautiful, clean embedded C code, worthy of study. The RTOS itself is considered to be highly reliable. True to form, the coding style throughout conforms to Mr. Labrosse's conventions. Quite a paradox.
My first response was to conclude that maybe Mr. Labrosse is just smarter than all the rest of us, and it wouldn't matter if his coding style were in complete opposition to what most consider "good practice." He'd figure out how to bring order to the system and ship something exceptional. That may, in fact, be true. But then I remembered the above from Einstein, and it completely changed my line of thought toward something more productive.
Source code is such a crude description of the intricate mental models that reside in our heads when crafting software systems. The process of first distilling a mental model to code is so much smoother than the process of recreating a mental model from reading source code. Unfortunately, most of us lead lives that prevent us from maintaining that system model in our heads indefinitely. We're constantly required to rebuild the model after being away from the problem for a while. As I look closer at Mr. Labrosse's conventions, I see a set of rules that allow him to create a richer reading experience for himself, each construct seeded with clues about how it fits into the larger system, assisting him to reconstruct the "clear images" in his mind each time he returns to the code. That sounds like "good practice" to me.