Changes between Version 5 and Version 6 of Coding_Conventions

Timestamp:

Jul 22, 2010, 11:45:50 PM (14 years ago)

Author:

Ivan Nikolaev

Comment:

--

Coding_Conventions

@@ -11 +11 @@
  * All source files (.cpp, .h) must start with the following header, before any other content:
 {{{
-/* Copyright (C) 2009 Wildfire Games.
+/* Copyright (C) 2010 Wildfire Games.
  * This file is part of 0 A.D.
  *
@@ -28 +28 @@
  */
 }}}
-replacing `2009` with the year that the file was last updated.
+replacing `2010` with the year that the file was last updated.
 
  * Wrap header files in include guards, using the name `INCLUDED_`''filename'', e.g. the file `Foo.h` should say:
@@ -61 +61 @@
  * Class names are !CamelCase and prefixed with `C`, e.g. `CGameObject`. Member functions are !CamelCase, e.g. `CGameObject::SetModifiedFlag(...)`. Member variables are !CamelCase prefixed with `m_`, e.g. `CGameObject::m_ModifiedFlag`. Files are named `GameObject.cpp`, `GameObject.h`, usually with one major class per file (possibly with some other support classes in the same files).
 
- * Use [http://www.cppdoc.com/ CppDoc] comments, e.g.
+ * Use [http://www.doxygen.org/ Doxygen] comments, e.g.
 {{{
 class CExampleObject
@@ -205 +205 @@
     *
     * (Notes regarding usage and possible problems etc...)
-    **/
-}}}
-For single-line comments, `///` can be used as well. The comment text is inserted into the documentation, and can additionally be formatted by certain tags (e.g. `@param description` for function parameters). For more details, see the !CppDoc documentation.
+    */
+}}}
+For single-line comments, `///` can be used as well. The comment text is inserted into the documentation, and can additionally be formatted by certain tags (e.g. `@param description` for function parameters). For more details, see the !Doxygen documentation.
 
 Each method of a class should be documented as well and here is the suggested method of documenting a member function (continuing with `CExample`):
@@ -221 +221 @@
         * documenting a member function.
         * @param dummy A dummy parameter.
-        **/
+        */
        void ShowExample(int dummy); 
    
@@ -250 +250 @@
     * Description : CExample interface file.
     * =========================================================================
-    **/
+    */
    
    /*
@@ -268 +268 @@
     * provide an example of documenting a class.
     * Notes regarding usage and possible problems etc...
-    **/
+    */
    class CExample
    {
@@ -279 +279 @@
         * documenting a member function.
         * @param dummy A dummy parameter.
-        **/
+        */
        void ShowExample(int dummy); 
    
@@ -304 +304 @@
 == Singletons ==
 
-Much debate regarding the use of global variables has been generated over the years so we will not re-enter that discussion. The Singleton design pattern does provide many benefits over that of a pure global variable.
-
-We will make use of the Automatic Singleton Utility as described by Scott Bilas in article 1.3 of the "Game Programming Gems", volume I, "An Automatic Singleton Utility".
+After a long debate, it was decided to not use Singletons and to prefer global variables to them. All global variables have to be prefixed with 'g_' and their initialisation should be as clear and transparent as possible. So, if there's a class like CGame, which needs to exist in a single instance, there will be a pointer declaration called 'g_Game' in Game.h, and all initialisation details will be "hidden" in Game.cpp. There are still some Singletons in the current codebase, but they will be reimplemented and the new code should be written using globals.
 
 == Strings ==