Go forward to OK.
Go backward to General.
Go up to Top.

GNU C++ library stylistic conventions
*************************************

   * C++ source files have file extension `.cc'. Both C-compatibility
     header files and class declaration files have extension `.h'.

   * C++ class names begin with capital letters, except for `istream'
     and `ostream', for AT&T C++ compatibility. Multi-word class names
     capitalize each word, with no underscore separation.

   * Include files that define C++ classes begin with capital letters
     (as do the names of the classes themselves).  `stream.h' is
     uncapitalized for AT&T C++ compatibility.

   * Include files that supply function prototypes for other C
     functions (system calls and libraries) are all lower case.

   * All include files define a preprocessor variable _X_h, where X is
     the name of the file, and conditionally compile only if this has
     not been already defined. The `#pragma once' facility is also used
     to avoid re-inclusion.

   * Structures and objects that must be publicly defined, but are not
     intended for public use have names beginning with an underscore.
     (for example, the `_Srep' struct, which is used only by the String
     and SubString classes.)

   * The underscore is used to separate components of long function
     names,
     e.g., `set_File_exception_handler()'.

   * When a function could be usefully defined either as a member or a
     friend, it is generally a member if it modifies and/or returns
     itself, else it is a friend. There are cases where naturalness of
     expression wins out over this rule.

   * Class declaration files are formatted so that it is easy to
     quickly check them to determine function names, parameters, and so
     on. Because of the different kinds of things that may appear in
     class declarations, there is no perfect way to do this. Any
     suggestions on developing a common class declaration formatting
     style are welcome.

   * All classes use the same simple error (exception) handling
     strategy.  Almost every class has a member function named
     `error(char* msg)' that invokes an associated error handler
     function via a pointer to that function, so that the error
     handling function may be reset by programmers. By default nearly
     all call `*lib_error_handler', which prints the message and then
     aborts execution. This system is subject to change. In general,
     errors are assumed to be non-recoverable: Library classes do not
     include code that allows graceful continuation after exceptions.