home.md

@@ -55,26 +55,26 @@ Basic ways of distinguishing word boundaries with ``<LWORD>=[a-z]+`` and ``<UWOR
 
 With those definitions in mind, let's define a set of word conventions. The main technical goal is to use the different ways of writing words to distinguish between as many parts of the language as possible. 
 
-1. variables (``VAR``)
+1.``VAR`` variables 
     * description: use underscores and all lower case
     * regex: ``<VAR>``=``<SNAKE>``
 2. classes 
-    1. class name (``CLASS``)
+    1. ``CLASS`` class name 
         * description: standard CamelCase used for most classes, avoid abbreviations, for acronyms capitalize first, e.g. ORIGEN-->Origen or IO-->Io, MG-->Mg, CE-->Ce
         * regex: ``<CLASS>``=``<UCAMEL>``
         * e.g. ``NuclideSet``, ``Nexus``, ``LibraryIo``, ``CeResourceFile``
-    2. class methods (``CLASSMETHOD``)
+    2. ``CLASSMETHOD``class method
         * description: use snake case
         * regex: ``<CLASSMETHOD>``=``<SNAKE>``
         * convention: accessor method "getters" have form ``Var var() const`` while "setters" have ``void set_var(Var)``.
-    3. class member variables (``CLASSVAR``)
+    3. ``CLASSVAR`` class member variables
         * description: use a prefix ``b_`` for the base class and ``d_`` for the derived class
         * regex: ``<CLASSVAR>``=``[bd]_<SNAKE>``
-3. specific-use free functions (``FREEFUNC``)
+3. ``FREEFUNC``specific-use free functions 
     * description: functions not bound to any particular class use lazyCamelCase (does not include static functions)
     * regex: ``<FREEFUNC>``=``<LCAMEL>``
     * conventions: try to use a verb as the first word, e.g. countListElements instead of listElementCount
-4. namespace component (``NAME``)
+4. ``NAME`` namespace component 
     * description: simple, one-word lower case
     * regex: ``<NAME>``=``<LWORD>``, !``detail``,!``tst``,!``example``
     * eg: ``scale``, ``origen``, ``polaris``, ``nemesis``
@@ -82,16 +82,16 @@ With those definitions in mind, let's define a set of word conventions. The main
         * use ``detail`` for implementation details
         * use ``tst`` for unit tests (possibly not pretty)
         * use ``example`` for an example usage (should be pretty)
-5.  fully qualified namespace (``NAMESPACE``)
+5.  ``NAMESPACE`` fully qualified namespace 
     * description: a complete namespace which should have one or two main parts, if two, the standard is ``organization::component``. Special final namespaces can be used to hide implementation details, testing code, and group example usage.
     * regex: ``<NAME>(::<NAME>)?(::detail|::tst|::example)?``
     * e.g. ``scale::io``,``origen::detail``,`` origen::tst``,``origen::example``,``ornl::gtest::example``
-6. typedef or variant class name (``CLASSTYPE``)
+6. ``CLASSTYPE`` typedef or variant class name 
     * description: "CamelCase_variant" used for classes which are logically very similar, perhaps typedefed templated classes
     * regex: ``<CLASSTYPE>``=``<CLASS>((_<CLASS>)+|_<LWORD>)``
     * conventions: for STL typedefs, use ``Vec`` for vector, ``Map`` for map, ``Set`` for set, ``Dbl`` for double, ``Int`` for int, ``Str`` for string, ``Long`` for long (>=64-bit), ``Sze`` for size_t, ``Bool`` for bool.
     * e.g.: ``LibraryIo_bof``, ``LibraryIo_s61`` which define a variant by different file types, and ``Vec_Dbl``, ``Vec_Str``, ``Map_Str_Int``, which define "typedef-style" variants where the first class is the template class and the remaining are the template parameters.
-7. general-use free functions (``LIBFUNC``)
+7. ``LIBFUNC`` general-use free functions 
     * description: in style of the STL library, should be templated
     * regex: ``<LIBFUNC>``=``<SNAKE>``