DEFAULT STYLE PROGRAMMING - GesielFreitas/CrossRoads-IJE-UnB GitHub Wiki

SUMARY

  1. Class, Functions and Variables Declarations
  2. Indent Style, braces and operators
  3. Header Style
  4. Comments
  5. Exceptions
  6. Good habits
  7. Lines and withespaces
  8. Statements

1. Class, Functions and Variables Declarations:

Summary

For declaration:

1.1. UpperCamelCase: this change the first letter should be upper case obligatorily, normally used in the statements:

  • Class name
  • Name Of Enums

Wrong

class gameobject{

}
class button {

}

Right

class GameObject {

}

class Button {

}

Wrong enum

enum class audiostate {

}

right enum

enum class AudioState {

}

1.2. Variables and functions names should be lowercase with underscores between words

  • Variables
  • Functions

Wrong

void MonsterAI::processPos() {
    ...
}
void MonsterAI::Process_pos() {
    ...
}
    hasDamage = false;
    hasdamage = false;

Right

void MonsterAI::process_pos() {
    ...
}
    has_damage = false;

1.3. Constant names should be uppercase with underscores between words

Wrong

const int player_distance = 850;
const int PlayerDistance = 850;
const int Player_distance = 850;

Right

const int PLAYER_DISTANCE = 850;

2. Indent Style, braces and operators

2.1. Indent Style

2.1.1. Use 4 spaces per indentation level.

Wrong Example:

if ( foo ) {
  do_something();
}

Right Example:

if( foo ) {
    do_
}

2.2 Braces

When start a new code block use braces for emulating pure blocks.The opening brace must appear on the same line of the structure who contains it, separated by 2 blank spaces after its end. The closing brace must appear on the line after the block end.

Wrong Example:

void example( foo )
{
  ...
}
void example( foo ) {...}

Right Example:

void example( foo ) {
  ...
}

2.3 Operators

All the operators must be separated from the operands by a blank space.

Wrong example:

int foo=4+4;

int foo= 4+4;

Right example:

int foo = 4 + 4;

3. Header Style

3.1 The #define Guard

All header files should have #define guards to prevent multiple inclusion. The format of the symbol name should be H. To guarantee uniqueness, they should be based on the full path in a project's source tree.

Wrong example:

#define BAZ_H_

...

#endif  // BAZ_H_

Right example:

#define FOO_BAR_BAZ_H_

...

#endif  // FOO_BAR_BAZ_H_

4. Comments

4.1 Comments should be complete sentences

4.2 All comments must have a blank line before and after

4.3 Comments must have a maximum of 80 characters per line

4.4 Single line comments must be written with // (space) (comment)

4.5 All comments must be idented with the code

4.6 All comments must begin with first letter capitalized

4.7 All comments must be written in English

4.8 Block comments - two or more lines - should begin / * followed the comment and closed with * / in new line. The content of the comment should be idented in relation to bookmarks /* */.

Wrong Example:

// Loop to iterate in the range of table
  for (i in range 0,10) {
  ...
  };

//Imprimindo a interação
  std::cout << i ;

// Returns an iterator for this table.  It is the client's responsibility to delete the iterator when it is done with it, and it must not use the iterator once the GargantuanTable object on which the iterator was created has been deleted.
// Returns an iterator for this table.  It is the client's
// responsibility to delete the iterator when it is done with it,
// and it must not use the iterator once the GargantuanTable object
// on which the iterator was created has been deleted.
/*
Returns an iterator for this table.  It is the client's
responsibility to delete the iterator when it is done with it,
and it must not use the iterator once the GargantuanTable object
on which the iterator was created has been deleted.
*/

Right Example:

  // Loop to iterate in the range of table

  for (i in range 0,10) {
  ...
  };
    // Printing the iterator

    std::cout << i ;
/*
    Returns an iterator for this table.  It is the client's
    responsibility to delete the iterator when it is done with it,
    and it must not use the iterator once the GargantuanTable object
    on which the iterator was created has been deleted.
*/

5. Exceptions

5.1. Assert liberally to document internal assumptions and invariants

Wrong Example:

assert(false);

Right Example:

assert( !variable );

5.2. Prefer to use exceptions to report errors

Reasons why exceptions is better than errors:

  • Exceptions can't be silently ignored;
  • Exceptions propagate automatically;
  • Exception handling removes error handling and recovery from the main line of control flow;
  • Exception handling is better than the alternatives for reporting errors from constructors and operators.

5.3. Throw by value, catch by reference

Wrong Example:

catch( MyException& e ) {
    e.AppendContext("Passed through here");
    throw e;
}

Right Example:

catch( MyException& e ) {
    e.AppendContext("Passed through here");
    throw;
}

5.4. Avoid exception specifications

Wrong Example:

class Abc {
    virtual f() throw( X, Y, Z);
};

Right Example:

class MyDerived : public Abc {

    virtual f() throw( X, Y, Z);

};

6. Good habits

This section aims describe good habits that should be adopted on a daily basis in programmer routine for the purpose of generate code safe, clean and principally easy to maintain.

  1. Follow the style sheet;
  2. Prioritize clarity rather than conciseness:
  3. Prioritize simple resolutions;
  4. Break the code into smaller pieces;
  5. Break arithmetic expressions;
  6. Reduce scope
  7. Protect data and internal functions;
  8. Avoid using global variables;
  9. Never ignore compiler warnings;
  10. Use secure data structures;
  11. Check all return values;
  12. Fix errors received
  13. Release the resources(memory, threads, files, locks...) that are no more used;
  14. Initialize all variables in declaration;
  15. Declare the variables as close to their use as possible;
  16. Don't reuse the auxiliary variables name;
  17. Don't abbreviate the names of variables, functions, classes, and constants
  18. Use standard language sentences and resources.

7. Lines and withespaces

7.1 Add one blank line between each logical block of code

The code must be separated into logical paragraphs by a blank line, so as to make clear the identification of parts of the code, such as initialization of variables, execution of a particular procedure, etc.

Wrong

Matrix4x4 matrix = new Matrix4x4();
double cosAngle = Math.cos(angle);
double sinAngle = Math.sin(angle);
matrix.setElement(1, 1, cosAngle);
matrix.setElement(1, 2, sinAngle);
matrix.setElement(2, 1, -sinAngle);
matrix.setElement(2, 2, cosAngle);
multiply(matrix);

Right

Matrix4x4 matrix = new Matrix4x4();

double cosAngle = Math.cos(angle);
double sinAngle = Math.sin(angle);

matrix.setElement(1, 1, cosAngle);
matrix.setElement(1, 2, sinAngle);
matrix.setElement(2, 1, -sinAngle);
matrix.setElement(2, 2, cosAngle);

multiply(matrix);

7.2 Add one blank line between functions and other file components

Wrong

#include <iostream>
using namespace std;

void first_function() {
  ...
}
void second_function() {
  ...
}

Right

#include <iostream>

using namespace std;

void first_function() {
  ...
}

void second_function() {
  ...
}

7.3 Add one blank line after functions and class declaration and before last key

Wrong

bool first_function( int value, int max ) {
    if( value > max ) {
        return false;
    }
    return true;
}
class Rectangle {
    int width, height;

    public:
      void set_values (int,int);
      int area (void);
} rect;

Right

bool first_function( int value, int max ) {

  if( value > max ) {
      return false;
  }

  return true;

}
class Rectangle {

    int width, height;

    public:
       void set_values (int,int);
       int area (void);

} rect;

7.4 In decision structures and loop, the statements should begin in next line after structure declaration

Wrong

if( value > max ) {

    return false;
}
while( value < max ) {

    cout << value << endl;
}

Right

if( value > max ) {
    return false;
}
while( value < max ) {
   cout << value << endl;
}

7.5 In if and while statements if the parenthesis content is not empty, a blank space should be added after opening the parenthesis and a blank before closing

Wrong

if(value > max) {
    ...
}
while(value < max ) {

}
move_monster(  );

Right

if( value > max ) {
    ...
}
while( value < max ) {

}
move_monster();

7.6 The opening of the parenthesis must be immediately after the sentence calling it not having

Wrong

if ( value > max ) {
    ...
}

Right

if( value > max ) {
    ...
}

7.7 Whenever a key is opened it must contain a blank space before opening

Wrong

if ( value > max ){
    ...
}

Right

if( value > max ) {
    ...
}

7.8 Whenever a key is opened it must contain a blank space before opening

Wrong

if ( value > max ){
    ...
}

Right

if( value > max ) {
    ...
}

7.9 Include statements must contain a space between the include and the call library

Wrong

#include"monsterAI.hpp"
#include<stdio.h>

Right

#include "monsterAI.hpp"
#include <stdio.h>

7.10 A line can be a maximum of 80 characters. If it is necessary to break the line it must be indented according to its the origin of its sentence

Wrong

if( _main_game_object->main_positionX<0 || _main_game_object->main_positionX+_main_game_object->main_width>800 )

Right

if( _main_game_object->main_positionX<0 || 
    _main_game_object->main_positionX+_main_game_object->main_width>800 )

7.11 Parameters of functions should not contain spaces in relation to parenthesis. If there is more than one parameter, a whitespace should be included after each separating comma

Wrong Example

m_monster_controler->play_animation("monster_walk",true);
m_monster_controler->play_animation( "monster_walk", true );
m_monster_controler->play_animation( "monster_damage" );

Right Example

m_monster_controler->play_animation("monster_walk", true);
m_monster_controler->play_animation("monster_damage");

7.12 A line should break after a binary operator

Wrong Example

compound_key = (registration 
               + id);

Right Example

compound_key = (registration +
               id);

8. Statements

8.1 If statements should always mark the block with keys. In the case of keywords else and else if you should always start them on the next line after the key is closed.

Wrong Example

if( !has_ground() ) {
    ...
} else {
    ...
}

Right Example

if( !has_ground() ) {
    ...
}
else {
    ...
}

8.2 The initialization of variances of a class by passing a list of parameters to the constructor must have a blank before and after the colon - if it fits on a single line. If more than one line is required, the list must start on the next line and be indented according to the parameters of the constructor method

Wrong Example

Heart(GameObject &main_game_objecte): Component(main_game_object, id) {}
Heart(GameObject &main_game_objecte) :
  Component(main_game_object, id) {}
Heart(GameObject &main_game_object, std::string id, Player* player, int life):
Component(main_game_object, id), m_player(player), m_life(life) {}

Right Example

Heart(GameObject &main_game_objecte) : Component(main_game_object, id) {}
Heart(GameObject &main_game_object, std::string id, Player* player, int life) :
      Component(main_game_object, id), m_player(player), m_life(life) {}

8.3 The operator accessing a pointer must be adjacent to the referent variable

Wrong Example

GameObject * ground;
GameObject* ground;
Player(GameObject & main_game_object);

Right Example

GameObject *ground;
Player(GameObject &main_game_object);

8.4 Dynamic cast should not have spaces inside the '<' and '>' operators and should contain a whitespace after the cast is closed

Wrong Example

AudioComponent *boss_dash_audio = (dynamic_cast<AudioComponenti*>());
AudioComponent *boss_dash_audio = (dynamic_cast< AudioComponenti* > ());
AudioComponent *boss_dash_audio = (dynamic_cast<AudioComponenti *> ());

Right Example

AudioComponent *boss_dash_audio = (dynamic_cast<AudioComponenti*> ());
Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️