Embedded Programming

rules
By

Dinesh
Why there should be rules?
• No code is perfect, it has its fair share of bugs knowingly or
unknowingly placed by the programmer.
• To find a bug is a tiresome process, and if the code is messy enough
its equivalent of searching a needle in haystack.
• That’s where rules chip in. Rules helps to avoid the common mistakes
done by the programmer, and write a readable code.
• A programmer is not an owner of the code, the company or the client
under whom he works are the owners, so he/she should keep that in
mind while writing a code.
Indentations ,Spacing and brackets
• A code will be readable only if it looks good enough.
• Each code should be indented well with appropriate spacing.
• Brackets are crucial and each control flow statements should use brackets.
Example:
if(a<5) print(“ a is less than 5”)
else print(“a is greater than 5”)
The above statements are legal, but it is best practice to follow curly
braces while writing.
This is crucial because, when nearby code is changed or commented out it the
condition might also disappear and may branch out new errors.
Example
if (a<5)
{
print(“a is less than 5”)
}
else
{
print(“a is greater than 5”)
}
As you can see the above more readable and straight-forward and readable!
Nested-if statements
While using nested-if statements proper indentation should be given
Example:
if(a > 5)
{
if( b > 5)
{
print(“both a and b are greater than 5”)
}
}
Parentheses
• Use parentheses to ensure proper execution of code
Example:
if (( depth_in_cm > 0 ) && ( depth_in_cm < MAX_DEPTH ))
{
depth_in_ft = convert_depth_to_ft(depth_in_cm);
}
Casts
• Casting is important, it ensures proper behavior across range of
possible values on the right side
Example
uint16_t sample = adc_read(ADC_CHANNEL_1);
result = abs((int) sample); // WARNING: 32-bit int assumed.
In the above example, sample is an unsigned_16_bit_int meaning it
can hold a larger range of positive values.
Casting it to int will lower the range of values and might cause
overflow.
Keywords to Avoid
• The auto keyword shall not be used.
• The register keyword shall not be used.
• It is a preferred practice to avoid goto keyword
• It is a preferred practice to avoid continue keyword.
Keywords to frequent
• Static:
Used when functions/variables need not be visible outside modules
in which they are declared.
• Const:
i. To declare variables that should not be changed after initialization
ii. To define call by reference function parameters that should not be
defined.
iii. To define fields in struct/union that should not be modified
iv. Alternative for #define for numerical constants
• Volatile:
i. To access a global variable inside an interrupt service routine.
ii. To declare a global variable that is accessible by two or more
threads.
iii. To declare a pointer to a memory mapped I/O peripheral.
iv. To declare a delay loop counter.
Comment Rules
• Single line comments are acceptable (/*……*/)
• Should not contain preprocessor tokens (/*,//,/)
• No code should be commented out!
i. Either it can be disabled by #if, #endif
ii. Any line/code that increased debug information shall be
surrounded by (#ifndef DEBUG #endif)
• Each comment should be grammatically correct and appropriate.
• Avoid writing obvious comments
eg: number<<2 /*the number is left shifted by 2*/
No need to write comments for lines like these
• If an algorithm is referred from a particular document, then reference
should be pointed out in the comment block
• All assumptions made should be indicated clearly
• Use capitalized letters to indicate important issues:
eg: ‘WARNING’, ‘NOTE:’, ‘TODO:’
White space rules
• Each keyword should be preceded/succeeded by a space.(if, while,
for,switch)
• Each assignment and binary operators should be preceded/succeeded
by a space.
(=>, <=,==,!=,&&)
• Pointer shall be written with white space on either side of it(* and &)
• Expression inside parenthesis shall not have spaces.
Header Files
• There shall always be one header for each source file and they shall
have same root name.
• Don’t declare variables in header files. Declare the variable in the .c
file. Call the variables in other files using extern.
Fixed Width Integers
• Always declare integers as fixed-width
eg:
int8_t or uint8_t, int16_t or uint16_t
Signed and Unsigned integers

• Bit fields shall not be defined within signed integer types

• No bitwise operations should be done on signed integer
• Do not combine signed and unsigned integer together
uint16_t unsigned_a = 6u;
int16_t signed_b = -9;
if (unsigned_a + signed_b < 4)
{
// Execution of this block appears reliably logical, as -9 + 6 is -3
...
}
// ... but compilers with 16-bit int may legally perform (0xFFFF – 9) + 6.
Floating point
• Avoid using floating point constants. Fixed point math may be an
alternative.
• Use the C99 type names float32_t, float64_t, and float128_t.
ii. Append an ‘f’ to all single-precision constants (e.g., pi = 3.141592f).
iii. Ensure that the compiler supports double precision, if your math
depends on it.
iv. Never test for equality or inequality of floating point values.
v. Always invoke the isfinite() macro to check that prior calculations
have resulted in neither INFINITY nor NAN