General Guidelines for Coding

1. At the lowest level, individual statements and small group of statements should be distinct use a line space • do not exceed expression more than one line it can be fixed to 70 characters • parenthesize expression for less ambiguity #define MULTIPLY(x,y) ( x * y ) #define MULTIPLY(x,y) ( ( x ) * ( y ) ) //better • avoid bulky computational expressions of arrays • clear readability of code structure use a few well defined control primitives avoid: goto,do-while • use macros for clarity Multiplied_value = MULTIPLY(5,6); • avoid nested macros #define MAX(a,b) ((a)>(b)?(a) b)) #define ABS(a) ((a)>0?(a) -1 * (a))) #define DISTANCE(y1,x1,y2,x2) (MAX(ABS((y1) - (y2)),ABS((x1) - (x2)))) General Guidelines for Coding N.K.Das, PIRD, IGCAR

2. Recursive functions can be dangerous, may go into infinite loops. • int fib(int n) • { • if (n==0 || n==1) • { • return 1; • } • return fib(n-1)+ fib(n-2); • }// what will happen if n = -10 • use data hiding in modules/procedures How to implement data hiding in C? declare data structures in the header files, not to define them • initialize all variables int iTemp=0; • avoid programming tricks X[i] or i[X] do the same • use library functions if available N.K.Das, PIRD, IGCAR

3. avoid dynamic variables • clarity should not be sacrificed at the cost of minor gains in efficiency • the program should be robust • anticipate possible changes, and make it flexible Ex. char Name[20];//if 20 char is sufficient Otherwise #define name_width 20 char Name[name_width]; //better N.K.Das, PIRD, IGCAR

4. Specific Guidelines for Coding Programming Language • C/C++ preferable • avoid assembly language Use only following cases a) When certain processing cannot be done in higher languages ex. Context switching b) When parts of the code does not meet timing requirement c) If it is mandated by for the project N.K.Das, PIRD, IGCAR

5. Specific Guidelines for Coding • Modules/Procedures • each modules/procedures correspond to a unique function • uniform interface throughout • minimum number of parameters of procedures • minimum usage of global variables • procedures should have single entry - single exit, other than error handling • explicitly defined types of parameters of a procedure • explicitly defined types of return value of a procedure • ensure type-matching in procedure call (use typecasting if necessary) • restrict procedure less than 50 statements N.K.Das, PIRD, IGCAR

6. Specific Guidelines for Coding • Code Layout • each file should have following order of codes /***********FileHeader********************/ • Package Name: myPackage.c • Project: AE-Sensor Networking System • Author: Mr. Code • Version: x.xx.xx • Date: mm-dd-yy • Modified by Mr. Modi • Date of Modi mm-dd-yy • Version: x1.xx0.xx1 • /***** list of include files*****************/ • #include <ltstdlib.h> // Correct • #include <ltstdio.h> // • #include <ltXm/Xm.h> // • #include "meaningfulname.h" // • #include "/proj/util/MeaningfulName.h" // wrong – absolute path given • #include <ltstdlib.h> // wrong – out of order • #include </usr/include/stdio.h> // wrong – path given for system file N.K.Das, PIRD, IGCAR

7. Specific Guidelines for Coding • Code Layout • // external declarations • extern someExtVriables; • // pseudo and macros • // definitions of derived types (enum, struct, union etc.) • // definitions of global data • // module header,module data and module procedures for each module • single module per file • within a procedure, separate variables declarations and statements by a line N.K.Das, PIRD, IGCAR

8. Specific Guidelines for Coding • Code Layout • indentations shall be used to indicate logical depths • int main() • { • doSomething(); • switch ( value ) • { • case 1: • { • while ( value == 0 ) • { • doSomething(); • } • break; • } • case 2: • case 3: • { • doSomething(); • break; • } • default: • { • break; • } • } • } N.K.Das, PIRD, IGCAR

9. Specific Guidelines for Coding • Naming • all namesof derived types(struct,unions)mixed case starting with uppercase Ex. Line, Socket • enum and const all UPPERCASE Ex. DAYS in enumerated type, MAX_ITERATIONS, PI • variables in mixed case starting with lower case Ex. chNumber, • Names representing methods or functions must be verbs and written in mixed case starting with lower case. • Ex. getName(), computeTotalWidth() • Declarations and definitions • data types of variables shall be explicitly declared ex. static myInt;//not a good practice, better -> static int myInt; • each variable should have single purpose • possible values of variables should be in the commentary • where size of a data(e.g. Array) may change use pseudos N.K.Das, PIRD, IGCAR

10. Specific Guidelines for Coding • Global Variables • minimize global variables usage • only a single procedure/task should update (write) a global variable while all others should only use (read-only) the global variable. Inputs/Outputs • Input format and sequence should be in user friendly natural form. Ex. It should not be in hexadecimal input • output should have proper headings and lebels • logical group of data should be separated by blank lines or page-breaks or any other formatting practices • in case of file I/O file format should be given N.K.Das, PIRD, IGCAR

11. Specific Guidelines for Coding • Control Structures • In if-elseif-else condition constructs Conluding 'else' should always exist in this 'if'-'else'-'if' statement. The final 'else' clause should provide a 'catch all' else arm. • avoid bushy tree • avoid “else break” or “else return” • floating point numbers shall be properly checked for equality (truncation threat) • control variable should always be defined within a local scope i.e.the block containing the loop itself. • For example: • static int si; • void func1(void) • { • for (si=0; si<3; si++) /* error */ • { • ... • } • } N.K.Das, PIRD, IGCAR

12. Specific Guidelines for Coding • Control Structures • There should not be more than one loop control variable. • For example: • for (i=0, j=0; (i < 10) && (j < 5); i++, j++) /* two possible loop control variables */ • { • /* ... */ • } • inswitch constructs “default case /branch” should be for failure handling • A break statement should only be used inside a switch statement. • Break statements should be avoided. • For example: • /* ... */ • for (...) • { • /* ... */ • if (...) • { • /* ... */ • break; • } • /* ... */ • } /* break jumps to here */ • /* ... */ N.K.Das, PIRD, IGCAR

13. Thanks N.K.Das, PIRD, IGCAR