home.md

+Here is an example class that uses the ORIGEN naming convention.
 ```cpp
 namespace scale{
 
@@ -5,11 +6,11 @@ bool isSameBuffer(int* a, int* b){
     return a==b;
 }
 
-class Reader_Int{
+class BufferedReader_Int{
   private:
       int *b_buffer;
-      Reader() : b_buffer(new int()){}
-      ~Reader(){ delete b_buffer; }
+      BufferedReader() : b_buffer(new int()){}
+      ~BufferedReader(){ delete b_buffer; }
   public:
     void read(std::istream& is){
         is >> *b_buffer;
@@ -24,7 +25,7 @@ class Reader_Int{
 };
 }//end namespace scale
 int main(){
-    scale::Reader_Int reader;
+    scale::BufferedReader_Int reader;
     {
         std::ofstream ofs("file.txt");
         ofs << 7;
@@ -34,15 +35,17 @@ int main(){
     std::cout << *reader.buffer() << std::endl;
     return 0;
 }
-//Note this could be generalized to a templated Reader.
+```
+A strict camel case would have this reader be named ``BufferedIntReader`` or ``IntBufferedReader``, but this has some shortcomings. First, by pushing the "variant" part of the naming to the end, we get good, automatic sorting of the classes. This helps in editors and in documentation that lexically similar implies logically similar.  Now, imagine what happens when we get around to templating the BufferedReader.  
+```c++
 template <typename T>
-class Reader {
+class BufferedReader {
 //contents
 };
-//Then it is natural to use these typedefs.
-typedef Reader<int> Reader_Int;
-typedef Reader<double> Reader_Dbl;
-//This is preferable to defining IntReader, DoubleReader, etc., because Reader_Dbl, Reader_Int will be automatically sorted to show their relationship.
+typedef BufferedReader<int> BufferedReader_Int;
+typedef BufferedReader<double> BufferedReader_Dbl;
+```
+The typedefs mirror the templating syntax and can always be made fairly straightforwardly, as opposed to trying to figure out where to put the "Int", i.e. is it "BufferedIntReader" or "IntBufferedReader". With multiple template parameters it gets even more hairy, but the _ syntax, simply leads to ``typedef std::map<std::string,int> Map_Str_Int``. 
 ```
 Basic ways of distinguishing word boundaries with ``<LWORD>=[a-z]+`` and ``<UWORD>=[A-Z][a-z]+``
 * Camel case
@@ -85,9 +88,9 @@ With those definitions in mind, let's define a set of word conventions. The main
     * e.g. ``scale::io``,``origen::detail``,`` origen::tst``,``origen::example``,``ornl::gtest::example``
 6. typedef or variant class name (``CLASSTYPE``)
     * description: "CamelCase_variant" used for classes which are logically very similar, perhaps typedefed templated classes
-    * regex: ``<CLASSTYPE>``=``<CLASS>_(<CLASS>|<LWORD>)``
+    * 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``, ``Vec_Dbl``, ``Vec_Str``
+    * 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``)
     * description: in style of the STL library, should be templated
     * regex: ``<LIBFUNC>``=``<SNAKE>``