Ronimo Code Style Methodology and Guide

Ronimo Code Style Guide

C ++

• All code and comments are written in British English. (Not in American English.) Correct: color, center, initialiser . Wrong: color, center, initializer .
• Each comma is followed by a space, for example: doStuff(5, 7, 8)
• Operators are separated by spaces, for example: 5 + 7 instead of 5+7
• Tabs are four spaces long. Tabs are stored as tabs, not as spaces.
• Functions and static variables are specified in the same order in the .h and .cpp files.
• Use #pragma once instead of #include guard (we switched to this recently, so you will see many old #include guard in our code).
• Try to write short functions, preferably no longer than 50 lines.
• Avoid creating too large classes. If you expect the class to grow large and it can be logically divided, then divide it. Strive to ensure that the standard class size does not exceed 750 lines. However, you should not divide the class if the code becomes less readable. Here are examples of unreadable partitions: too closely related classes, friend classes, and complex class hierarchies.
• Do not write long lines that do not fit on a standard 1920 * 1080 screen (do not forget that there is a Solution Explorer window on this screen).
• When splitting a long line into several lines, make sure the indents correspond to the brackets. For example, like this:
  
  

   myReallyLongFunctionName(Vector2(bananaXPos + xOffset, bananaYPos * multiplier), explodingKiwi); 

• If possible, use a preliminary announcement: the header files should be as small as possible include. For example, use class Bert; and move #include "Bert.h" to the .cpp file.
• Include and preliminary declarations must have the following order:
  
  • Start with all preliminary announcements from your own code (in alphabetical order)
  • Then all include from your own code (in alphabetical order)
  • Empty line
  • Then for each library:
    
    • Preliminary announcements from this library (in alphabetical order)
    • All include from this library (in alphabetical order)
• The include of the .h file belonging to the .cpp file is always at the top.
• Do not define static variables in a function. Use class element variables (possibly static).
• Everything must be correct in terms of const .
• The names of variables and functions should be descriptive. You can easily use long names, you can not use vague names. Use abbreviations only if they are very clear and standard.
• The first letter of the class names, the struct and enum types is the capital letter. Variables and functions begin with an uppercase. Each next word in the title begins with a capital letter. Do not use underscores (_) in variable names. Here is an example:
  
  

   class MyClass { void someFunction(); int someVariable; }; 

• Element variables are not flagged in any way, neither the letter m before the name, nor _ after. Functions must be short enough so that you can keep track of what is declared in the function and what is in the class. Do not mark the variables of the elements this-> .
• Implementations of functions should never be in .h files.
• Template functions that cannot be implemented in a .cpp file are implemented in an additional header file, which is included from the main header file. Such a class can have three files: MyClass.h, MyClassImplementation.h and MyClass.cpp. For example:
  
  

   class MyClass { template <typename T> void doStuff(T thingy); }; #include "MyClassImplementation.h" 

• Start the template type names with the letter T. If you need more information, then you can add words after it, for example TString .
• You cannot declare multiple classes in a single header file. Exception: the file is part of another class (for example, declared inside another class).
• There must be two blank lines between the functions (in the .cpp file).
• Use blank lines to structure and group code for readability.
• Accompany the code with detailed comments.
• Above each class give a short description of the class. In particular, it is worth describing relationships (for example, “This class helps class X by doing Y for it”).
• The curly brackets { and } always occupy a separate line, that is, they cannot be placed on a single line with if or for . Also, they can never miss them. The only exception: several similar single-line if constructions, going one under the other. In this case, it is allowed to put them in one line. As in this example:
  
  

   if ( banana && kiwi && length > 5) return cow; else if ( banana && !kiwi && length > 9) return pig; else if (!banana && !kiwi && length < 7) return duck; else return dragon; 

• When writing the do-while while function, it should be in the same line with a closing bracket:
  
  

   do { blabla; } while (bleble); 

• Indents in switch constructions should be arranged as follows:
  
  

   switch (giraffeCount) { case 1: text = "one giraffe"; break; case 2: text = "two giraffes"; break; case 3: //     doStuffOnSeveralLines; text = "three giraffes"; break; case 4: { //       int x = getComplexThing(); text = "quadruple giraffe"; break; } } 

• Function parameters must have the same name in the .h and .cpp files.
• If the function parameter and the variable of the class element have the same name, then you need to either come up with another name, or add _ at the end of the function parameter. For example, like this:
  
  

   void setHealth(float health_) { health = health_; } 

• The number of preprocessor instructions (everything starting with #) should be minimal, of course, except for #include and #pragma once .
• Do not write macros.
• Variables within functions are declared where they are needed, not all of them need to be declared at the beginning of a function.
• In the body of constructors, it is better to use initialization lists (initialiser list), rather than setting variables. Each initialization in the initialization list should occupy a separate line. Make sure the variables in the initialization list are in the same order as in the class definition in the .h file.
• Do not use exceptions (unless you use a library that requires them).
• Do not use dynamic data type identification (RTTI) (that is, do not use dynamic_cast ). RTTI slows down a bit, but more importantly, RTTI is almost always a sign of poor object-oriented design.
• Use reinterpret_cast and const_cast only when absolutely necessary.
• Do not commit code that does not compile without errors or warnings (and do not turn off warning / error messages).
• Do not commit commits breaking existing functionality.
• No global variables. Use variable elements of the static type instead.
• Instead of std::abs use our own function MathTools::abs . Reason: implementation of std::abs is different on different platforms, which leads to hard-to-find errors.
• Always use namespaces explicitly. Do not insert into the code anything like using namespace std .
• Don't even think about using go-to designs. We have a thought recognizer and in such cases it beats the programmer with current.
• Do not use commas as delimiters. Example: if (i += 7, i < 10)
• Do not use union unions.
• Do not use function pointers unless required by other libraries (for example, sort from STL).
• Use ternary operators only in the simplest cases. Never use nested ternary operators. Example of permitted simple use:
  
  

   print(i > 5 ? "big" : "small"); 

• The counters used by the artist or designer must begin with 0, as in ordinary arrays in code. Some old tools may still start at 1, but all new tools developed for artists start at 0.
• When checking for the existence of a pointer, perform this operation explicitly. Therefore, use if (myPointer != nullptr) , and not if (myPointer) .
• If possible, use RAII (Resource Acquisition Is Initialization). That is, instead of creating a separate initialise() function, completely initialize the class in its constructor so that it is never in an incomplete state.
• Write the constructor and destructor at the same time: write each corresponding delete for each new , so as not to forget about them later.
• If you are writing a temporary debugging code, then add a comment with QQQ to it. Never commit with QQQ : delete all debugging code before committing.
• If you want to leave a note on what needs to be done later, use QQToDo . If you need to do this, add your letter to the comment, for example, QQToDoJ . Make commits with QQToDo only if it is impractical to shut down now.
• Class definitions begin with all functions, then all variables follow. The order should be as follows: public/protected/private . This can sometimes mean that you need to use the same public/protected/private keywords in the same header file several times (first for functions, then for variables).
• The class begins with its constructors, followed by the destructor. If they are private or protected , they should still be at the top.
• If something has two options, but not exactly true/false , then it is better to use the class enum , rather than boolean . For example, to indicate the direction, do not use bool isRight . Instead, use enum Direction with the values Left and Right .
• Instead of std::string and std::stringstream use our own RString , RStringstream , WString and WStringstream (they are tied to our own memory management system).
• The variable float time always means the time after the last frame in seconds. If time means something else, then express it explicitly, for example, by giving the name timeExisting .
• Make sure that all code is independent of the frame rate, so actively use the float time variable for this.
• Make the structures explicit and understandable. For example, avoid this:
  
  

   if (yellow) { return banana; } return kiwi; 

  
  This means that, depending on the yellow, banana or kiwi is returned. More readable code will be, if you express it explicitly:
  
  

   if (yellow) { return banana; } else { return kiwi; } 

• Use nullptr , not NULL .
• We use auto only for cases such as complex iterator types. For everything else, we specify the type explicitly.
• Use where applicable, range-based for, for example:
  
  

   for (const Banana& ultimateFruit : myList) 

  
  (Note that when you do not work with pointers, it is important to type this link, because otherwise Banana will be copied in this case.)
• As applicable, use override and final .
• If the function is virtual, then the virtual keyword should always be added to it, not only in the parent class, but also in each of the versions of the functions in the descendant classes.
• Use enum with strong typing, the same with the word class . The register in the names is the same as in the classes. For example:
  
  

   enum class Fruit { Banana, Kiwi, ApplePie }; 

• Use rvalue references ( && ), if absolutely necessary.
• If possible, use unique_ptr . If the object does not have an owner, then it is stored as a regular pointer.
• Avoid instantiating complex types in the initialization list. In the initialization list, simple copying and assignment is used, and more complex code, for example, the call new , should be in the body of the constructor. Here is an example of how this works:
  
  

   FruitManager::FruitManager(Kiwi* notMyFruit): notMyFruit(notMyFruit) { bestFruitOwnedHere.reset(new Banana()); } 

• Use shared_ptr only in cases where common ownership is really necessary. In general, try to avoid common ownership and use

   unique_ptr 

  .
• Lambda functions that are too long to be written in one line should have the following indents:
  
  

   auto it = std::find_if(myVec.begin(), myVec.end(), [id = 42] (const Element& e) { return e.id() == id; }); 

• Do not use MyConstructor = delete (this does not seem to be supported in some of the compilers we use).
• Do not use the C ++ 11 features to initialize lists (it seems that this is not supported in some of the compilers we use). Therefore, we do not use this:
  
  

   std::vector<int> thingy = {1, 2, 3}; 

• Do not use features added in C ++ 14.

C #

• Variables should be at the beginning of the file, not at the bottom. We strictly separate functions and variables (as in C ++), so all variables are listed first, then all functions.
• Names async-functions must always end with Async, for example eatBananaAsync.