Skip to content

Latest commit

 

History

History
287 lines (216 loc) · 5.31 KB

CONTRIBUTING.md

File metadata and controls

287 lines (216 loc) · 5.31 KB
Raw

Contributing

Reporting Issues

Bug reports are appreciated. Following a few guidelines listed below will help speed up the process of getting them fixed.

  1. Search the issue tracker to see if it has already been reported.
  2. Include additional information such as:
    • A detailed explanation
    • OpenGD Debug-Info
    • Operating System version
    • Screen shots (if applicable)
    • ...and any other relevant information

GENERAL

  1. Do not use Java-like braces.
  • Good:
    void MyClass::method1()
{
    if (aCondition)
    {
        // Do something
    }
}
  • Bad:
    void MyClass::method1() {
    if (aCondition) {
        // Do something
    }
}

However, the method definition could be defined in a header file (.h), if there's one line code only. In this case, Java-like braces should be used.

  • Good:
    class MyClass
{
public:
    void method1();
    int method2() {
        return _x; // only one line code can be placed in .h as method definition
    };

private:
    int _x;
}
  1. Use tabs instead of white-spaces (we usually set our editors to 4 white-spaces for 1 tab, but the choice is up to you).
  2. Always leave one space before and after binary and ternary operators.
  • Good:
    if (a == 10 && b == 42)
  • Bad:
    if (a==10&&b==42)
  1. Only leave one space after semi-colons in "for" statements.
  • Good:
    for (int i = 0; i != 10; ++i)
  • Bad:
    for(int i=0;i<10;++i)
  1. Function names are not separated from the first parenthesis.
  • Good:
    foo();
myObject.foo(24);
  • Bad:
    foo ();
  1. Keywords are separated from the first parenthesis by one space.
  • Good:
    if (true)
while (true)
  • Bad:
    if(myCondition)
  1. Use the following indenting for "switch" statements:
switch (test)
{
    case 1:
    {
        // Do something
        break;
    }
    default:
        // Do something else
} // No semi-colon here
  1. Avoid magic numbers.
  • Good:
    if (foo == I_CAN_PUSH_ON_THE_RED_BUTTON)
    startTheNuclearWar();
  • Bad:
    while (lifeTheUniverseAndEverything != 42)
    lifeTheUniverseAndEverything = buildMorePowerfulComputerForTheAnswer();
  1. Prefer enums for integer constants.
  2. Use initialization with curly braces.
  • Good:
    MyClass instance{10.4};
  • Bad:
    MyClass instance(10.4);
  1. Always use empty() for testing if a string is empty or not.
  • Good:
    if (!string.empty())
...
  • Bad:
    if (string != "")
...
  1. Always use C++ conversion instead of C-Style cast. Generally, all the conversion among types should be avoided. If you have no choice, use C++ conversion.
  • Good:
    char aChar = static_cast<char>(_pEditView->execute(SCI_GETCHARAT, j));
  • Bad:
    char aChar = (char)_pEditView->execute(SCI_GETCHARAT, j);
  1. Use ! instead of not, && instead of and, || instead of or.
  • Good:
    if (!::PathFileExists(dir2Search))
  • Bad:
    if (not ::PathFileExists(dir2Search))

NAMING CONVENTIONS

  1. Classes uses Pascal Case
  • Good:
    class IAmAClass
{};
  • Bad:
    class iAmAClass
{};
class I_am_a_class
{};
  1. Methods & method parameters use camel Case
void myMethod(uint myVeryLongParameter);
  1. Member variables

Any member variable name of class/struct should be preceded by an underscore.

public:
    int _publicAttribute;
private:
    int _pPrivateAttribute;
    float _pAccount;
  1. Always prefer a variable name that describes what the variable is used for.
  • Good:
    if (hours < 24 && minutes < 60 && seconds < 60)
  • Bad:
    if (a < 24 && b < 60 && c < 60)

COMMENTS

  1. Use C++ comment line style rather than C comment style.
  • Good:
    // Two lines comment
// Use still C++ comment line style
  • Bad:
    /*
Please don't piss me off with that
*/

BEST PRACTICES

  1. Use C++11/14/17 whenever it is possible
  2. Use C++11 member initialization feature whenever it is possible
class Foo
{
    int value = 0;
};
  1. Prefer Pre-increment:
++i
Over Post-increment:
i++

(It does not change anything for built-in types but it would bring consistency)

  1. Don't place any "using namespace" directives in headers.
  2. Compile time is without incidence. Increasing compile time to reduce execution time is encouraged.
  3. Code legibility and length is less important than easy and fast end-user experience.