+ teshsuite/ -> The more test the better. Put in there any strange test
+ doing things that the users are not supposed to do,
+ just to see if our framework is robust to incorrect and
+ unusual behaviors. All tests written in this section
+ should leverage our tesh(1) utility.
+
+**
+** NEW type naming standard in SimGrid4
+**
+*****************************************************
+
+SimGrid4 will follow the these rules:
+
+ - filenames are unique in the whole project
+ (because of a bug in Sonar coverage computation)
+ C++
+ - fields, methods and variables are in snake_case()
+ - 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
+ - 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()
+ - 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.
+
+**
+** 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)
+