With decades of experience writing and supporting software for many different customers, we have seen many variations of coding styles and guidelines, and with them, many different variations of comment styles.
While each company has their own preferred method of including comments in software, and details regarding the comment delimiters, line spacing, etc., a general outline of the approach we have seen work best, at least for C and C++ based software, is as follows:
- Each code file (i.e. .c, .cpp, etc. file ) in a source tree should have a corresponding .h file in which the ‘public’ or ‘user visible’ function prototype definitions and public type and constant definitions are defined. A developer using functions coded in a .c or .cpp file should only have to look at the corresponding .h file in order to use the code in the .c file.
math_functions.h math_functions.c
- A ‘header’ comment including copyright information and a very short description of the purpose of a file should appear at the top of every file in the source code. This includes both header files and code files.
/* Copyright 2016 Acme Inc. All Rights Reserved math_functions.h - math library routines */
- Comments describing the API (Application Programming Interface) for a ‘public’ function should be with the function prototype definition in the applicable header (.h) file.
/* Copyright 2016 Acme Inc. All Rights Reserved math_functions.h - math library routines */ /* 32 bit divide function parameters: divisor - 32 bit divisor dividend - 32 bit dividend returns: dividend / divisor */ long divide_32(long dividend, long divisor); /* fibonacci sequence parameters: num - integer number returns: value of fibonacci sequence for n = num. fib(0) = 0, fib(1) = 1, fib(2) = 1, fib(3) = 2, fib(4) = 3 etc. */ int fib(int num); /* ... other functions in math.h & math.c */
- Comments should not be present at the start of the code implementation for individual functions in the .c file if those functions are ‘public’ and part of the module’s API. In other words, if the function’s API comments are in a header file, they should not be repeated in the .c file.
/* Copyright 2016 Acme Inc. All Rights Reserved math_functions.c - math library routines */ long divide_32(long dividend, long divisor) { return dividend / divisor; } int fib(int num) { int val; if (num == 0 ) val = 0; else if (num == 1) val = 1; else { int f0 = 0; int f1 = 1; for (int i = 0; i <= num-2; i++ ) { val = f0 + f1; f0 = f1; f1 = val; } return val; }
The objective of commenting code is to make it easier for someone to support and understand the code. To this end, the less text there is to look through, the better. In one example we ran into, the coding standard had some verbiage to the effect that comments should be used ‘copiously’. This led a novice programmer to generate thousands of lines of code like this:
// declare variable i int i; // clear the initial value of i i = 0; // use i to loop 10 times for ( i = 0; i < 10; i++ ) { j = j + 1; // increment j }
There was a separate comment line for practically every line of C code. We feel the following, with no comments, is actually more readable, much quicker to scan through, and is easily understood:
for (int i = 0; i < 10; i++) { j = j + 1; }
Programmers using languages other than C/C++, for example Python, other ‘scripting’ languages like Perl and PHP, or some types of microcode, can all benefit from picking up on the spirit of the above ideas.
We hope this small note provides some useful guidelines for making your code more supportable.
Please contact us for help with your project