4 handy embedded software tips

From time to time, I like to muse on some useful programming tips for embedded developers. This is such a time. I am not presenting hard and fast rules; I am just suggesting some possible good practices. I am also keen to promote discussion, as an alternate point of view is always interesting. Do contact me by comment or via email or social media …

Always use ++i instead of i++ if you are not saving the result of the expression

Every C programmer knows the difference between the prefix and postfix form of the ++ operator: ++i increments i and returns the new value; i++ increments i and returns the old value. They are both useful in various contexts. However, if you are not using the returned value – i.e. you just convert the the expression into a statement – does it matter which one you use? For example, you might write:

for (i=0; i<10; i++)
   ...

or

for (i=0; i<10; ++i)
   ...

They both do exactly the same thing, but is one better than the other?

The answer is: most of the time it makes no difference which form you use. If i is an int the resulting code would be identical. However, if i were an instantiation of a user-written class, and the ++ operator(s) had be overloaded, it would be a different story. The postfix form would probably result in some extra memory being used to accommodate the old value ready to return. Although compiler optimization might save the day, it is good practice to use the prefix form by default.

Never test for equality of floating point values

When floating point calculations are performed, there is always the possibility of tiny rounding errors. This results in code like this:

float x, y;
...
if (x == y)
   ...

being misleading. The result of some calculations may be that x and y are both 6.0. However, their actual values might be 6.0000001 and 6.0000002 respectively. So, the equality comparison would produce the wrong result. Clearly a comparison for less than or greater than would also need care.

Only have a single return point from a function; it makes for clear code

This tip is somewhat controversial and, to be honest, I could swing either way. The idea is that, there is only one entry point to a function: the top. There should, therefore, be a single exit/return point: the bottom. The thinking is that this makes the structure clear and avoids the possibility that any function exit code is overlooked.

The opposing argument is that, to achieve this structure, in some cases, may require some quite convoluted logic to steer execution to the bottom. The best approach is to perform parameter verification etc., which might result in an early exit, at the top and include one or more return statements there, if necessary. Then, enter the main body of the function, where there is a single exit at the bottom.

Coding standards like MISRA C encourage the single exit approach and it is mandated by some safety standards like IEC 61508 and ISO 26262.

Always initialize a variable at the point of definition. Never assume that it is zero

Even though the language standard says that static variables in C/C++ will always be initialized to zero, it is bad programming practice to assume that this is the case. If nothing else, readability of the code is improved by an explicit initialization. I feel that this is best done when the variable is declared, but it might be argued that the declaration are initialization are [for automatic variables anyway] separate things and that should be illustrated. So, looking at this code:

void fun()
{
   int alpha, beta=2;

   alpha = 3;
   ...

Which variable has been handled in the best/clearest fashion? The generated code will be the same either way.