|What are the coding conventions for Xerces-C++?
As with any coding effort, there are always arguments over what coding conventions to use. Everyone thinks
that they have the best style which leads to the entire source tree looking different. This causes consternation
as well as eye fatigue on subsequent developers that need to maintain the code. Therefore, we are going to
make an attempt at defining some basic coding conventions for Xerces-C++. When committing files or providing
patches please keep them in mind:
- All classes should have a constructor, destructor, assignment operator and copy constructor to
avoid compiler generated default versions of these.
If you add a catch(...) block be sure to add the following block
- If a class contains only static methods, only a private constructor is required.
- If a class contains any virtual methods, the destructor should be virtual.
- If a class has a public or protected constructor, it should declare private assignment operator
and copy constructor which are not implemented (unless of course you need either of these).
so the OutOfMemory condition does not get absorbed.
If you change the serialization format (by adding something to be serialized or removing something that
was serialized) increment the XERCES_GRAMMAR_SERIALIZATION_LEVEL constant in XercesVersion.hpp.
If a class allocates memory or is instantiated with new then it should inherit from XMemory.
Use a tab size of 4 and insert them as spaces instead of keeping tabs.
The code is written to be platform independent. Platform specific code should only be in the
util/FileManagers, util/MutexManagers, util/Transcoders, util/MsgLoaders, and util/NetAccessors directories.
The header file name and the source file name should both be named corresponding to the primary
class they contain. For example class StringPool should be in the header file StringPool.hpp and in
the source file StringPool.cpp.
In general, code should be documented with comments. Use Doxygen tags to describe methods.
The naming convention for enumerations should be chosen to be unique and descriptive
(i.e. INVALID or UNKNOWN) to avoid colliding with predefined macros in other
products. The current style of using ALL CAP enums should be phased out with
Mixed Case instead, except for names specified in standards (for example, TEXT_NODE
should not be converted to mixed case for standards compliance).