Invité
|
Posté le: Jeu Jan 01, 1970 16:37 Sujet du message: Re: Proposition de coding standard |
|
|
| Grelumph a écrit: | Identificateurs
fichier : tout en minuscules
méthode/fonction : première lettre majuscule, le reste en alpha-num
La bof pour la minuscule mais aprés tout...
Enfin, je trouves que çà ne correspond à rien d emettre la première lettre d'une méthode en minuscule.
variable : première lettre minuscule, le reste en alpha-num
variable pointeur : préfixe p, première lettre minuscule, le reste en alpha-num
variable membre : préfixe m_, première lettre majuscule, le reste en alpha-num
variable membre statique : préfixe s_, première lettre majuscule, le reste en alpha-num
variable membre constante: préfixe c_, première lettre majuscule, le reste en alpha-num
type : préfixe T, première lettre majuscule, le reste en alpha-num
classe : préfixe C, première lettre majuscule, le reste en alpha-num
Le C çà me fait beaucoups penser à MFC ;o)
En fait pour ma part, dans les divers projet auxquels j'ais participé on mettait la premiere lettre qui correspondait au projet. Par exemple ici ce serait N. Ca permet de savoir si la classe a ete developpe dans le projet ou s'il st vient d'une lib quelqconque.
j'ai laissé le préfixe C pour une classe, mais au fond je n'en vois pas l'intérêt.
il n'y a rien sur la visibilité, parce que la ou je bosse, on ne fait que des données privées (à part éventuellement des constantes, mais on n'en a pas des tonnes non plus).
Dimensionnement
Taille max d'un fichier source : ~3000 lignes
Taille d'une classe : de 5 à 15 méthodes (sans les accesseurs sur les données membres)
Taille max d'une méthode : ~90 lignes
Nb paramètres d'une méthode : <=6
Profondeur max de boucles/conditions : 4
Organisation d'une classe
Organisation des membres suivant :
1. la visibilité : publique en premier, puis protégé et pour finir privé
2. la nature (pour les méthodes). dans l'ordre :
constructeurs/destructeurs
accesseurs
opérateurs
traitements
copie/clonage
Organisation d'une méthode
1. test des pré-conditions
2. déclarations
3. traitement
4. test des post-conditions
Format des commentaires
Donc c'est le format supporté par Doxygen, à savoir comme Javadoc mais mieux
En-tête d'un prototype de méthode
/// Description courte
En-tête d'une méthode
/**
* Description détaillée
* @date
* @param <nom> <desc>
* @return <desc>
* @pre <pré-condition>
* @post <post-condition>
* @invariant
*/
tous les champs ne sont pas nécessaires. ca dépend de la complexité de la méthode
pour le champs @date, je préconise la forme <date> - <auteur> - <commentaire>
ca permet de gérer une sorte d'historique (<commentaire> pouvant être création, correction ...)
on peut bien sur utiliser un champ @author séparé, mais je trouve que ca perd de l'intérêt
La par contre, je préfèrerait deux truc :
Entête de fichier avec balises CVS (headern name, date, etc).
Fin de ficheier $Log$.
Si biensur on utilise CVS....
Pour doxygen, je suis totalement d'accord, çà coute trés peu de chose et çà apporte énormément au projet.
Commentaire d'une structure
/// Description de la structure
typedef enum {
val1, /**< Desc de val1 */
val2, /**< Desc de val2 */
val3 /**< Desc de val3 */
} TBidule;
Doxygen permet de regrouper les déclarations par thème (pratique pour regrouper les accesseurs, les traitements ...)
/** @name <Thème> */
//@{
<prototypes>
//@}
dans le cas ou vous ne connaitriez pas Doxygen, http://www.stack.nl/~dimitri/doxygen/
je trouve cet outil excellent parce qu'il peut être connecté à un autre outil (GraphViz) pour générer des graphes d'héritage et de collaboration, et à Latex pour intégrer des formules de maths dans les commentaires (j'ai pas réussi mais on peut le faire)
on peut aussi utiliser du code html dans les descriptions (pour mettre des liens, des images, ou pour formatter les descriptions)
le défaut c'est qu'avec tout çà on peut avoir des commentaires super lourds et plus forcément très lisibles (le but étant d'avoir une doc html à côté, c'est pas forcément très gênant) |
|
|