Source code organization

Back to Coding Standards

• Header files always have the file extension .h.
• The file name has to be unique within the whole project (not only the subdirectory).
• Usually, a header file should only contain the declaration of a single class; then the file name is the name of this class (plus extension).
• A header file may contain several classes if it declares a main class with a few auxiliary classes; in this case, the file name is the name of the main class (plus extension), e.g., List.h declares the List class with their iterator classes.
• A header file may contain several class or function declarations if these are highly related and should not be spread among several header files; in this case the file name should describe the common topic, e.g., graph_generators.h.
• Inline function definitions and definitions of (member) functions with a template argument are contained in the header file.

Each header file uses the following mechanism for preventing multiple inclusion:

#ifdef _MSC_VER
#pragma once
#endif
 
#ifndef OGDF_FILENAME_H
#define OGDF_FILENAME_H
 
...
 
#endif

where FILENAME is the base name of the file with all letters in upper case. The pre-processor directive #pragma once tells Visual C++ that the file is included only once and hence optimizes compilation times. Since it is Microsoft specific, it is guarded by #ifdef _MSC_VER. The stuff below is the old-school C++ way to avoid multiple inclusion that works with every C++ compiler.

• Implementation files always have the file extension .cpp.
• The file name has to be unique within the whole project (not only the subdirectory).
• Usually, an implementation files contains the implementation code of a single class; then the file name is the name of this class (plus extension).
• An implementation file may contain the code of several related classes and functions; in this case, the file name should be lower-case and should reflect the common topic, e.g., sugiyama.cpp.
• If the implementation of a particular class is very large (e.g., involves a complicated algorithm), it should be distributed over several implementation files, each implementing a well-defined sub-part.

Header files are placed in subdirectories of the directory ogdf and implementation files in subdirectories of the directory src, both contained in the OGDF root directory. The respective subdirectories follow a common scheme, we have:

• basic: all core functionality and basic data types.
• fileformats: graph loaders and file parsers.
• module: module base classes.

• augmentation: augmentation algorithm, mainly planar augmentation.
• decomposition: data structures for graph decomposition.
• graphalg: graph algorithms.
• packing: packing algorithms, in particular 2D-packing algorithms for the layout of connected components.
• planarity: data structures and algorithms for planarity testing and embedding, as well as planarization.

• cluster: clustered graphs and algorithms for clustered graphs.
• energybased: energy-based graph layout algorithms.
• layered: layer-based graph drawing algorithms.
• misclayout: diverse graph drawing algorithms that does not fit into one of the specific categories.
• orthogonal: algorithms and data structures for orthogonal graph drawing.
• planarlayout: planar layout algorithms (except for orthogonal layout).
• simultaneous: simultaneous graph drawing.
• tree: tree layout algorithms.
• upward: algorithms and data structures for (layer-free) upward graph drawing.
• labeling: graph labeling algorithms.

• external: interaction with external libraries, e.g., Coin.
• internal: (header files only) contains declarations that are required for header files but contain only internal functionality not relevant for the user.
• legacy: legacy code that is no longer part of the public release, but should be preserved; all this code must be in the namespace ogdf_legacy.
• lpsolver: OGDF's LP-solver (not part of the public release).