Identifier names

Identifier names are used to name functions, variables, types (typedefs, structs, unions, enums), type members, macros, etc.
There are of course many styles of choosing identifier names. One important rule is to be consequent about naming.
The smaller the scope of a name, the less important a good choice of the name is. E.g. it is less important to chose a speaking and somewhat systematic name for a small scope index variable8 than it is for an exported library function.
Using capable development environments (the ones that let you jump to definition and declaration of a function) makes it less important to express type and package membership in a function name.
The aspect of which natural language to use for names has already been covered.

Name styles
There are several methods to get readable names:
• use of underscore characters9 (e.g. get_name)
• use of upper case initials (e.g. GetName)
• use of natural language context (e.g. getname)
Some software packages use a kind of type prefix (e.g. uppercase initial for functions and lowercase type indicating initials for variables). E.g.: sz (zero terminated string), n/i (integer), p (pointer), psz (zero terminated string pointer), f/b (flag, boolean), c (character), fp (file pointer), pfn (function pointer), h (handle), w (word, unsigned int), fd (file descriptor).
Package prefixes (e.g. t_ in the TLI API) will be mentioned below.

Name restrictions
• Case-insensitive linkers will have problems with external identifiers that differ only in case.
• There is a restriction on how many characters of an external identifier name a linker must support.10
• Identifiers that begin on _ or __ are reserved for the C implementation and may not be used.
• Some additional prefixes are reserved and may not be used: str (string functions, string.h), E (operating system error numbers, errno.h).

Namespace
A program's identifier namespace isn't partitioned in the C programming language, unlike in Lisp, Java11 or C++ 3rd Ed. [BS,1997].
Libraries tend to include package membership information (e.g. t_open, t_bind, etc. of the TLI network interface library) to omit name collisions12.
However, it will be impossible to find small unique package prefixes13.

File names
The naming of source files, header files, libraries, directories and projects is not a C programming language issue. However, some considerations are worthwhile.
Filesystems (in which the source files are stored) may or may not be case-sensitive14. In the later case, one cannot save e.g. Main.c and main.c in the same directory.
The recommended character set for file names, valid on most systems, is rather small: letters, digits, .-_ and maybe ~@+%,, reasons being
• some characters are used by filesystems (/\:;)
• some characters have the meaning of quotes (in scripts or shells) ("'\`)
• some characters are delimiters in shells (blank, tab)
• some characters are meta characters in shells (<>()[]{}$=`;&|^*?#!)
• some characters depend on a non-ASCII character set
A package prefix is considerable with header files to avoid namespace problems (a bad example being external header files named error.h or types.h).