Re: [certi-devel] Patch GAV_aux.cc

[Benoît Bréholée]

Valéry Raulet <address@hidden> writes:
> 
> Par contre pour la mise en forme du code source, y a t-il des
> conventions d'écriture ? (ca serait bien pour homogènéiser l'ensemble
> de sources)

J'utilise l'indentation que me fournit emacs (je ne sais pas quel est
le style, c'est celui par défaut, sans doute 'gnu'). A l'exception des
namespaces dont l'intérieur n'est pas indenté.

Pour les blocs, nombre de lignes minimisé :
        if(...) {
        ...
        }

ça permet de voir plus de choses à l'écran. Par contre ça ne
s'applique pas aux blocs class ou pour les méthodes. Pour les méthodes :

prefixes type_retour
Classe::methode(parametres)
  throw()
{
  ...
}       

class MaClasse
{

};

le tout en restant en dessous des 80 colonnes (c'est très appréciable
quand on lit du code imprimé !). Si ça dépasse, les paramètres passent
sur plusieurs lignes, indentés au meme niveau que le premier. Idem
pour les exceptions. Si ça ne suffit toujours pas, classe et nom de
méthodes sur deux lignes différentes :

type_retour
Nom_de_classe::
nom_de_methode_tres_long(un_type premier_parametre,
...


Pour les identifiants, style java : UneClasse, uneMethode(), unAttribut,
UNE_CONSTANTE, une_variable_locale

Voilà pour les principaux points. C'est ce que j'essaie d'appliquer
quand j'ai des modifications à faire, mais comme il y a eu beaucoup de
contributeurs différents, on trouve des styles très différents.

J'ai fait des modifications de ce genre avant certi 3.0 pour ce qui
pouvait être fait plus ou moins automatiquement (noms de classes et de
méthodes). Maintenant, l'inconvénient est que ça rentre en conflit
avec CVS : si un source est complètement reformaté, un diff entre 2
versions de part et d'autres ne donnera rien d'intéressant. Donc je
pense que la meilleure chose à faire est d'adapter le style quand il y
a des modifications à faire, et de laisser tel que tant que ça n'a pas
besoin d'être modifié (cf. GAV_aux, de 3.1 à 3.2 j'en ai profité pour
faire des modifications de style)

Autre chose concernant le code : il faudrait que tout soit en anglais,
variables et commentaires. Changer les commentaires ne doit pas poser
de problèmes avec les diffs s'ils sont en blocs et pas en fin de
ligne. Sinon, les commentaires de fin de ligne et les identifiants ne
devraient être changés que s'il y a vraiment une modification à faire.

Le style, ça concerne aussi les commentaires... j'ai fait un test avec
Doxygen[1], ça ne rend pas grand chose puisqu'aucun commentaire n'est
déclaré comme commentaire de documentation, et qu'aucun tag n'est
utilisé. Mais s'il faut une convention, ce que propose Doxygen est
intéressant, et c'est une bonne solution au problème des docs trop
vite obsolètes.

Je vais déjà voir si parmi les styles existants il y en a un qui
correspond à peu près à ça. Ca pourrait servir de référence. 

> Autre question : vous utilisez peu les fonctionnalités de la STL. Je
> voulais savoir si c'était un choix imposé ?

C'était plus ou moins « imposé » par les implémentations existantes de
C++ au début du projet (1996). Ca ne doit plus poser de problèmes
maintenant (en fait je compte bien l'utiliser dans CERTI
prochainement).

Benoit.

[1] http://breholee.free.fr/CERTI/

-- 
Benoît Bréholée [http://breholee.free.fr] [mailto:address@hidden
CERTI - http://www.cert.fr/CERTI/