EasyRPG Wiki

User Tools

Site Tools

You are here: EasyRPG wiki » Development documentation » Player » Code Formatting Conventions
development:player:code-formatting-conventions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
development:player:code-formatting-conventions [2011/09/25 16:47] – fdelapenadevelopment:player:code-formatting-conventions [2015/10/03 09:54] (current) – external edit 127.0.0.1
Line 15: Line 15:
 Braces in your code should look like the following example: Braces in your code should look like the following example:
  
-<code>for (int i = 0; i < t; i++) {+<code cpp>for (int i = 0; i < t; i++) {
     [...]     [...]
 } }
Line 34: Line 34:
  
 ==Conventional operators surrounded by a space character== ==Conventional operators surrounded by a space character==
-<code>a = (b + c) * d;</code>+<code cpp>a = (b + c) * d;</code>
  
 ==C++ reserved words separated from opening parentheses by a white space== ==C++ reserved words separated from opening parentheses by a white space==
-<code>while (true) {</code>+<code cpp>while (true) {</code>
  
 ==Commas followed by a white space== ==Commas followed by a white space==
-<code>SomeFunction(a, b, c);</code> +<code cpp>SomeFunction(a, b, c);</code> 
-<code>int d, e;</code>+<code cpp>int d, e;</code>
  
 ==Semicolons followed by a space character, if there is more on a line== ==Semicolons followed by a space character, if there is more on a line==
-<code>for (int i = 0; i < 10; i++) {</code> +<code cpp>for (int i = 0; i < 10; i++) {</code> 
-<code>DoSomething(e); DoSomething(f);    // This is probably bad style anyway</code>+<code cpp>DoSomething(e); DoSomething(f);    // This is probably bad style anyway</code>
  
 ==When declaring class inheritance and in a ? construct, colons should be surrounded by white space== ==When declaring class inheritance and in a ? construct, colons should be surrounded by white space==
-<code>class Foo : public Bar {</code> +<code cpp>class Foo : public Bar {</code> 
-<code>var1 ? var2 : var3;</code>+<code cpp>var1 ? var2 : var3;</code>
  
 ==Array delete operator has no whitespace before []== ==Array delete operator has no whitespace before []==
-<code>delete[] foo;</code>+<code cpp>delete[] foo;</code>
  
 ==STD library and <>== ==STD library and <>==
 No whitespaces before or after <, and whitespaces only after >. No whitespaces before or after <, and whitespaces only after >.
-<code>std::vector<int> array;</code> +<code cpp>std::vector<int> array;</code> 
-<code>std::vector<std::vector<int> > array_of_arrays;</code>+<code cpp>std::vector<std::vector<int> > array_of_arrays;</code>
  
 ==Operator overloading== ==Operator overloading==
 Operator keyword is not separated from the name, except for type conversion operators where it is required. Operator keyword is not separated from the name, except for type conversion operators where it is required.
-<code>struct Foo {+<code cpp>struct Foo {
     void operator()() {     void operator()() {
         // ...         // ...
Line 73: Line 73:
 ==Pointers and casts== ==Pointers and casts==
 No whitespace after a cast; and in a pointer, we write a whitespace after it but not before it. Consider "*" to be part of the type. No whitespace after a cast; and in a pointer, we write a whitespace after it but not before it. Consider "*" to be part of the type.
-<code>const char* ptr = (const char*)foobar;</code>+<code cpp>const char* ptr = (const char*)foobar;</code>
  
 ==References== ==References==
 Unlike pointers, use a whitespace before the "&" but not after it. Consider the & operator to affect the variable, not the type. Unlike pointers, use a whitespace before the "&" but not after it. Consider the & operator to affect the variable, not the type.
-<code>int i = 0;+<code cpp>int i = 0;
 int &ref = i;</code> int &ref = i;</code>
-<code>void func(const int &foo) {</code>+<code cpp>void func(const int &foo) {</code>
  
 ====Switch / Case constructs==== ====Switch / Case constructs====
 ---- ----
-<code>switch(command_window->GetIndex()) {+<code cpp>switch(command_window->GetIndex()) {
   case 0: // New Game   case 0: // New Game
       CommandNewGame();       CommandNewGame();
Line 98: Line 98:
 ==Constants== ==Constants==
 All upper case, with underscores as name separators, but no leading/trailing underscores: All upper case, with underscores as name separators, but no leading/trailing underscores:
-<code>THIS_IS_A_CONSTANT</code>+<code cpp>THIS_IS_A_CONSTANT</code>
 ''As a exception'', for headers use the following format: ''As a exception'', for headers use the following format:
-<code>#ifndef _WINDOW_COMMAND_H_+<code cpp>#ifndef _WINDOW_COMMAND_H_
 #define _WINDOW_COMMAND_H_</code> #define _WINDOW_COMMAND_H_</code>
  
 ==Type names== ==Type names==
 We use RPG Maker XP/VX RGSS and scripts as our API base. Normally classes should be named in UpperCamelCase, like EventCommand, but there are some exceptions when trying to mantain the names RPG Maker XP/VX use, like RPG or Scene_Title. Scripts or "Engine" classes use a word prefix with a underscore indicating what they are for: Game_, Sprite_, Spriteset_, Window_ and Scene_. We use RPG Maker XP/VX RGSS and scripts as our API base. Normally classes should be named in UpperCamelCase, like EventCommand, but there are some exceptions when trying to mantain the names RPG Maker XP/VX use, like RPG or Scene_Title. Scripts or "Engine" classes use a word prefix with a underscore indicating what they are for: Game_, Sprite_, Spriteset_, Window_ and Scene_.
-<code>class RPG::MoveRoute {+<code cpp>class RPG::MoveRoute {
 class Game_CommonEvent { class Game_CommonEvent {
 class Window_MenuStatus : public Window_Selectable { class Window_MenuStatus : public Window_Selectable {
Line 112: Line 112:
 ==Functions== ==Functions==
 Functions should be UpperCamelCase. Functions should be UpperCamelCase.
-<code>void ThisIsAFunction() {</code>+<code cpp>void ThisIsAFunction() {</code>
 Property methods should start with Get or Set: Property methods should start with Get or Set:
-<code>class Foo {+<code cpp>class Foo {
 public: public:
     int GetThatInt() { return that_int; }     int GetThatInt() { return that_int; }
Line 124: Line 124:
 ==Variables== ==Variables==
 Variables should be lower case with underscores as word separators. Variables should be lower case with underscores as word separators.
-<code>int this_is_a_variable;</code>+<code cpp>int this_is_a_variable;</code>
  
 ====Headers includes==== ====Headers includes====
 ---- ----
 Use the following format: Use the following format:
-<code>//////////////////////////////////////////////////////////// +<code cpp>
-// Headers +
-////////////////////////////////////////////////////////////+
 #include "header1.h" #include "header1.h"
 #include "header2.h"</code> #include "header2.h"</code>
Line 144: Line 142:
   * Backend/Multimedia headers (e.g. graphics.h)   * Backend/Multimedia headers (e.g. graphics.h)
   * Engine headers (e.g. game_character.h)   * Engine headers (e.g. game_character.h)
-  * Readers headers (e.g. lmu_reader.h)+  * liblcf headers (e.g. lmu_reader.h)
  
 For each headers group alphabetically sort the includes. For each headers group alphabetically sort the includes.
Line 157: Line 155:
 ==Documentation== ==Documentation==
 Use Doxygen like documentation, with the following format for functions: Use Doxygen like documentation, with the following format for functions:
-<code cpp>//////////////////////////////////////////////////////////// +<code cpp>/** 
-/// Description of MyFunction. + * Description of MyFunction. 
-/// A more detailed description here. + * A more detailed description here. 
-/// @param var1 : this is a description for var1 + * @param var1 : this is a description for var1 
-/// @param var2 : this is a description for var2 + * @param var2 : this is a description for var2 
-/// @return here goes a description for return value + * @return here goes a description for return value 
-////////////////////////////////////////////////////////////+ */
 virtual int MyFunction(double var1, std::string var2);</code> virtual int MyFunction(double var1, std::string var2);</code>
  
 With the exception of getters and setters: With the exception of getters and setters:
-<code cpp>/// @return description of variable+<code cpp>/** @return description of variable */
 int GetVariable(); int GetVariable();
  
-/// @param variable : description of variable+/** @param variable : description of variable */
 void SetVariable(int variable);</code> void SetVariable(int variable);</code>
  
 And for variables: And for variables:
-<code cpp>/// Description of example_variable.+<code cpp>/** Description of example_variable. */
 std::string example_variable;</code> std::string example_variable;</code>
  
 Remember to document only declarations and not implementations, i.e. in headers. An exception could be .cpp static functions or variables, if documenting is really necessary. Remember to document only declarations and not implementations, i.e. in headers. An exception could be .cpp static functions or variables, if documenting is really necessary.
- 
-==Separators== 
-For organizing better .cpp files add <nowiki>////////////////////////////////////////////////////////////</nowiki> (60 slashes) between different functions. Normally constructors, the destructor, functions and their overloads, and all properties (getters and setters) should be separated in "groups" with these separators. 
  
 ==Code descriptions== ==Code descriptions==
-We prefer a global function description with Doxygen headers rather than inside the function descriptions. Only when code is really hard to follow, or there is something hardcoded then add some <nowiki>//</nowiki> comments explaining the situation. Do not add redundant comments, like actions that should be already understand easily.+We prefer a global function description with Doxygen headers rather than inside the function descriptions. Only when code is really hard to follow, or there is something hardcoded then add some comments explaining the situation. Do not add redundant comments, like actions that should be already understand easily.
  
 ==Special comments== ==Special comments==
 <code cpp>// TODO: what is left to do <code cpp>// TODO: what is left to do
 // FIXME: what code and in what circumstances it does not work, and if possible why it does not work well</code> // FIXME: what code and in what circumstances it does not work, and if possible why it does not work well</code>
development/player/code-formatting-conventions.1316969268.txt.gz · Last modified: 2013/06/30 23:47 (external edit)
Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki