5.4 Naming Variables, Functions, and Files

The names of global variables and functions in a program serve as
comments of a sort. So don’t choose terse names—instead, look for
names that give useful information about the meaning of the variable or
function. In a GNU program, names should be English, like other
comments.

Local variable names can be shorter, because they are used only within
one context, where (presumably) comments explain their purpose.

Try to limit your use of abbreviations in symbol names. It is ok to
make a few abbreviations, explain what they mean, and then use them
frequently, but don’t use lots of obscure abbreviations.

Please use underscores to separate words in a name, so that the Emacs
word commands can be useful within them. Stick to lower case; reserve
upper case for macros and enum constants, and for name-prefixes
that follow a uniform convention.

For example, you should use names like ignore_space_change_flag;
don’t use names like iCantReadThis.

Variables that indicate whether command-line options have been
specified should be named after the meaning of the option, not after
the option-letter. A comment should state both the exact meaning of
the option and its letter. For example,

When you want to define names with constant integer values, use
enum rather than ‘#define’. GDB knows about enumeration
constants.

You might want to make sure that none of the file names would conflict
if the files were loaded onto an MS-DOS file system which shortens the
names. You can use the program doschk to test for this.

Some GNU programs were designed to limit themselves to file names of 14
characters or less, to avoid file name conflicts if they are read into
older System V systems. Please preserve this feature in the existing
GNU programs that have it, but there is no need to do this in new GNU
programs. doschk also reports file names longer than 14
characters.