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

2.1 Acceptable Formats

  1. Home
  2. Embedded C Coding Standard
  3. 2 Comment Rules
  4. 2.1 Acceptable Formats

Rules:

2.1.a. Single-line comments in the C++ style (i.e., preceded by //) are a useful and acceptable alternative to traditional C style comments (i.e., /* … */).

2.1.b. Comments shall never contain the preprocessor tokens /*, //, or \.

2.1.c. Code shall never be commented out, even temporarily.

i. To temporarily disable a block of code, use the preprocessor’s conditional compilation feature (e.g., #if 0 … #endif).

ii. Any line or block of code that exists specifically to increase the level of debug output information shall be surrounded by #ifndef NDEBUG …#endif.

Example:

/* The following code was meant to be part of the build...
...
safety_checker();
...
/* ... but an end of comment character sequence was omitted. */

Reasoning: Whether intentional or not, nested comments run the risk of confusing source code reviewers about the chunks of the code that will be compiled and run. Our choice of negative-logic NDEBUG is deliberate, as that constant is also associated with disabling the assert() macro. In both cases, the programmer acts to disable the verbose code.

Enforcement: The use of only permitted comment formats can be partially enforced by the compiler or static analysis. However, only human code reviewers can tell the difference between commented-out code and comments containing descriptive code snippets.

Book traversal links for 2.1 Acceptable Formats

  • ‹ 2 Comment Rules
  • Up
  • 2.2 Locations and Content ›

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