12. Indentation

Leading line intentions are always handled with TAB characters (not spaces), and any subsequent indentions on the same line (e.g. columnar tables in comments or aligning a set of ‘=’ characters in a sequence of assignments) are always handled with SPACES (not tab characters). Set your editor (and/or IDE) so that the tab indents 4 spaces in source code. This enables anyone reading the code, regardless of their viewer’s tab settings, to always be able to see the code intentions as they were intended. This is important for readability.

When working with a team of programmers that edit one anothers’ code, the entire team needs to have their editors and/or IDEs set up the same way. One or more .editorconfig files in the project can sometimes be very useful for this purpose if the commonly-used EDI editor honors it. See Senior Policy for details.

Function names and global variable names are generally indented to column 16. This helps things line up, both in variable and function blocks, and is not only more visually pleasing, but more importantly, makes it FASTER and EASIER to understand, thus accomplishing the goals for Coding Standards in the first place.

This reduces editing time (and even makes it automate-able) to create lists of exported (non-static) function prototypes and extern variable declarations. This also greatly increases readability of the .H file as well as reduces required editing time to create it: the list of prototypes can be created by copy/pasting all the non-static function definitions and then replacing the actual code blocks with a ;. This not only makes it fast, but eliminates the potential for human typing errors.

So function name lines looking like this:

void           S1D13517_SetAddress(register BYTE aui8Register, register UINT32 aui32SdramAddr) {
/*             ^ <-- column 16 */

and function prototypes in the .H file looking like this:

void           S1D13517_SetAddress(register BYTE aui8Register, register UINT32 aui32SdramAddr);
/*             ^ <-- column 16 */

and global variable name lines look like this:

uint32_t       gui32BufferSizeInBytes;
/*             ^ <-- column 16 */

and the corresponding declaration in the .H file:

extern uint32_t       gui32BufferSizeInBytes;
/*                    ^ <-- column 23 (16 + len('extern')) */

This looks nice and tends to keep things reasonably readable.