Difference between revisions of "Coding Style"

From Mineserver Wiki
Jump to navigation Jump to search
m
* '''Indentation''': 2 spaces
* '''Indentation''': 2 spaces
−
* '''Class names''': Camelcase, starting with uppercase letter, e.g.: '''FurnaceManager'''
+
* '''Class names''': PascalCase (e.g.: '''FurnaceManager''').
−
* '''Variable and method names''': Camelcase, starting with lowercase letter, e.g.: '''updateWorld()''', '''userCommands'''.
+
* '''Variable and method names''': camelCase, (e.g.: '''updateWorld''', '''userCommands''').
** '''Pointer variables''': Use '''Foo* bar''' instead of '''Foo *bar'''
** '''Pointer variables''': Use '''Foo* bar''' instead of '''Foo *bar'''
** Using short names for loop variables is ok, e.g. '''i''', '''j'''. Otherwise use descriptive names and don't use abbreviations all over the place, to make the code more readable.
** Using short names for loop variables is ok, e.g. '''i''', '''j'''. Otherwise use descriptive names and don't use abbreviations all over the place, to make the code more readable.
* '''Inline methods''': Keep them short (max 10-15 lines at most).
* '''Inline methods''': Keep them short (max 10-15 lines at most).
−
* '''Documentation''': Use javadoc-style documentation for at least all public methods. Example:
+
* '''Documentation''': Use doxygen-style (javadoc-style?) documentation for at least all public methods. Example:
    /**
    /**
     * The foo() method. Does some fooish stuff, yo!
     * The foo() method. Does some fooish stuff, yo!
 
** Note: Documentation should go in to the header file.
** Note: Documentation should go in to the header file.
* '''Class definitions''': Put public methods at the top of the definition. They're usually the most interesting part from a user's point of view. Private stuff at the bottom.
* '''Class definitions''': Put public methods at the top of the definition. They're usually the most interesting part from a user's point of view. Private stuff at the bottom.
−
class Foo {
+
class Foo
 +
    {
      public:
      public:
      Foo();
      Foo();
 
      private:
      private:
      /* private instance vars etc go here.*/
      /* private instance vars etc go here.*/
−
}
+
};
−
** '''Instance variables''' should usually be accessible through getter and setter methods and thus be private. In some cases having them public is fine (e.g. when they're accessed all over the place and modifiying them happens all over the place as well. Usually this is the case for "dumb classes" used as pure data structures). Also, don't use prefixes for public instance variables, since it's ugly to use. For private instance variables we could choose to use either '''_foo''', '''m_foo''', '''mFoo''' etc. I personally prefer '''_foo''' and have a getter method be just '''foo()''' and a setter '''setFoo()'''. 
+
** '''Instance variables''' should usually be accessible through getter and setter methods and thus be private. In some cases having them public is fine (e.g. when they're accessed all over the place and modifiying them happens all over the place as well. Usually this is the case for "dumb classes" used as pure data structures. We should consider using a '''struct''' instead for these cases.). Also, don't use prefixes for public instance variables, since it's ugly to use. For private instance variables we could choose to use '''m_foo''' and have a getter method be just '''foo()''' and a setter '''setFoo()'''.
 +
** '''Static (class) variables''' should start with just an underscore, e.g. '''_instance''', '''_users''' etc.
* '''Namespaces''': We probably should use them.
* '''Namespaces''': We probably should use them.
 +
* '''Codeblocks''': Use braces always for clarity and to prevent bugs while editing code
 +
    if (true)
 +
    {
 +
      foo = bar;
 +
    }
 +
 +
    if (true)
 +
    {
 +
      foo = bar;
 +
      foo2 = bar2;
 +
    }
 +
* '''Spacing''':
 +
    Foo* bar = new Foo();
 +
    fooBar(param1, param2, param3);
 +
    for (int i = 0; i < 1; i++)
 +
    {
 +
      ...
 +
    }