Main Menu
Documentation
Community
Last changes
Search
Sponsors

Coding Guidelines

Module Layout

Header files

Source files


Coding Style

Tabs & Indenting

Tab characters (\0x09) should not be used in code. All indentation should be done with 4 space characters.

Bracing

Open braces should always be at the beginning of the line after the statement that begins the block. Contents of the brace should be indented by 4 spaces. For example:
if (someExpression)
{
   DoSomething();
}
else
{
   DoSomethingElse();
}

“case” statements should be indented from the switch statement like this:
switch (someExpression)
{
   case 0:
      DoSomething();
      break;

   case 1:
      DoSomethingElse();
      break;

   case 2:
      {
         int n = 1;
         DoAnotherThing(n);
      }
      break;
}

Braces should never be considered optional. Even for single statement blocks, you should always use braces. This increases code readability and maintainability.

It is suggested that all control structures (if, while, for, etc.) use braces, but it is not required.

Commenting

Comments should be used to describe intention, algorithmic overview, and/or logical flow. It would be ideal, if from reading the comments alone, someone other than the author could understand a function's intended behavior and general operation. While there are no minimum comment requirements and certainly some very small routines need no commenting at all, it is hoped that most routines will have comments reflecting the programmer's intent and approach.

Copyright notice

Each file should start with a copyright notice. Ideally using doxygen style comments will make it easy to generate the final software documentation. Final text may vary, but should be similar to:
/*******************************************************************
*
* DESCRIPTION: OSEK OS (Operating System) implementation
*
* $Id:$
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the
* Free Software Foundation, Inc.,
* 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
*
* Copyright 2004-2007 by openOSEK.org development team
*
* HISTORY:
*
* $-Log-$
*
*******************************************************************/

Documentation Comments

All functions/methods should use doxygen style comments.

Spacing

Spaces improve readability by decreasing code density. Here are some guidelines for the use of space characters within code:

Do use a single space after a comma between function arguments.
Right: 
Read(myChar, 0, 1);

Wrong: 
Read(myChar,0,1);


Do not use a space after the parenthesis and function arguments
Right: 
CreateFoo(myChar, 0, 1);

Wrong: 
CreateFoo( myChar, 0, 1 );


Do not use spaces between a function name and parenthesis.
Right: 
CreateFoo();

Wrong: 
CreateFoo ();


Do not use spaces inside brackets.
Right: 
x = dataArray[index];

Wrong: 
x = dataArray[ index ];


Do use a single space before flow control statements
Right: 
while (x == y)

Wrong: 
while(x==y)


Do use a single space before and after comparison operators
Right: 
if (x == y)

Wrong: 
if (x==y)

Naming convention

  • Do not use Hungarian notation
  • Do not use a prefix for member variables (_, m_, s_, etc.).
  • Do use camelCasing for member variables
  • Do use camelCasing for parameters
  • Do use camelCasing for local variables
  • Do use PascalCasing for function, property, event, and class names
  • Do prefix interfaces names with 'I'
  • Do not prefix typedefinitions, enums, classes, or delegates with any letter

  • Functions/methods should be named as what they do ( e.g. OpenFile() ).
  • Variables should be named to describe the data they hold ( e.g. numberOfElements ).
  • Avoid the use of acronyms.

Coding convention

  • Should be accoding to MISRA-2004 guidelines
  • Should pass static test with LINT - (a good reference is the splint website) 







 




  Last edited by rabiddog
  .
                                         
  Page last modified on Sunday 25 of May, 2008 [20:42:32 UTC].





      
            





  

    



    






 

  
  
  

    
  










    
    	

    
 

	



    

            

      		
          

    

  

    

    	

						RSS
				Wiki