2. Rationale

NASA programs and projects have multiyear life cycle times. Often the software personnel who develop the original software work products move on to other projects. These developers are then backfilled on the team by other developers for the remainder of development, for operations, maintenance, and disposal phases of the life cycle. This personnel turnover process may occur several times during the project's life cycle. The use of uniform software coding methods, standards, and/or criteria ensures uniform coding practices, reduces errors through safe language subsets, and improves code readability. Verification that these practices have been adhered to reduces risk of software malfunction for the project during its operations and maintenance phases.

3. Guidance

Coding standards for software have been developed for years and represent lessons learned by coding experts.  Coding standards help prevent or reduce unsafe coding practices such as defect-prone coding styles, security issues from specific coding sequences, numerous coding errors, mistakes, and misunderstandings.  “Coding standards are the ‘materials and manufacturing standards’ for implemented software...

Human-rated certification and mission critical software both require the application of a recognized coding standard, one that is supported by automated analysis tools, for all software required to be certified for human spaceflight and mission critical applications.  Manual verification is all but impossible.

The reduction in effort by simply adhering to a coding standard that can be tested through automation is the one certification process that truly has no other method of efficient verification. ...  As security becomes an issue, security coding standards should also be applied.” ⁴⁷⁶

General Coding Standard Guidance

Planning for the adoption and use of coding standards at the beginning of a software development activity sets the right tone and approach for the development team.

Software coding standards are classified by language, usage, and severity levels. Language specific rules and best coding practices are usually determined by experts in the particular language [e.g., C++, ADA] and tailored as needed by the project. Usage types and severity levels are set by the user. ³²⁶

Over time, correlations between bugs and coding practices resulted in a set of rules that helped to prevent coding errors from occurring. ³²⁶These activities resulted in recommendations to develop and use coding standards.

In a team environment or group collaboration, the use of coding standards ensures uniform coding practices, reduces oversight errors, and the time spent in code reviews. When NASA software development work is outsourced to a supplier (see topic 7.03 - Acquisition Guidance),having a set of coding standards in place helps to ensure that the code produced by the contractor meets quality requirements mandated by NASA in the NASA Software Assurance Standard, NASA STD 8739.8. ²⁷⁸

A coding standard document may be written as a general document that is independent of any project. Project-specific needs are then added as amendments to the document. Note there is an important difference between a coding style and a coding standard. A coding style specifies how you indent lines or employ tabs and spaces to make the code easier to read by the software development team. A coding standard, which often includes a coding style, goes beyond just how to name a variable. It tells you how that variable is to be treated and when it is to be used (and not used). ⁰⁰⁶ Use of these standards will help the developer avoid actions that are not a smart practice to get into. They may also restrict coding statements to language statements from national or international standards.

One way to tell the difference between a coding style and a coding standard is to assess the functionality of code changed as the result of applying the coding style or standard. If the coding style was not followed, the code should still work exactly the same way, with exactly the same behavior and safety checks. However, if the coding standard is not correctly applied, it is likely that the code's "safety" and/or functionality have changed. A coding standard is more important than a coding style since the standard affects the behavior of the code.

How Coding Standards are Classified

Software coding standards are classified by language, usage, and severity levels. Language specific rules and best coding practices are determined by industry experts in that particular language. Usage types and severity levels are set by the user. ³²⁶

Coding standards should address (for all the languages used):

• Code structure (includes overall project layout (files, and so on), classes, resources, and other source file types).
• Error handling (describes how objects handle errors, reporting, and logging).
• Module size (should be limited).
• Library routines, especially the following:

• Operating system routines.
• Commercial library routines (e.g., numerical analysis).
• Project-specific utility routines.

• Constants and data types (rules for defining).
• Global data use.
• Compiler-specific features not in the language standard. ⁰⁰⁷

The following items may be an integral part of the coding standard to the extent their implementation actually affects the outcome of the execution of the software. Otherwise they are part of the coding style.

• Formatting: Includes the use of white space, indentation, and length of statement lines in code. Some standards might include, for example, common editor setup and handling for tabs versus spaces for indentation.
• Naming conventions: Specifies how developers name their methods, classes, variables, events, and parameters.
• Comments: An English description in the code that explains the logic of the code. (Quality code is usually self-documenting by default.) The use of quality commenting gives quality code better maintainability and easier understandability.

Adherence and Verification

Assuring the adherence of the developed software to the coding standards provides the greatest benefit when followed from software development inception to completion. Coding standards are selected at the start of the software development effort. Verification activities of the software work products (see SWE-028) include reviews, such as peer reviews and inspections (see SWE-087), and assessments of how the coding standards are used to develop the software work products.

The use of automated tools for assessing adherence to standards at appropriate reviews, or even on a batch mode run overnight, will assist the project team in adherence and verification. “Code should be mechanically checked against the standards with the help of state of-the-art static source code analyzers. ... Flight code should be checked nightly for compliance with a coding standard and subjected to rigorous analysis with state-of-the-art [static source code analysis tools]. The warnings generated by each of these tools is combined with the output of mission specific checkers that secure compliance with naming conventions, coding style, etc. In addition, all warnings, if any (there should be none), from the standard C compiler, used in pedantic mode with all warnings enabled, should be provided to the software developers... [who] are required to close out all reports before a formal code review is initiated. In peer code reviews, an additional source of input is provided by designated peer code reviewers... Separately, key parts of the software design can be also checked for correctness and compliance with higher level design requirements with the help of logic model checkers.” ⁴⁷⁷

Training should be provided for the software development team in the use of logic model checkers for the analysis and verification of flight software. ⁴⁷⁷

Manual analysis to verify the complete application of safety or security coding standards is all but impossible. ⁴⁷⁶

MISRA and CERT-C Coding Standards

Two example coding standards to improve safety, reliability, and security in software systems are MISRA and CERT C. MISRA C has become the de facto standard for embedded C programming in safety-related industries and is also used to improve software quality even where safety is not the main consideration.

“The CERT C Secure Coding Standard is composed of 89 rules and 132 recommendations for producing secure code.  It is recommended that compliance with a standard like CERT C be performed by a static analyzer, depending on program size and complexity.  A source code static analysis tool meeting ISO/IEC TS 17961 conformance is recommended.

The following quote from the author of the second edition of the CERT C Coding Standard describes what static analysis for conformance can imply.

While the application of these rules and recommendations does not guarantee the security of a software system, it does tell you ...that the software was developed to a set of industry standard rules and recommendations that were developed by the leading experts in the field. ... that ...time and effort went into producing code that is free from the common coding errors that have resulted in numerous vulnerabilities ...over the past two decades ... that the software developers who produced the code have done so with a real knowledge of the types of vulnerabilities that can exist and the exploits that can be used against them, and consequently have developed the software with a real security mindset.” ⁴⁷⁶

How to Interpret the "and/or" Phrase in the Requirements Statement

The "and/or" in the text of the requirement statement is meant for flexibility in tailoring the requirement to the needs of the project. In appropriate (e.g., less "critical") settings, a subset of ”methods, standards, criteria” would be sufficient and compliant. For human-rated applications, the project would want to cover methods, standards, and criteria (e.g., the use of the Klocwork® Insight  tool as part of the method,

MISRA C (a software development standard for the C programming language developed by MISRA (Motor Industry Software Reliability Association)

 as part of the standards, avoidance of the project's restricted language constructs as criteria, etc.).

NASA-specific coding standards information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook. 

Additional guidance related to the planning and control of software coding standards, and where they may be used, may be found in the following related requirements in this Handbook:

4. Small Projects

Smaller projects may consider using previously developed/tailored coding methods, standards and guidelines, rather than developing their own. These standard applications may be available in the software Process Asset Librarys (PAL) of other Centers, if not available at the performing Center.

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

The NASA Lessons Learned database contains the following lessons learned related to coding standards:

• Software Design for Maintainability. Lesson Number 0838. NASA has long recognized that software maintenance is a large cost driver in its software systems. Early planning for maintenance, which includes the use of appropriate and consistent coding standards, coding styles, and software configuration management systems, helps hold down software maintenance costs over the software life cycle. The lessons learned citation given below provides additional information on this topic of coding standards. ⁵²⁶ .
• Mars Pathfinder Flight Software Development Process (1997). Lesson Number 0590. The software developer should also recognize that there is benefit to using coding standards dedicated to the project at hand. As this set of lessons learned derived from the Mars Pathfinder project shows, even though the coding standards and styles were tailored for the project, maintaining the set of derived coding standards for future upgrades and improvements will assure cost control ⁵¹⁰.