Pourquoi est-ce utile ?

D'abord, quel est l'interet de mettre en forme son code ? La lisibilité ! Un code bien mis en forme est plus facile à lire, à comprendre, et donc à maintenir.

Ensuite, quel est l'interet d'avoir une même convention pour tout un projet ? Encore la lisibilité ! Si chaque développeur présente son code comme il l'entend, l'intégration risque de se faire dans la douleur. Les différents morceaux seront difficiles à lire, les noms des variables seront surement incohérents (avec risque de doublons), etc.

Enfin, quel est l'interet de rédiger un document ? Pouvoir entrer dans les détails. En effet, si on peut se mettre d'accord sur les grandes lignes (indentation notamment) par oral, cela devient plus difficile dès qu'on décide d'entrer dans les détails ; et croyez moi, certains Coding style sont tellement détaillés qu'ils vous imposeraient presque la couleur du caleçon...

Voyons maintenant les points essentiels de toute bonne convention de codage qui se respecte.

Conventions de nommage

La façon de nommer les variables et les fonctions (identifiers en anglais) est sans aucun doute le point le plus important d'un projet - et pourtant pas le plus médiatique. En effet, de bonnes règles de nommage permettront la plupart du temps de connaitre en un seul coup d'oeil certaines caractéristiques (au choix : type, portée (globale, locale, publique, privée, ...), appartenance, dépendance, etc.) et de savoir à coup sûr comment nommer une variable selon le contexte. A l'inverse, aucune règle amenera immenquablement à des noms de variables sans aucune logique (toto, tata et compagnie), et provoquera à coup sûr des erreurs parfois difficiles à detecter (exemple : Ah merde, je suis en train de détruire une variable globale là !).

Sur la mise en forme seule, il existe un grand nombre de possibilités, revelant plus du goût qu'autre chose :

  • Jouer sur la casse (Case en anglais) : miniscules, MAJUSCULES, MixedCase ou mixedCase ; et quid des abrévations, faut-il écrire trainSNCF ou trainSncf ? (désolé pour la SNCF, c'est le seul exemple qui m'est venu à l'esprit :)
  • Utiliser le caractère underscore « _ » : liste_double
  • Retirer les voyelles, ou les espaces : lst (liste)
  • Plus généralement, utiliser des variables courtes, cptList, ou des_variables_explicites ?

Là où ça devient interressant, c'est d'associer une mise en forme à un contexte. Par exemple, voici les conventions que j'utilise pour un projet de C++ :

  • Les variables globales et les macros en MAJUSCULES.
  • Les variables locales en minuscules_avec_des_underscores et un nom explicite.
  • Les variables internes à une classe finissent par un underscore_.
  • Les variables statiques dans une classe commencent par un _underscore.
  • Les fonctions membre d'une classe sont enMixedCase avec une minuscule au départ. Les abréviations sont également en minuscule (sauf la première lettre si besoin).
  • Les fonctions non-membres sont précédée du nom du modules si aucun namespace, et en mixed case, comme ça : module_mixedCase ou namespace::mixedCase.
  • Les classes sont en MixedCase avec une majuscule au départ.

Quelques styles célèbres

A vrai dire, le seul style que je connaisse qui porte un nom est le style hongrois (Hungarian notation) qui consiste à préfixer les variables par des lettres indentifiant leur type. Par exemple : ulToto est une variable de type unsigned long (int). Même si la démarche peut sembler interessante, elle s'avère à l'usage peut pratique et peut lisible. Personnellement je la déconseille.

Quelques liens :

Indentation

Indentation
Disposition particulière du texte d'un programme faisant apparaître des décalages de la marge dans l'écriture des divers blocs d'instructions.(source : Le Petit Robert)

L'indentation concerne non seulement la manière de décaler les blocs d'instructions, mais aussi le placement des accolades (ou autre élément délimiteur de bloc). Autant pour le nommage des variables il est facile de faire un peu ce qu'on veut et d'être spécifique à chaque type de programme, autant là, il vaut mieux se rallier à un camp existant ; d'une part parceque tout a déjà été inventé, et d'autre part parceque ça demande moins de temps d'adaption aux nouveaux développeurs.

Attention, l'indentation est un sujet extrêmement trollifère, et il est difficile d'en parler déclancher une guerre de religion. D'ailleurs, je ne vais pas m'en priver !

Quelques styles célèbres

Le K&R, est le style de Brian Kernighan et Dennis Ritchie, les inventeurs du langage C. C'est de loin le plus utilisé et le plus connus (et généralement celui qu'un débutant adopte naturellement). Il est notamment utilisé (avec quelques petites améliorations) pour le kernel Linux. Je ne vais pas y aller par 4 chemins : c'est mon style préféré.

void truc()
{
   if (x > y) {
           faire_un_truc();
  }
 fin();
}

Le Linux Kernel Coding Style est disponible dans les sources du noyau linux (dans Documentation/CodingStyle). Vous pouvez consulter la version disponible dans les sources du kernel 2.6.12.2

Le style GNU, est utilisé (de gré ou de force) pour tous les projets GNU. Dans mon environnement, c'est le deuxième et le seul autre style que je côtoie souvent.

void
truc()
{
  if (x > y)
    {
      faire_un_truc ();
    }
  fin();
}

Voir le Gnu Coding Style, section Formatting.

Pour plus d'informations sur les différents styles d'indentation, ainsi que les arguments pour et contre chacun, je vous conseille la page Wikipedia.

Trollons un peu : pourquoi utiliser des tabs ?

Pour mettre en retrait du texte, il y a deux écoles : les pro-espaces qui prônent l'utilisation de séquences d'espaces et les pro-tabs qui militent pour l'utisation du caractère « tabulation ». Et la guerre entre les deux fait rage depuis des années. Par exemple, taper les deux mots « indentation tabs » dans Google renvoie plus de 360 000 réponses, avec en des titres comme Tabs versus Spaces, Why I prefer no tabs in source code, Indentation wars end here, Space indentation is morally wrong, etc. Bref, tout un programme ! En ce qui me concerne, j'ai choisi mon camp, celui des tabulations, et je vais vous expliquer pourquoi.

A l'origine (c'est-à-dire au temps des machines à écrire), le caractère tabulation permet de déplacer le curseur jusqu'à un point d'arret marqué sur une réglette (tabstop en anglais). Cela évitait à l'opérateur d'avoir à taper une série d'espace pour aligner des éléments. Tiens donc, « aligner des éléments » ça ne vous rappelle rien ? Aujourd'hui, on retrouve le principe des réglettes et des tabstop dans les logiciels de traitement de texte tels que Microsoft Word ou OpenOffice Writer. La tab (parceque c'est une tabulation) permet par exemple de faire un retrait au début d'un paragraphe.

De manière plus générale, dans tout éditeur de texte moderne, il est possible de choisir la taille des tabs. Concrètement, vous pouvez définir qu'une tab fera 2 caractères ou 4 ou 8 ou autant que vous voulez ! Un seul caractère ASCII permet donc non seulement de remplacer efficacement une série d'espaces (et ainsi d'avoir un fichier plus petit), mais aussi de laisser celui qui consulte le fichier la possibilité de modifier son apparence visuelle par simple réglagle de son éditeur ! Exemple : vous avez un grand écran avec une grande résolution et vous préferez les tabs de 8 caractères ? Pas de problème. Vous passez le fichier à un ami qui a un tout petit écran et préfére des tabs de 2 caractères ? Pas besoin de toucher la moindre ligne du fichier, un simple réglage suffit.

Pour en savoir plus, voici quelques liens très utiles :

Trollons un peu plus : pourquoi le GNU Coding Style est-il une erreur de la nature ?

Je n'aime pas Richard M. Stallman (RMS). Certes, il a fait énormement pour le libre (c'est l'inventeur de gcc, de la GPL, etc.), mais c'est un intégriste borné qui ne voit malheureusement pas plus loin que le bout de son clavier et qui se permet de donner son avis sur tout et n'importe quoi (oui, comme RAGE2000, cqp). A chaque fois que j'en entend parler, il a encore sorti une connerie plus grosse que lui. Tiens par exemple, la dernière fois il ordonnait à ses fidèles de ne pas acheter les livres Harry Potter (à quand une intifada ?). Et la fois d'avant, il se permettait de juger le projet de Constitution Européenne et d'affirmer que c'était une bonne chose d'avoir voter « non » (c'est un américain, qu'est-ce qu'il y connait ?). Et parmi toute les idioties de RMS, celle qui me pourri le plus la vie au quotidien est son GNU Coding Style...

Première chose : déclarer les fonctions sur deux lignes (ou plus !). Les ayatollah affirment que ça permet de retrouver facilement l'implémentation d'une fonction parmis des centaines de milliers de lignes de code. Explication : il leur suffit de rechercher la ligne commençant directement par le nom de la fonction recherchée. En effet, si on cherche le nom de la fonction simplement, on va tomber, non seulement sur la déclaration, mais également sur tous les appels à ladite fonction. Cet argument est valable, certes, mais on peut tout à fait trouver une astuce similaire pour un autre style, par exemple avec le K&R il suffit de rechercher une ligne contenant le nom de la fonction et aucun caractère « ; », ou bien une ligne contenant le nom de la fonction directement suivie d'une ligne débutant par une accolade... Une autre solution est d'utiliser un IDE moderne, qui permet de se rendre directement à l'implémentation par simple clic. Ah oui, mais ça, contraire à la religion des GNUistes, qui doivent utiliser GNU emacs.

Deuxième chose : les « demi-niveaux » d'indentation ; c'est-à-dire le placement des accolades à mi-chemin entre les deux blocs, comme ceci :

if (x > y)
  {
     faire_un_truc ();
  }

Ce que j'en pense, c'est qu'en plus d'être illisible, ça n'a pas grand interet. Mais bon, je veux bien admettre qu'il s'agit là d'une notion tout à fait subjective ; comme dirait ma grand-mère : Les goûts et les couleurs.... Alors discutons sur des choses objectives.

Premièrement, est-ce bien moral de « couper » l'indentation en deux, et de créer ainsi ces « demi-niveaux » ? Je ne crois pas. Ca casse l'imbrication et ça perturbe la lecture : la notion de « demi » n'est pas naturelle et on a l'impression que le bloc est en fait 2 niveaux en dessous.

Deuxièmement, la façon d'indenter. Pour créer ces « demi-niveaux », il faut impérativement utiliser des espaces au lieu des tabulations (voir ci-dessus). Cela à 2 inconvenients majeurs :

  1. Il faut plusieurs caractères « espace » pour imiter un seul caractère « tabulation » ; ça prend plus de place pour le stockage (essayez avec un fichier de quelques centaines de lignes pour voir, la perte peut très vite se compter en kilo-octets), et donc rend la compilation un poil plus longue (parceque fichier plus gros à parser), ainsi que les commits et autre manipulation.
  2. Les développeurs ne peuvent pas modifier la valeur de l'indentation selon leur goûts (2, 4, 8, ...)

Pour conclure ce petit troll, je vais citer Linus Torvalds (le papa du noyau Linux) : First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture. (« Avant tout, je vous suggère d'imprimer une copie du GNU Coding style, et de NE PAS le lire. Brulez-le, c'est un grand geste symbolique. »).

Encore plus loin...

Même si ces deux notions (nommage et indentation) sont les plus importantes (et les plus celèbres), il y a bien d'autres point à préciser si on veut rédiger un coding style complet. Parmi celles-ci :

  • Les espacements. Faut-il écrire : m = moyenne(a,b); ou m=moyenne(a,b); ou encore m = moyenne(a, b); ?
  • Les noms de fichiers, et l'arborescence du projet. Les noms de fichiers doivent-ils être en miniscules uniquement ? Faut-il faire une classe par fichier ?
  • On peut aller encore plus loin, en imposant par exemple un nombre de lignes limite pour les fonctions, un nombre de variable maximum, ou, comme je le disais en introduction, la couleur du caleçon à porter pour coder !

Bref, comme vous avez pu le constater, les standards de codage forment un sujet très vaste et particulièrement... délicat. Les guerres sont nombreuses, très nombreuses, à tel point qu'il est difficile d'en parler sans que ça dégénère (essayer de poser une question sur un forum de geek en postant un morceau de code : à tous les coups quelqu'un va venir vous dire que votre coding style n'est pas bon !). Et encore, là je n'ai survolé que les points les plus connus...

Note : Saviez-vous que, lorsqu'on parle de typographie, on dit une espace ?