I think it is important to understand for whom you are writing the source code. Once upon a distant time, I was a manager. For a few short years before that I was a “team leader” (with a different company). Some of those who worked with me may remember my asking the question “Who are you writing the code for?” (I was less grammatically correct in those days.)
If this was the first time he/she heard the question, they usually would give a confused look and respond with “The compiler?” After listening to my carefully expressed thoughts (i.e. my rant), no one gave that response a second time.
Yes, the code is written for the compiler, but you don’t write the code just for the compiler. The written code — the source code — is the most important piece of firmware documentation. Thus, the code is written also for the reviewers. In spite of all the computerized tools, a line-by-line design review is still one of the best methods to uncover mistakes in the code.
As a project manager, I have used the source code to match with a checklist of product features as part of a schedule review. If formalized Unit Testing is performed, both the quality assurance designer and the auditor use the code structure to determine the nature and extent of the required firmware testing.
Of course, we should never forget one more important person for whom the code is written — the next programmer. She/he is the one that will add that new important feature.
So the code is written for the compiler …and the code reviewers, the project manager, software quality assurance, the testing auditor and the next programmer. With all these people involved, isn’t it worth an extra effort to make the source code easy to read. I mean a real extra effort.
Especially, if six months later, you are the “next” programmer.
“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.”
— C.A.R. Hoare