Rules

[nutsi]

Pour une question d'uniformité, il faut mettre les choses au point dès maintenant.

Code (C++)

• Les classes commencent par une Majuscule.
• Les namespaces sont en miniscule.
• Lorsqu'une fonction peut throw une exception, il est nécessaire de l'indiquer dans sa signature.
• Dans une classe, le nom des attributs doit être précédé par un ___ : int _monInt;
• Les getters/setters d'une classe ne s'appellent jamais getterMachin/setterMachin mais void machin(T) et T machin() const ou const T& machin() const.
• Les fonctions qui testent une condition et qui renvoient un booléen doivent s'appeler bool isMachin() const.
• Les fichiers doivent aussi être écrits en camlCase.
• Les fichiers comportant une classe (ou une famille), doivent en porter le nom (majuscule comprise).
• Ce qui doit être const est déclaré const, idem pour les références (Les interfaces faisant exceptions).
• Lors de l'utilisation de templates, insérer des espaces entre les chevrons, ie std::list< int > et non std::list<int>
• Tous les headers doivent se trouver dans le répertoire inc/ et ses descendants
• Ne jamais faire paraître de ../ dans les #include. Toujours repartir de la racine inc/ si besoin de remonter dans les répertoires.
• Pour le multi-plateforme, deux sous-répertoires linux/ et windows/ d'inc/ permettent de faire figurer les implémentations différentes. Ces deux sous-répertoires doivent reproduire exactement la même hiérarchie qu'inc/
• Les bibliothèques devront être générées dans un dossier lib/ à la racine, dans un sous-répertoire correspondant à leur nom. Leurs sources demeurent par contre dans le répertoire src/
• Pour les bibliothèques dépendant de la plateforme, modifier la procédure précédente pour générer dans lib/linux/nom_de_lib/ ou autre.
• Les fichiers headers doivent être des .hh, ou des .hpp s'ils contiennent du code
• Le code dans les .hpp n'est autorisé que pour les templates et les inline
• Tous les headers doivent être protégés contre la double-inclusion, à l'aide d'une macro relatant le nom du fichier et de dossier: pour le fichier utils/toto.hh, la macro sera UTILS_TOTO_HH_

  Makefile

• Un Makefile par lib ou ensemble de fichiers indépendants (tests)
• Un Makefile général qui les appelle tous
• Ce dernier définit une variable ZIA_PATH, qui correspond à son emplacement dans le système de fichiers
• Tous comme pour les headers, les Makefile ne devraient jamais utiliser ../ pour remonter dans les répertoires. Toujours utiliser ZIA_PATH.

  Git

• Tout commit doit être accompagné d'un message explicite
• Un seul commit par fonctionnalité
• La première ligne sera toujours un résumé de cette fonctionnalité
• Les suivantes la détailleront si besoin

  GitHub

• Toutes les informations nécessaires au bon fonctionnement du projet seront données dans les issues

Pour le moment, c'est tout ce qui me vient l'esprit.

À bon entendeur.

[slashdevsda]

au niveau code tu peux rajouter : "tout ce qui peut être const doit être const" et "tout ce qui peut être une référence doit être une référence" ^^

[nutsi]

Vu que l'on doit faire du c++, je m'etais dis que c'etait quelque chose d'implicite. Mais, je vais le rajouter ;) (^^, si tu vois d'autres chose a rajouter hesite pas)

[entwanne]

Simple question, que fait-on au niveau des headers Epitech ? Est-il utile de les conserver ?

[entwanne]

Et je voudrais revenir sur les const, avec l'exemple des classes Socket. Personnellement, je n'ai pas mis const les méthodes read, write, etc. Bien qu'elles ne modifient aucun attribut, je considère qu'elles altèrent l'objet, et n'ont donc pas à être signées const.

[morosa]

pour ma part je pense vraiment que les header epitech sont devenu inutile ca rajoute des linges plus vraiment utile vue que plus personne les regardent

[slashdevsda]

je suis du même avis sur les headers epitech.