Skip to main content

+1 866 653-6233 LinkedIn Software Expert Witness Directory

About Us Contact Us

Barr Group Software Experts

Barr Group Software Experts

Main navigation

  • Expert Services
    • Consulting Experts in Software and Electronics
    • Expert Reports by Testifying Software Experts
    • Reverse Engineering and Forensic Analysis
    • Software Source Code Review and Analysis
  • Areas of Expertise
    • Left Side
      • Artificial Intelligence
      • Automotive Systems
      • Cloud Computing
      • Computer Security
      • Consumer Electronics
      • Electronic Circuits
      • Enterprise Software
      • Financial Technology
      • Firmware and IoT
    • Right Side
      • Industrial Controls
      • Mechanical Design
      • Medical Devices
      • Military & Aerospace
      • Mobile Devices & Apps
      • Optical Equipment
      • Renewable Energy
      • Signal Processing
      • Telecommunications
  • Matters & Venues
    • Patent Infringement and Invalidity Experts
    • Software Copyright and Trade Secrets Experts
    • Product Liability and Failure Analysis Experts
    • Contract Disputes and Software Project Failures
    • Venues and Clients
  • Directory
  • Case Studies
    • DirecTV Anti-Piracy
    • Samsung Software Copyright
    • Toyota Runaway Cars
  • Resources
    • Expert Witness Blog
    • Source Code Review in Litigation
    • Software Source Code Discovery

Guiding Principles

  1. Home
  2. Embedded C Coding Standard
  3. Introduction
  4. Guiding Principles

To focus our attention and eliminate internal conflict over items that are too-often viewed by programmers as personal stylistic preferences, this coding standard was developed in accordance with the following guiding principles:

  1. Individual programmers do not own the software they write. All software development is work for hire for an employer or a client and, thus, the end product should be constructed in a workmanlike manner.

  2. It is cheaper and easier to prevent a bug from creeping into code than it is to find and kill it after it has entered. A key strategy in this fight is to write code in which the compiler, linker, or a static analysis tool can detect such defects automatically—i.e., before the code is allowed to execute.

  3. For better or worse (well, mostly worse), the ISO C Programming Language “Standard” permits a considerable amount of variation between compilers.2 The ISO C Standard's “implementation-defined,” “unspecified,” and “undefined” behaviors, along with “locale-specific options”, mean that even programs compiled from identical source code but via different “ISO C”-compliant compilers may behave very differently at run-time. Such gray areas in the C language standard greatly reduce the portability of source code that is not carefully crafted.

  4. The reliability, readability, efficiency, and sometimes portability of source code is more important than programmer convenience.

  5. There are many sources of defects in software programs. The original team of programmers will create some defects. Programmers who later maintain, extend, port, and/or reuse the resulting source code may create additional defects—including as a result of misunderstandings of the original code.

    • The number and severity of defects introduced by the original programmer(s) can be reduced through disciplined conformance with certain coding practices, such as the placement of constants to the left side of an equivalence (==) test.

    • The number and severity of defects introduced by maintenance programmers can also be reduced by the original programmer. For example, appropriate use of portable fixed-width integer types (e.g., int32_t) ensures that no future port of the code will encounter an unexpected overflow.

    • The number and severity of defects introduced by maintenance programmers can also be reduced through the disciplined use of consistent commenting and stylistic practices, so that everyone in an organization can more easily understand the meaning and proper use of variables, functions, and modules.

  6. To be effective, coding standards must be enforceable. Thus, when it is the case that two or more alternative rules would equally prevent defects, the more easily enforced rule is the better choice.

In the absence of a needed rule herein or a conflict within the coding standard your team commits to follow, the spirit of the above principles should be applied to guide the decision.


Footnotes

[2] See, e.g., [C90] and [C99].

Book traversal links for Guiding Principles

  • ‹ Purpose of the Standard
  • Up
  • MISRA C ›

Request an Expert

(866) 653-6233

Barr Group logo
Call us

Expert Services

  • Source Code Review Services
  • Expert Witness Directory
  • Reverse Engineering Services
  • Expert Reports & Testimony
  • How-To Technical Articles
  • Engineering Services

Latest Insights

  • Payment Processing and e-Payments Fraud
  • Albert Einstein Expert Witness
  • Medical Device Litigation and FDA 510(k)
  • Personality Traits of the Best Expert Witnesses

Website contents copyright © 2012-2025 by Barr Group. | Barr Group's logo is a U.S.-registered ® trademark.

SITEMAP  |  PRIVACY