If you’re working in a collaborative environment or if your projects are shared between different teams or companies, having a well defined coding standard can be useful to make sure that your code is easily understandable and maintainable between developers and down the road.
Aside from cosmetic issues like clear and consistent naming conventions (helpful as that is when debugging), a good set of coding standards also includes a lot of hard-won wisdom on what you should or shouldn’t do for reliability reasons as well.
While certain development platforms like C# (.Net) tend to have a single widely accepted ‘coding standard’ (the “IDesign C# Coding Standard” probably being the best and most widely adopted for that platform), things are a bit less homogonous for C (more broadly) or embedded C (specifically), and a few different ‘styles’ exist (K&R C, etc.).
A lot of this comes down to personal preference, but the following resources may be useful if you’re trying to improve your own coding, particularly for embedded systems where you have some unique safety and practical concerns.
Software Development with C – Coding Guidelines
A summary of current coding standards from Alexander Neundorf at the Technische Universität Kaiserslautern, this presentations has a good summary of C Coding Standards if you’d like a more in-depth description of why having a coding standard is important and what some of your options are.
MISRA is the “Motor Industry Software Reliability Association”, and amongst many other publications they have published, their “Guidelines for the Use of the C Language in Critical Systems” has been widely adopted both inside and outside of the automotive industry. As a ‘standard’, it’s quite restrictive, but this goes with the nature of safety-critical systems such as automotive, medical devices, etc. This particular standard sets the bar pretty high, but it also gives you a high confidence in the portability of your code and can help avoid a wide variety of common pitfalls that can be difficult to debug in the field. A number of automatic tools existing for checking code compliance again MISRA C and several high end compilers integrate support for checking MISRA C compliance, but they are all commercial and tend to be prohibitively expensive for hobbiest use. A PDF version of the MISRA C standard can be purchased for 10 British Pounds from MISRA Website, and is worth the investment if you want to develop safety critical or highly reliable systems.
JOINT STRIKE FIGHTER AIR VEHICLE C++ CODING STANDARDS – (Alternatively: PDF File)
While this standard from Lockheed Martin Corporation is aimed at C++, there is a great deal of information that can be adopted for C development as well, and the document can be freely downloaded from numerous places on the web. They draw extensively on the MISRA standards mentionned above, but also offer a lot of general explanations and comments that can be a good reminder for both experience and beginning embedded developpers.
Published by the Jet Propulsion Laboratory at the California Institute of Technology, this C coding standard is also freely available on the web, and is more concise than the JSF Standard above, though it is also much higher-level and doesn’t go into nearly the same detail. It can be a good high-level overview of what key pitfalls to avoid and is worth reading through and making some notes in the margins when developping your own coding style. Some of the higher level recommendations to ensure code maintanability are:
- Rule 2 (routine checking): All code shall always be compiled with all compiler warnings enabled at the highest warning level available, with no errors or warnings resulting. All code shall further be verified with a JPL approved state-of-the-art static source code analyzer, with no errors or warnings resulting. [MISRA-C:2004 Rule 21.1]
- Rule 25: Functions should be no longer than 60 lines of text and define no more than 6 parameters. [Power of Ten Rule 4]