× You're looking at the old version of the wiki! As of January 2020, all pages have been migrated to the new site at: http://wiki.speeduino.com

Style code

From Speeduino
Revision as of 07:16, 25 October 2016 by Josh (talk | contribs) (Created page with "= C Program Layout = In a C program file items must be arranged in the following sequence: Header comment #included files #defines #local struct typedefs #local prototypes #g...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

C Program Layout

In a C program file items must be arranged in the following sequence:

Header comment

  1. included files
  2. defines
  3. local struct typedefs
  4. local prototypes
  5. global vars
  6. main function (if present)
  7. local functions

In a C header (.h) file items must be arranged in the following sequence:

  1. Header comment
  2. ifndef guard
  3. included files
  4. defines
  5. struct typedefs
  6. prototypes
  7. (extern) global vars


All names should be meaningful and follow existing usage patterns if present.


Item Standard Example


camelCase, lowercase first letter, no spaces or _ readSensor();
Variables sensorValue = 0;
Anonymous variables (eg some loop counters) Single lowercase letter (Preferred order or use: x, y, z, i) x++;
Constants UPPER_CASE, words joined with _ #define TWO_SQUARED 4


  • Use spaces for indents, not tabs
  • Indent 2 spaces per level
  • Always use { }, even for single statement blocks
  • Describe block structures using indentation, do not rely on { } alone
  • For multiple line blocks, brackets should always have their own line:
 void readSensors()
  • Single line blocks (if/else statements etc) should be on the same line and must includes braces
 if(fanEnabled) { digitalWrite(fanPin, HIGH); }


  • Declare variables at the top of the function
  • In a block of related definitions vertically align the names, types, and initialisations
  • Initialise variables close to where they are first used.


  • Put the return type on same line as function name
  • Functions should be kept as short, and broken into sub-functions as required
  • Each function should have a single clearly defined purpose, this purpose should be reflected in its name.

Executable Statements

  • One per line, not i=0; j=0;
  • Multiple operations are permitted per line where appropriate. Eg: i = j = 0;
  • True / False if statements should not use a comparison to 0 or 1. Eg:
    • Good: if(isEnabled)
    • Bad: if(isEnabled == 1)

don't use comma operator

Function definitions

  • Use inline static for all non-interface functions
  • Use prototypes for all functions (even those returning int)
  • Don't turn parameter type checking off in prototypes with (), use (void) instead
  • Give sensible variable names in prototypes


  • Blocks comments should be used for any single comment longer than one line
  • Single comments are preferred at the end of a line rather than on their own line beforehand