Coding Style

Tabs or Spaces?

Tabs. Not spaces. Every level of indentation should be at a new level of tabification.

Braces on their own line

Do this:

if( person.isCool() == true )
{
    person.buyPizza();
}

not:

if( person.isCool() == true ){
    person.buyPizza();
}

And definitely not:

if( person.isCool() == true ){ person.buyPizza();}

Variable Names

Be as verbose as you need to be to get across the meaning of the variable. When in doubt, go with a longer name.

So make variables that look like:

silentAlarmListenThread

not

SA_LstnThrd

Otherwise, use standard styles, such as:

Function names

Should start with a capital letter, be camel cased, and be a statement about what the function DOES. Such as:

NormalizeDataPoints()

Functions that return boolean values

The name should be in the form of a question that is answered by the return value. IE:

ArePacketsHostile()

#define macros

Any constant defined as a preprocessor macro must be placed in ALL CAPS with underscores between words, such as:

TRAFFIC_EVENT_MAX_SIZE

Normal Variables

Start with lower case letter and then camel case afterward.

normalizedDataPts

Underscores can be used in places where camel casing might make a confusing or difficult to read:

IP_protocol

instead of:

IPProtocol

Function Contract Documentation

All public functions should include above both their declaration (header file) and definition (.cpp file) a verbose description of its workings, inputs, and outputs.

This contract consists of:

1. A short plain-english description

2. List and specification of each parameter

3. Any side effects

4. What the return values are, and what they indicate

   //This first line describes what the function does in plain english, without simply repeating the function name // paramOne - This type specifies how X behaves // paramTwo - This value specifies Y // Note: This function increments the global "counter" variable // returns - A boolean signifying success bool DoStuff(int paramOne. int paramTwo); }}}

Private functions need only maintain a lesser standard of documentation, where a single or two describing what the function does is sufficient. Any notable side effects, assumptions, or non-intuitive uses should be noted but otherwise less is okay.

Log Levels

When calling the logger, make sure to enter log level appropriate to the situation at hand. The Logger uses the standard set of 8 log levels used by the kernel and syslog. One should not use a lower level than is expected: that will cause errors to go unnoticed. One should also not use a higher level than expected, that will cause lots of noise in the logs. Use exactly what is appropriate:

LOG_EMERG	0	/* system is unusable */
LOG_ALERT	1	/* action must be taken immediately */
LOG_CRIT	2	/* critical conditions */
LOG_ERR		3	/* error conditions */
LOG_WARNING	4	/* warning conditions */
LOG_NOTICE	5	/* normal but significant condition */	
LOG_INFO	6	/* informational */
LOG_DEBUG	7	/* debug-level messages */