![]() For fairly pragmatic reasons, then, our coding rules primarily target C and attempt to optimize our ability to more thoroughly check the reliability of critical applications written in C. For this reason, C is also the target of the majority of coding guidelines that have been developed. With its long history, there is extensive tool support for this language, including strong source code analyzers, logic model extractors, metrics tools, debuggers, test support tools, and a choice of mature, stable compilers. At many organizations, JPL included, critical code is written in C. The choice of language for a safety critical code is in itself a key consideration, but we will not debate it much here. In return, we should be able to demonstrate more convincingly that critical software will work as intended. When it really counts, especially in the development of safety critical code, it may be worth going the extra mile and living within stricter limits than may be desirable. To support strong checking, the rules are somewhat strict – one might even say Draconian. Such a small set, of course, cannot be all-encompassing, but it can give us a foothold to achieve measurable effects on software reliability and verifiability. To put an easy upper-bound on the number of rules for an effective guideline, I will argue that we can get significant benefit by restricting to no more than ten rules. ![]() The rules will have to be specific enough that they can be checked mechanically. To be effective, though, the set of rules has to be small, and must be clear enough that it can easily be understood and remembered. A verifiable set of well-chosen coding rules could, however, make critical software components more thoroughly analyzable, for properties that go beyond compliance with the set of rules itself. The benefit of existing coding guidelines is therefore often small, even for critical applications. Tool-based checks are important, since it is often infeasible to manually review the hundreds of thousands of lines of code that are written for larger applications. The most dooming aspect of many of the guidelines is that they rarely allow for comprehensive tool-based compliance checks. Not surprisingly, the existing coding guidelines tend to have little effect on what developers actually do when they write code. ![]() ![]() Some rules, especially those that try to stipulate the use of white-space in programs, may have been introduced by personal preference others are meant to prevent very specific and unlikely types of error from earlier coding efforts within the same organization. The result is that most existing guidelines contain well over a hundred rules, sometimes with questionable justification. Among the many that have been written there are remarkable few patterns to discern, except that each new document tends to be longer than the one before it. Curiously, there is little consensus on what a good coding standard is. These guidelines are meant to state what the ground rules are for the software to be written: how it should be structured and which language features should and should not be used. Most serious software development projects use coding guidelines. Holzmann NASA/JPL Laboratory for Reliable Software Pasadena, CA 91109 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |