My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
StyleGuide  
Project style guide
Updated Oct 16, 2008 by schw...@gmail.com

Here are the code style guidelines. You may violate them if doing so will produce more readable code FOR ALL (not just you).

Your editor/fingers/terminal not supporting this style is not an excuse. It's 2008, adapt your editor/fingers/terminal.

The Basics

Follow these basics and you'll be fine.

  • 4 character indentation.
  • NO LITERAL TABS
  • unless inside a string, then use your discretion
  • Unix newlines.
  • Max 100 characters wide.
  • Use whitespace liberally

Naming

Use this_style_of_naming to separate words.

Variable Names

Knowing when your code will have global effect is of critical importance, therefore global variables must stand out. Use this style of naming.

  • local for variables inside a subroutine
  • Global for variables outside a subroutine
  • CONSTANT for constants and macros

With the following exceptions, no single character variable names.

  • i, j loop indexes

idx is preferred over i. Consider moving the inner loop into its own subroutine.

Functions

Are for more than just using code twice. They break up the code into logical chunks which are easier to read, understand and reuse.

If you find yourself writing a long explanatory comment, stick the code in a subroutine.

If your nesting more than a level or two, stick it in subroutine.

If your blocks run so far off the page you can't remember what the condition was, stick the code into a subroutine.

Declare all private functions as static.

Blocks

Block style for simple conditions:

  if( condition ) {
      code
  }
  else {
      code
  }

Complex conditions:

  if( condition              or
      another condition      or
      yet another condition           
  ) {
      code
  }
  else {
      code
  }

Only use block-less if's for simple statements.

   /* Ok */
   if( condition )
       statement;
    /* Not ok */
    if( condition           or
        another condition )
        statement;

    /* Not ok */
    if( condition )
        statement;
    else {
        statement;
        statement;
    }

Parens

The paren is attached to the enclosing element...

  function( args );

  if( condition ) ...

Horizontal Whitespace

Use horizontal whitespace to make similar things look the same, and vice-versa.

For example, line up related assignments.

char *name        = "Yarrow Hock";
char *rank        = "Rear Admiral";
int serial_number = 123456;

char *food = "bagel";

Vertical Whitespace

Please use extra vertical whitespace to help differentiate between logical code elements.

  • Place two blank lines between subroutines.
  • Place blank lines between logical hunks of code.
  if( thing ) { 
      some code
  }

  some more code

  if( other thing ) {
      other code
  }

Compatibility

We must be compatible with ANSI C89 and POSIX.

Extensions to those standards (GNU, BSD, C99...) must be wrapped in ifdefs.

Goto

Considered harmful. Avoid it. Instead, call a subroutine. If there's too many variables to pass in, collect them into a struct (they're probably related).

Tests

Write them. We use a custom TAP library. Here's a sample of a very simple test.

#include "t/tap.c"
#include "time64.h"

int main(void) {
    /*  have,  want, label     */
    ok( 1 + 1, 2,    "addition" );

    done_testing();
}

See t/timegm.t.c for a good example of how to write a test.

Comment by project member schw...@gmail.com, Oct 13, 2008

I'm not a C programmer, this is adapted from my Perl style. They all have good reasons for readability and maintainability. I'll gladly change to a style more native to C, but it needs to be for a good reason. Not just "because that's how C programmers do it". I've read too much C code to fall for that one.


Sign in to add a comment
Powered by Google Project Hosting