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

6.2 Functions

  1. Home
  2. Embedded C Coding Standard
  3. 6 Procedure Rules
  4. 6.2 Functions

Rules:

6.2.a. All reasonable effort shall be taken to keep the length of each function limited to one printed page, or a maximum of 100 lines.

6.2.b. Whenever possible, all functions shall be made to start at the top of a printed page, except when several small functions can fit onto a single page.9

6.2.c. It is a preferred practice that all functions shall have just one exit point and it shall be via a return at the bottom of the function.

6.2.d. A prototype shall be declared for each public function in the module header file.

6.2.e. All private functions shall be declared static.    

6.2.f. Each parameter shall be explicitly declared and meaningfully named.

Example:

int
state_change (int event)
{
    int result = ERROR;

    if (EVENT_A == event)
    {
        result = STATE_A;
    }
    else
    {
        result = STATE_B;
    }
    return (result);
}

Reasoning: Code reviews take place at the function level and often on paper. Each function should thus ideally be visible on a single printed page, so that flipping papers back and forth does not distract the reviewers.

Multiple return statements should be used only when it improves the readability of the code.

Enforcement: Compliance with these rules shall be checked during code reviews.


Footnotes

[9] One way this can be accomplished is to insert a form feed character ‘FF’ (ASCII 0x0C) at the beginning of the first line on the comment block that precedes the function definition.

Book traversal links for 6.2 Functions

  • ‹ 6.1 Naming Conventions
  • Up
  • 6.3 Function-Like Macros ›

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