Coding style: snake_case.

[simgrid.git] / README.coding

diff --git a/README.coding b/README.coding
index c0325a7..e3eed40 100644 (file)
--- a/README.coding
+++ b/README.coding
@@ -20,27 +20,61 @@
 
 SimGrid4 will follow the these rules:
 
 
 SimGrid4 will follow the these rules:
 

-  - filenames are unique in the whole project 
+  - filenames are unique in the whole project

     (because of a bug in Sonar coverage computation)
   C++
   - fields, methods and variables are in snake_case()
     (because of a bug in Sonar coverage computation)
   C++
   - fields, methods and variables are in snake_case()

-  - Classes and Enum are in CamelCase
-  - filenames: Class.cpp and Class.hpp
+  - Classes and Enum names are in UpperCamelCase
+  - Enum values are in UPPER_SNAKE_CASE (as constants)
+  - public filenames: api_Class.cpp and api/Class.hpp.
+    - Example: src/s4u/s4u_ConditionVariable.cpp and
+               include/simgrid/s4u/ConditionVariable.hpp
+    - If you prefer api_class.cpp, that's OK, too. Breath and relax.
+      Example: src/s4u/s4u_actor.cpp and include/simgrid/s4u/Actor.hpp
+  - internal/kernel filenames: Class.cpp and Class.hpp
+    - Example: src/kernel/activity/Activity.cpp
+               include/simgrid/activity/Activity.hpp

   C
   C

+  - Field getters are named sg_object_get_field() e.g. sg_link_get_name()
+    Field setters are named sg_object_set_field() e.g. sg_link_set_data()

   - variables and functions are in snake_case()
   - variables and functions are in snake_case()

-  - typedefs do not hide the pointers, ie * must be explicit
-    char * sg_host_get_name(sg_host_t * host);
-  
+  - typedefs do not hide the pointers, i.e. * must be explicit
+    char* sg_host_get_name(sg_host_t* host);
+

 
 This is different from the old convention (described below), that
 should not be used in S4U and its bindings, nor in the kernel.
 
 
 This is different from the old convention (described below), that
 should not be used in S4U and its bindings, nor in the kernel.
 

+**
+** Commenting the source: doxygen
+**
+****************************************************
+
+The global structure of the documentation is in doc/modules.doc
+
+The structure of each module (xbt, msg, etc) is in doc/module-<module>.doc
+
+The structure of a module is in its public header. This way, you're sure to
+see all the public interface (and only it). The different parts of the
+interface are grouped using the @name construct, even if it's buggy. Since
+parts often get reordered, it's better to add numbers to the parts (so that
+users can see the intended order).
+
+The documentation of each type and macro are also in the public header since
+this is were they live.
+
+The documentation of each function must be in the C++ file were it lives.
+
+Any public element (function, type and macro) must have a @brief part.
+
+We use @ as a command marker, not \ (so, use @brief not \brief)
+

 **
 ** OLD Type naming standard in SimGrid3
 **
 *****************************************************
 
 **
 ** OLD Type naming standard in SimGrid3
 **
 *****************************************************
 

-SimGrid3 legacy interfaces (ie, MSG and SimDag) are following these rules:
+SimGrid3 legacy interface (ie, MSG) is following these rules:

 
   - ???_t is a valid type (built with typedef)
   - s_toto_t is a structure (access to fields with .)
 
   - ???_t is a valid type (built with typedef)
   - s_toto_t is a structure (access to fields with .)


@@ -60,31 +94,6 @@ Example:
 Moreover, only toto_t (and e_toto_t) are public. The rest (mainly s_toto_t)
 is private.
 
 Moreover, only toto_t (and e_toto_t) are public. The rest (mainly s_toto_t)
 is private.
 

-If you see any part of the code not following this convention, this is a
-bug. Please report it (or fix it yourself if you can).
-
-**
-** Commenting the source: doxygen
-**
-****************************************************
-
-The global structure of the documentation is in doc/modules.doc
-
-The structure of each module (xbt, msg, etc) is in doc/module-<module>.doc
-
-The structure of a module is in its public header. This way, you're sure to
-see all the public interface (and only it). The different parts of the
-interface are grouped using the @name construct, even if it's buggy. Since
-parts often get reordered, it's better to add numbers to the parts (so that
-users can see the intended order).
-
-The documentation of each type and macro are also in the public header since
-this is were they live.
-
-The documentation of each function must be in the C file were it lives.
-
-Any public element (function, type and macro) must have a @brief part.
-

 
 *
 * SimGrid Hacker Survival Guide (FIXME: should be betterly placed)
 
 *
 * SimGrid Hacker Survival Guide (FIXME: should be betterly placed)