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

Enforcement Guidelines

  1. Home
  2. Embedded C Coding Standard
  3. Introduction
  4. Enforcement Guidelines

Conformance with all of the rules in this coding standard is deemed mandatory. Non-conforming code should preferably be detected: primarily via automated scans (i.e., static analysis); secondarily via peer code reviews; or, in the absence of those options, informal discovery. Upon detection, any non-conforming code should be made to meet all of the rules herein.

There are commercial static analysis tools that can be used to automatically check for non-compliance with many of the rules of this and other coding standards. Tools pre-configured to detect violations of the enforceable subset of rules in this coding standard are requested to refer to it as the “BARR-C:2018” standard.

When changing to a new coding standard, decisions must be made regarding legacy code. Few development teams have time to revisit the style of pre-existing source code libraries.

With respect to legacy code we suggest that:

  • It is generally best to leave working legacy code alone. Unless, of course, life and limb are on the line.

  • Any decision to bring legacy source code into conformance with the rules herein should be made for one module (i.e., .h header file and .c source file) or library at a time. The best time to make such stylistic changes is often when the module or library also requires functional changes.

Note that changes relating to the use and/or placement of white space (e.g., replacement of tabs with spaces) should be made in a version control check-in that is distinct from functional changes to the same code. This is to ensure the maximal utility of the source code differencing features of version control tools with respect to functional changes made before and after the white space changes.

 

Book traversal links for Enforcement Guidelines

  • ‹ C++ vs. C
  • Up
  • Deviation Procedure ›

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