Last Friday (03FEB12) I had the first code review for a major new
feature I'm currently working on. The design and implementation of this
feature are my responsibility, and I'm the only one working on it, so I
feel a significant amount of pride, responsibility, and ownership. From
this overly-sensitive perspective, the review didn't go so well.
The application implements real-time signal processing algorithms
running on a cluster of machines configured as a grid. Its completely
written in ANSI C, despite the fact that one of the overarching design
requirements is that the top-level application have no platform-specific
code unless absolutely necessary. I don't agree with the language
choice, but the project has sensible reasons for this (the application
has a lot of legacy and only two engineers besides myself (out of a team
of 18) know C++, and since no one besides me really knows any other
languages). Where I start to butt heads, and get increasingly irritated,
is in the design choices.
I write object-oriented C as much as sensible, though I do sometimes
break encapsulation to make my new code fit cleanly into the legacy
portions. I try to break my code up into small, descriptive functions to
make it easy to tell what is going on where. I try to keep variable
declarations within the innermost scope they are required in. I make
heavy use of const, and initialize variables at declaration. None of
these are appreciated, and some aren't even tolerated.
Now, I don't want to give the impression that I whine about having to
follow coding standards. I don't. Standards are necessary, especially on
a large project, where stylistic issues come down to personal
preference. However, everything I mentioned above has valid, functional
purposes. Some are considered best practices, not only in C but most
other languages as well. Yet in my leads' ideal world, none of those
elements (except possibly const usage) would be present in the code.
In this most recent review, I got called on #3 and #4. They want to see
all the variables declared at the top of the function, and would prefer
them to be initialized at the beginning of the function itself. The
reasoning: maintainability. The whole reason for #3 and #4 in the first
place is maintainability (and, in a few cases, optimization). However,
the code they have been writing and reading for the past 20+ years
hasn't changed measurably from K&R's style.
The current codebase is unmaintainable, and the corporate coding and
design standards were tailored to match the style of all the 15-year-old
legacy code the application is built on, to avoid the work of having to
update the old code to new standards. A few months ago, I compared the
corporate standard to the project standard, and was not happy with the
items they tailored. The corporate standard is much more sensible, and
we should have updated our codebase as we went to meet it, not make the
old code compliant by definition.
I didn't really want to use this blog for venting about my job, but I'm
losing sleep over this tonight and felt writing about it might help.