When I was developing embedded systems, we had to comply with specifications that would allow a third party to verify the functional behavior of the system. The closest we came to a software coding standard was a short lived mandate that said systems needed to be developed in Ada. Invariably, we always received a waiver to the Ada requirement and generally used C to develop our systems. To be fair, most of what I worked on was prototypes and proof-of-concepts – we typically built a small handful of the system in question. The process for bringing these designs to a manufacturing level was a separate task.
When I started Embedded Insights, I spent some time discussing with my business partner how each of us approached software projects. This was important because we were planning to build a back-end database and client application to deliver capabilities in the Embedded Processing Directory that would change how developers find, research, and select their target processing options. That project is currently ongoing.
One of the software topics we discussed was coding style and how to represent design and implementation decisions. In a sense, we were negotiating software coding standards – but not pretty syntax rules. Rather, we were discussing how each of us incorporated design assumptions into the code so that someone else (possibly even ourselves a few years later) could figure out what thought process drove the software into its current implementation. I believe that is the essence of a coding standard.
Coding standards should not arbitrarily limit implementation decisions. They should enable a third party person to grasp what problems the previous developer was solving. By understanding the different challenges that the developer needed to simultaneously solve, what might appear to be “poor” coding practices might actually be making the best of a difficult situation.
In short, I think a coding standard should provide a mechanism by which developers can encode their assumptions in the implementation code without limiting their choices. This is especially critical for software because software systems must contend with shared resources – most notably in the time domain. The software from each developer must “take turns” using the CPU and other resources.
How important are software coding standards to the projects you work on? Do you use an industry standard or do you have a custom set of conventions that captures the lessons learned of your own “tribe” of developers? How formal are your coding guidelines and how do you enforce them? Or, do you find that spending too much effort on such guidelines contributes more to “mine is better than yours” religious wars than helping the team get the project finished?
Processor Tracker
All Entries RSS Feed