Conventions

Git

Formattage

Toujours faire un nom de commit explicite !! :
- NON ! :
  - correction
  - loadMusic fait
  - ghrksj,gksdnkgj
  - test
  - IHM fini
  - wallah
  - meh
  - ...
- OUI :) :
  - [STABLE] Correction du lancement de l'IHM (image apparait)
  - [ToTEST] ajout de la coloration syntaxique (juste pour quelque mots)
En plus du nom du commit explicite, il faut souvent une description (les listes c'est bien) !! ex :

[ToTEST] ajout de la coloration syntaxique (juste pour quelque mots)
# ligne a laisser blanche
    - coloration pour :
      - si
      - sinon
      - fin
      - else

[ToTEST] ajout de la coloration syntaxique (juste pour quelque mots)
# ligne a laisser blanche
    - coloration pour :
      - les mots clés
      - quelques fonctions importantes (avancer, reculer ...)
      - commencement pour les variables (juste la recupération pas encore la coloration)

Toujours mettre un flag avant chaque message parmis ceux-ci, trié par ordre de "stabilité" (si il en manques, venez me voir) :
- [STABLE] : fonctionnel, stable
- [ToTEST] : à tester
- [INSTABLE] : le comportement est instable, on sait, mais on a du commit
- [ERROR] : la ca marche pas, DU TOUT, ca compile pas ou segmentation fault ou ...
Vous pouvez créer des alias (-e : permet l'edition meme avec un message) /!\ le nom de l'alias est à changer (ex cFonct ou commitFonct ...):

git config --global alias.nomAlias 'commit -m "[STABLE] " -e'
git config --global alias.nomAlias 'commit -m "[ToTEST] " -e'
git config --global alias.nomAlias 'commit -m "[INSTABLE] " -e'
git config --global alias.nomAlias 'commit -m "[ERROR] " -e'

Apres le flag, mettre le mot qui resume votre commit :
- add/ajout
- fix
- modify/modifie

Workflow

Commit dès qu'une tache est terminée !
Si vous n'arrivez pas à resumer un commit dans son nom, qu'il manques des choses,
c'est qu'il faut diviser en plusieurs commit (vous pouvez utiliser git commit -p ou -i)
une branche par fonctionnalité !!
dès que vous pensez que votre branche est prête, faite un pull-request (pas un merge) donc sur GitHub dans develop
Rappel du workflow : La branche principale est develop, mais on passe en fait par les branches thématiques feature/??? et des Pull-Request.
Puis on merge dans release pour préparer la prochaine version public et enfin on merge dans master pour le public (et on tag genre : v1.1).
Parfois il faut corriger un bogue rapidement et on par par hotfix et on remerge dans master directement.
Respecter le workflow, une branche sera toujours :
- master
- hotfix
- release
- develop
- feature/<nomFeatureExplicite>

Formattage du code :

Un fichier xml de formattage est fournie pour eclipse, de là vous pouvez cloner ou télécharger le repo.
Ensuite dans Eclipse > Window > preferences > C/C++ > Code Style > Formatter > bouton import

1. Indentation :

NE PAS UTILISER DE TABULATIONS !! utiliser des espaces (dans les IDE regarder dans les parametres de formattage).
L'indentation est de 2 caractères.

2. Espaces :

Ne laisser pas d'espaces en fin de ligne.
Faites des sauts de ligne pour grouper des instructions/declarations.
Utiliser seulement un saut de ligne pour grouper.
Utiliser un espace après chaque mot clé.
Example:

if(   // wrong
if (  // correct

Usage des espace dans les parentheses (e.g. if- et for-, function calls) faite comme vous voulez.
Example:

if (i < 5)                    <->  if ( i < 5 )
calculateSalary(age, years);  <->  calculateSalary( age, years );

Pour les pointers ou les references, Utiliser
un simple espace après '*' ou après '&', mais pas avant (C++ style),
Example:

T* v;
T& v;

Attention:

char* i, j;  // i is declared pointer to char, while j is declared char, donc à ne pas faire

Pas d'espace après un cast.
Pas d'espaces autours de '.' ou '->', ni entre les operateurs unaires ni les operandes.

3. Accolades :

Les implementations de fonction, les classes, les struct et les declarations de namespace
on toujours leurs accolade ouvrante sur le debut de la ligne (suivante) :

class Test
{
  cout<<"test";
}

Pour tous les autres (if, switch, for, ...), l'accolade ouvrante
va sur la meme ligne que le debut de l'expression :

if (true) {
  cout<<"test";
}

Utiliser toujours des blocs (accolades) meme s'il n'y a qu'une instruction (si jamais on doit en rajouter, cela reste consistant).

4. Instructions :

Ne pas mettre plusieurs instructions sur la meme ligne.

5. Switch :

Les case sont sur la meme colonne que le switch.

6. Retour à la ligne :

Toujours garder les lignes plus courtes que 100 caractères (utiliser des retours à la ligne).

7. Pointeurs :

En C++, un pointeur nul est

nullptr

et pas

0l ou 0L ou NULL

Nommage :

Ne pas faire d'abreviations dans le nom de classe ou de variable !!

Declarer chaque variable sur une nouvelle ligne.
les variables et les fonctions commencent par une minuscule.
Les classes commences toujours par une Majuscule (n'est ce pas Jessy ;) ).
Chaque nouveau mot dans un nom commence par une Majuscule :

int varTest;
class TestExemple{
  public:
  void methodeDeClasse();
};

N'utiliser des enderscores "_" que pour les constantes static int const TEST_CONSTANT; sauf :
Les attributs membre/fields/champs commence tous par "_" comme string _nom;.
Ne pas utiliser du style pseudo Hungarian.
Example:

_bSomeBoolean, _pSomePointer  // wrong
_someBoolean, _somePointer    // correct

La premiere lettre de vos classes correspond à sa place dans le pattern MVC
Exemple :

class MClassModel; // une classe Model
class CClassControler; // une classe controler

Utiliser un alignement vertical pour faciliter la lecture des declarations :
Example:

QString  aStringToUse;
int      anInt;
double   aDoubleNumberToUse;

Utiliser les static const pour les constantes !
Raison:
Pour la sureté des types.

Casting :

Utiliser les cast du C++ comme static_cast, dynamic_cast au lieu de ceux du C (details des casts)

Class* t = static_cast<Class*>(object);        // correct
SubClass* t = dynamic_cast<SubClass*>(object); // correct

et pas celui là :

SubClass* t = (SubClass*)object; // wrong !!

Includes :

Inclure ses headers d'abord.
Inclure ensuite les headers systemes (eg <iostream>)
Les includes des headers doivent etre minimale, du au temps de compilation.
Cela peut etre fait par des "forward declare" puis ensuite inclure dans les sources(.cpp)
les "Forward declarations" marchent pour les pointers et les const references.

Include guards :

Les include macro doivent etre toutes en majuscules.
Example:

#ifndef MyFileName_h    // wrong
#ifndef MY_FILE_NAME_H  // correct

Ne pas mettre d'underscores au debut des include guard
Example:

#ifndef _MY_FILE_NAME_H_   // wrong
#ifndef MY_FILE_NAME_H_    // correct

Commentaires Doxygen :

Tous les éléments doivent avoir un commentaire doxygen (class, methods, attribut spécifiques, element d'enum...)
Les commentaires doxygen ressemblent (see also):

/**
 * Here is the description...
 * @param ...   ...
 * @param ...   ...
 * @return      ...
 */
  <element>

Les commentaires pour les méthodes doivent etre ecrit dans l'implementation(cpp). Les commentaires pour les classes/attribut doivent etre ecrit dans le header(hpp).
Raison :
le header peut etre relue rapidement.

Structure de header :

Un header(hpp) ne doit contenir qu'une seule et une seule classe public !!
Utilisez le template suivant :

<license>
<include guard>
<includes>

namespace
{

/**
* description
*/
class <Name> : public <Parent>
{
//========================>Attributes<========================
private:

//=======================>Constructors<=======================
public:
  <Name>();
  virtual ~<Name>();

private:

//=========================>Methods<==========================
public:

private:

//=====================>Getters&Setters<======================
public:

private:

};

}

C++ :

La "const correctness" Doit etre preservé au mieux !!
Rendez tout les getters const.
Cela peut etre une bonne idée de rendre les constructeurs explicit ( niveau avancé : renseignez vous ;) )

Metrics :

loc = lines of code
Refactor classes qui comportent plus de 1000 loc.
Refactor les methodes qui comportent plus de 200 loc.

SpaceBoxInk/Conventions