Coding standards reboot
Most programmers have a set of coding standards they work to. These range from cosmetics such as indentation style to more fundamental things like acceptable maturity of dependencies or memory management standards.
I’ve recently given my own standards a reboot and it mostly boils down to the phrase: “don’t ship bugs”.
I used to write a lot of code like this:
/* FIX: global - make this thread safe */
float *temp[5000];
/* FIX: eventually pass arguments rather than using globals */
void to_be_replaced(void)
{
/* FIX: inline constant */
for(int i = 0; i < 5000; i++)
{
/* FIX: memory leak */
temp[i] = malloc(sizeof(float));
/* FIX: inefficient - refactor */
*temp[i] = cosf(i);
}
}
/* etc...*/
This code smacks of under-confidence and/or low standards. The issue isn’t so much the problems it contains, as the fact that they are knowingly left in the code. “FIX” comments are added as an acknowledgement as if to say “I know this is wrong, but I’ll come back to it later”.
This might work for some developers, especially on single-author projects. However if you’re working as part of a team, seeing a lot of “FIX” in code is unnerving and undermines confidence. For me, code comments aren’t fine-grained enough to serve as a bug reporting mechanism.
So what’s the solution?
From now on I’m going to be doing the following:
- don’t commit code that has known problems
- transfer intended improvements from the code to an issue tracker (no “FIX”)
- develop vertically rather than rushing larger pieces of functionality
- write skeleton code to sketch structure
Point 3 is probably the most significant and important. It also implies a shift in approach to architecture — to facilitate this vertical approach, the software architecture (and development methodology) need to be able to support it.
In summary: “working but incomplete” is better than “complete but broken”.
