Two big trends in the embedded world are on a collision course – and the resolution isn’t going to be easy. The two trends are the requirements that all code meet internal coding standards and the use of third party code.
Organizations have been gradually been getting religion about having and enforcing coding standards. As well as spelling out what the source code should look like, and making rules for what is kosher, many internal standards now also require code to be ‘Lint free’, and also possibly that it conform to various standards, such as those laid down by MISRA.
Simultaneously, organizations have been striving to improve productivity. One way of doing this is to turn to code re-use. Code re-use is normally discussed in the context of code that you’ve already developed being re-used in subsequent projects. However, a far more powerful paradigm is to use code that others have developed. Need a CRC algorithm, or a way of computing a MD5 hash – head to the Internet to find your source code. Have a need to develop a complex state handler – hello visualSTATE. Need to develop a GUI – take your pick from a plethora of component suppliers. Now if you were developing for a PC, most of this code would be supplied in binary format. However with the plethora of embedded targets and compilers, the chances are you’ll get source code that you’ll need to compile.
Now, the chances of the source code matching your coding standards should be nil. So what is to be done? My experiences to date have been pragmatic – but not pretty.
For small pieces of code, I simply rewrite them to bring them up to standard.
For third party libraries, such as a graphics library, it is usually impractical, if not illegal, to modify the source code, and so one is forced to accept the code as is.
For machine generated code, even if it’s small, rewriting the code is pointless, since the chances are you’ll be regenerating it later and over-writing your work. Thus, once again, one is forced to accept the code as is.
So what is to be done? At present, my coding standards procedure allows one to issue a variance where code doesn’t comply (in pretty much the same way that MISRA allows variances to be issued). Although this is OK, let’s recognize it for what it is – a cop out. What we really need are the suppliers of source code to recognize and adhere to various ‘standards’. For example:
1. Use the C99 data types folks. I’m tired of seeing UINT8 definitions everywhere when ISO has stipulated that a uint8_t data type is an 8 bit unsigned type.
2. Make your code Lint free. If you’re selling source code, it’s in your interest to make it as clean as possible. PC-Lint from Gimpel is the gold standard, so make sure you can pass it with a clean bill of health (and I don’t mean by suppressing every complaint it has).
3. Make your code MISRA compliant. MISRA can be a pain – but their intentions are good. If nothing else, making your code MISRA compliant will increase the size of your target market. This issue has been recognized by IAR to whom I’d like to congratulate for making the code generated by the upcoming new release of visualSTATE MISRA compliant.
What if you are just an honest Joe, just putting code out there for all to use and enjoy? Well why not adhere to the same rules? It’ll make your code more useful – and after all isn’t that the point of publishing it in the first place?