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

Purpose of the Standard

  1. Home
  2. Embedded C Coding Standard
  3. Introduction
  4. Purpose of the Standard

Barr Group’s Embedded C Coding Standard was designed specifically to reduce the number of programming defects in embedded software. By following this coding standard, firmware developers not only reduce hazards to users and time spent in the debugging stage of their projects but also improve the maintainability and portability of their software. Together these outcomes can greatly lower the cost of developing high-reliability embedded software.

This “BARR-C” coding standard is different from other coding standards. Rather than being based on the stylistic preferences of the authors, the rules in this standard were selected for their ability to minimize defects.  When it was the case that one rule had the ability to prevent more defects from being made by programmers than an alternative rule for a similar aspect of coding, that more impactful rule was chosen. For example, the stylistic rules for when and where to place curly braces were selected on the basis of their ability to reduce bugs across a whole program.

Clearly, no set of coding rules will be able to eliminate 100% of the defects from embedded systems. Interactions between electronics and software as well as between inter-connected systems are complex by their nature.  Even if there existed a team of programmers able to code perfectly and they followed all possible defect- minimizing rules, defects in the product could still occur as a result of: mistakes in the project requirements; misunderstandings of the requirements by implementers; oversights in the architecture of the system and/or software; insufficient handling of hardware failures or other exceptional run-time circumstances; etc.

Other important reasons to adopt this coding standard include increased readability and portability of source code. The result of which is reduced cost of code maintenance and reuse. Adopting the complete set of rules in this coding standard (i.e., not just the defect reducers) benefits a team of developers and its larger organization by helping to reduce the time required by individuals to understand the work of their peers and predecessors.

We recommend that the BARR-C coding standard be applied to your project as part of a broader effort to improve your organization’s embedded software development and quality assurance processes. Relative to the risks to human users of your projects, of course, an appropriate software development process may be lightweight but must emphasize the importance of system and software architecture to prevent and recover from run-time hazards as well as professional training for all programmers in this and other aspects of their work.1  At a minimum, your process should include not only a coding standard but also at least the use of version control and defect tracking tools, formal architecture/design reviews and peer code reviews, as well as automated source code scans via one or more static analysis tools.


Footnotes

[1] Whenever humans could be injured or killed by a product malfunction or insecurity, appropriate safety guidelines should be followed. This book is NOT a safety standard.

Book traversal links for Purpose of the Standard

  • ‹ Introduction
  • Up
  • Guiding Principles ›

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