home.md

 # ORIGEN naming convention
 
-The ORIGEN naming convention is basically ``CamelCase`` for classes and ``snake_case`` for everything else. There are some notable exceptions and these are basically to allow the programmer to more easily differentiate between some functions. For example, for functions which are not bound to any class  
+The ORIGEN naming convention is basically ``CamelCase`` for classes and ``snake_case`` for everything else. There are some notable exceptions and these are basically to allow the programmer to more easily differentiate between some functions. For example, for functions which are not bound to any class use ``lazyCamelCase``. This is both so they can be differentiated from class methods, and because they tend to have long descriptive names and avoiding the underscores saves characters. There is another consideration because ORIGEN provides both C++ and Fortran APIs. Fortran is a case insensitive language, and current documentation systems (Doxygen and Sphinx) render all names in lower case. Thus it is beneficial to use ``snake_case`` for the most common language elements, and so variables and class methods are ``snake_case``. In both systems, with an extra line of documentation, a class's main page can show the class name in ``CamelCase``, however all hyperlinks to the class are still rendered in lower case.
 
 ## C++ example class
 
@@ -55,7 +55,7 @@ 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``. 
 
-### Word Boundaries
+## Defining Word Boundaries
 
 Basic ways of distinguishing word boundaries with ``<LWORD>=[a-z]+`` and ``<UWORD>=[A-Z][a-z]+``
 * Camel case
@@ -107,3 +107,21 @@ With those definitions in mind, let's define a set of word conventions. The main
     * description: in style of the STL library, should be templated
     * regex: ``<LIBFUNC>``=``<SNAKE>`` 
 
+## Fortran definitions
+The goal for Fortran is to as closely as possible mirror the C++ rules. The only real difficulty is the lack of namespaces in Fortran. The rule is that namespaces are appended to the front of the class name.
+
+```fortran
+module scale_BufferedReader_Int_M
+type scale_BufferedReader_Int
+end type
+contains
+! -- contents --
+end module
+program main
+use scale_BufferedReader_Int_M
+type(scale_BufferedReader_Int) :: reader
+integer :: buffer
+end program
+```
+
+Fortran cannot handle constness or mirror returning complex objects from functions like C++. For this reason, accessors of complex types in Fortran should bind to C++ functions ``void get_var(Var*&) const`` and ``void set_var(const Var*) `` with the understanding that there will be a *copy*. For performance sensitive applications, ``void getptr_var(Var* &)`` and ``void manageptr_var(Var*&)`` knowing that changing any values in the variable received with ``getptr`` results in undefined behavior *and* the variable passed in ``manageptr_var`` no longer belongs to you and will be returned as ``C_NULL``.