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

4.3 Source Files

  1. Home
  2. Embedded C Coding Standard
  3. 4 Module Rules
  4. 4.3 Source Files

Rules:

4.3.a. Each source file shall include only the behaviors appropriate to control one “entity”. Examples of entities include encapsulated data types, active objects, peripheral drivers (e.g., for a UART), and communication protocols or layers (e.g., ARP).

4.3.b. Each source file shall be comprised of some or all of the following sections, in the order listed: comment block; include statements; data type, constant, and macro definitions; static data declarations; private function prototypes; public function bodies; then private function bodies.

4.3.c. Each source file shall always #include the header file of the same name (e.g., file adc.c should #include “adc.h”), to allow the compiler to confirm that each public function and its prototype match.

4.3.d. Absolute paths shall not be used in include file names.

4.3.e. Each source file shall be free of unused include files.

4.3.f. No source file shall #include another source file.

Example: See Appendix D.

Reasoning: The purpose and internal layout of a source file module should be clear to all who maintain it. For example, the public functions are generally of most interest and thus appear ahead of the private functions they call. Of critical importance is that every function declaration be matched by the compiler against its prototype.

Enforcement: Most static analysis tools can be configured to check for include files that are not actually used. The other rules shall be enforced during code reviews.

Book traversal links for 4.3 Source Files

  • ‹ 4.2 Header Files
  • Up
  • 4.4 File Templates ›

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