Mes conventions de codage...
Par NiKo le mercredi 23 juillet 2008, 21:21 - Dev
- Lien permanent -
29 commentaires -
Tags :
... sont celles des projets sur lesquels je me greffe. C'est en effet pour moi une forme de respect que d'appliquer les standards de codage partagés par une communauté (ou une équipe) de développeurs : ainsi, on maximise les chances de se comprendre et on minimise les coûteuses phases de communication entre geeks introvertis[1] 
En effet, rien de plus pénible que de reprendre le code de quelqu'un qui a pris des libertés avec des conventions établies à ce niveau, l'apothéose étant obtenue avec ce genre de code :
<?php class Ma_superClasse { function dire_coucou ( $popol) { echo 'coucou ' . $popol . ' !' ; } function DireAuRevoir($Popol ) { print "Au revoir $Popol !"; } }
Je force bien évidemment ici le trait, mais tout le monde est déjà tombé sur ce genre de code illisible, qui multiplie par 10 votre temps d'intervention sur ce dernier et divise par 1000 votre passion pour la TMA.
Bien entendu, il peut arriver de produire du code sur un projet ne nécessitant l'utilisation d'aucune brique logicielle existante. Auquel cas vous pouvez librement appliquer vos propres standards de codage, l'important étant ici qu'ils soient cohérents et constamment appliqués. S'il peuvent être ceux d'un projet open source existant reconnu, cela augmentera la sympathie potentielle à votre égard de futurs intervenants sur votre code 
Je noterai quand même en vrac quelques bonnes pratiques générales globalement reconnues et appréciées :
- être explicite,
- indenter son code,
- documenter son code,
- à choisir entre les deux, privilégier la lisibilité à la concision,
- utiliser des noms de variables, de classes, de méthodes, de fonctions et d'arguments parlants,
- utiliser des noms anglophones,
- utiliser des motifs de conception connus.
Personnellement, j'ai mes petites préférences et tout comme Oncle Tom - qui m'a gentiment refilé cette chaîne[2] - j'ai tendance à appliquer les standards de codage de symfony, que je trouve homogènes et cohérents. Mais ce sont là bien évidemment essentiellement des questions de goûts et de couleurs.










29 commentaires (Ajouter un commentaire)
Moi, je dis vive le Ctrl + Shift + F sous Eclipse! (format)
Effectivement si tout le monde appliquait ces règles ça simplifierait grandement le travail.
J'envie Python pour ce côté là avec ses conventions bien posées.
Tout à fait d'accord sur les conventions. Moi qui, pour l'instant, bosse exclusivement en TMA, je peux dire que j'en vois passer, des horreurs.
Pour moi, le principe le plus important reste le principe KISS. Quoi qu'on en dise, un bon code est un code simple.
(N'empêche, les espaces pour indenter, ça pue)
J'ai beaucoup de mal avec les accolades ouvrantes mises une ligne sous le nom de la classe, de la méthode ou de la fonction. Je n'ai jamais compris l'intérêt...
Sinon, ouais nique les indentations à espaces, vive les tabulations.
@thibault:
Super ton site, et particulièrement ce lien que j'y ai trouvé : J'en pleure encore de rire
@Quentin:
> J'ai beaucoup de mal avec les accolades ouvrantes mises une ligne sous le nom de la classe, de la méthode ou de la fonction. Je n'ai jamais compris l'intérêt...
C'est quoi l'intérêt de les laisser sur la même ligne ?
Oui, je sais, un troll aussi facile, je suis vraiment très faible...
Je suis un farouche utilisateur des tabulations pour indenter, mais j'ai le désagréable sentiment que je vais rapidement devoir me faire aux espaces.
Faudra quant même m'expliquer pourquoi les éditeurs PHP dans Eclipse sont aussi en retard. Que ce soit pour Java ou Javascript, les éditeurs permettent de définir différents profils, chacun avec ses règles de formatage, et de les associer aux projets. Plus besoin de se soucier des histoires d'espaces ou d'emplacement des accolades, l'éditeur gère tout tout seul. Mais pour PHP, les réglages sont ridiculement pauvres, que ce soit avec PDT, PHPEclipse, Aptana... Ok le formattage ne représente qu'une partie des convention de codage, mais c'est dommage que les éditeurs soient aussi en retard
Les conventions de codage de symfony sont pas mal du tout.
Il y a juste l'indentation par des espaces au lieu des tabulations auquel je n'arrive pas à m'y faire :/
je sais qu'il est interdit de nourrir les trolls, mais... j'utilise toujours la touche tab (plus pratique), mais sous Notepad++ je remplace chaque fois mes tabs par 4 espaces avant de sauver, et quand je fait du C/C++ c'est sous Code::Blocks, lequel me les convertit automatiquement en espaces
sinon, 100% d'accord avec ta liste de points à respecter

je rajouterais peut-être un point: à l'image de la philosophie linux, préférer une séquence de commandes simples à une artillerie lourde qui fasse tout d'un coup
Pour assurer le contrôle et le respect des conventions de codage, il existe maintenant pour PHP des solutions similaire à Checkstyle (http://checkstyle.sourceforge.net) pour Java (Je pense entre autres à http://beautifyphp.sourceforge.net/).
Un outil très pratique dans ce domaine serait quelques choses comme Jalopy (http://jalopy.sourceforge.net/) pour PHP. Ce genre d'outil ne permettra pas de renommer des fonctions ou des classes ne respectant pas les conventions établises, mais au moins il peut "recadrer l'indentation".
C'est aussi pour ces raisons que j'aime python, et qui oblige le programmeur à utiliser ces conventions (ce qui facilite énormément, comme tu dis, la TMA)
(être explicite, indenter ... etc ...)
Sinon, faut indenter avec des espaces, et non avec des tabulations !
Les espaces seront toujours identiques qqsoit l'editeur ... alors que les tabulations peuvent varier (2,3,4, 8 générallement). et ça peut devenir hautement illisible dans un editeur. D'autant plus que de nos jours, les bons éditeurs simulent très biens les indentations avec espaces ...
Vive le checkstyle et le "Ctl + Shift + F" sous Eclipse
Et j'ajouterais cela à ta liste :
- Faire de lignes courtes (moins de 120 caractères, parce qu'avoir à scroller horizontalement c'est une horreur, tien ça me fait penser à l'EeePC 701 ça...).
- Faire des classes courtes (moins de 1000 lignes).
- Faire des méthodes courtes.
La lisibilité du code en dépend...
ben pareil que 1ace, moi je dit à eclipse de remplacer mes tabulations par 4 espaces, tout se passe bien et je suis pour l'utilisation d'espaces, plus harmonieux que les tabs et transparent à l'utilisation quand on configure bien son IDE.
Julien> Tout à fait exact !
Suivre les conventions du projet, soit... Mais pour tes propres projets en interne, c'est quand même mieux de définir quelque chose de "standard".
Et ne pas oublier le cas : tu importes un module codé dans un standard (celui de son projet) avec une application (qui suit un autre standard).
C'est pour ça que les conventions globales peuvent être un mal nécessaire, aussi.
Tant que les conventions restent cohérentes, et rendent le code source lisible humainement, c'est plutôt une bonne chose ("readability counts", comme on dit chez nous). La PEP 8 de Python est généralement adaptable à tout autre langage (reste la question des accolades, mais je n'ai pas envie de nourrir ce troll-là précisément)
http://www.python.org/dev/peps/pep-...
Une autre constante dans Python : coder en anglais. C'est triste à dire, mais c'est comme ça... À part pour des langage comme Baguette On Snails, l'anglais reste la "Lingua Franca" de l'informatique actuelle (jusqu'à ce que le mandarin balaie tout) et il vaut mieux éviter le mix frengliche qui rend le code plus difficile à comprendre et à faire évoluer. Une règle de base c'est aussi : "ne me fais pas réfléchir". Je ne devrais pas, en principe, avoir à me poser la question plus d'une seconde sur le nom d'une méthode... "attends... c'est 'get_chose_importante' ? ou 'get_important_thing' ? ou 'getImportantThing' ?"
Établir des conventions, c'est aussi éliminer du temps de CPU dans ton cerveau.
Bon. Assez parlé... J'ai un stagiaire sur le feu... Il utilise des noms de variables et de classe imbittables, et il n'a pas encore reçu son quota de coups de fouet.
Mais sous le même éditeur, toutes les tabulations ont la même taille, l'argument est mauvais.
D'ailleurs, l'indentation est le plus dur à voir. Il faut afficher les caractères non imprimable.
Il y a des éditeurs qui ont des macros, templates etc.
Dedans, on y met ses indentations, c'est pas pris en compte par les réglages après.
Par exemple, quand je crée une fonction, il va m'indenter automatiquement dans l'accolade, mais il va me mettre une tabulation alors que l'éditeur est réglé en espaces.
Comme dit plus haut, le plus pratique finalement, c'est de reformater avec une action.
J'ai jamais essayé encore, j'me demande si ça casse les alignements des "=" et tout
Concernant l'utilisation de l'anglais pour le codage, je veux bien, mais j'ai deux arguments plutôt en faveur de la langue du projet :
1. les termes fonctionnels sont en général des (abréviations de) termes français propres au métier. Je me vois mal traduire « Entité de Production » juste pour le bon plaisir d'avoir un joli terme anglais (que je devrai sans doute abréger au final).
2. quand on se base sur un ou des framework(s), qui sont codés en anglais, on voit tout de suite ce qui a été développé par l'équipe du projet, puisque les noms sont en français.
Par contre, pour les briques de base (getters et setters par exemple), inutile de dire que je laisse getBidule() et setBidule() ! D'autant que le framework sur lequel je bosse a besoin de cette convention pour sa tambouille interne...
Par contre, je me souviens d'un stage à Taiwan où j'ai particulièrement déchanté quand j'ai enfin pu mettre les mains dans le code... tous les commentaires étaient en chinois, sauf que j'étais sous Windows en français et avec un Visual Studio en français... et donc j'avais des jolis hiéroglyphes à la place des commentaires. Bon, de toute façon à l'époque je savais pas lire le chinois, alors que ça s'affiche bien ou pas m'aurait pas aidé à grand'chose ! Enfin tout ça c'était du temps où on me forçait à faire du C#...
Bref, moi ça me fait bien rigoler toutes ces querelles de codage
«
— Tu peux t'la carrer où j'pense ta tabulation de mes deux !
— Ah ouais ? Tu veux t'batt', toi et tes espaces à la mords-moi-l'nœud ?!
»
@Pierre:
> les termes fonctionnels sont en général des (abréviations de) termes français propres au métier. Je me vois mal traduire « Entité de Production » juste pour le bon plaisir d'avoir un joli terme anglais
Comme tu le dis plus bas dans ton commentaire, je te souhaite sincèrement de n'avoir *jamais* à offshoriser tes développements. J'aimerai assez voir la tête d'un indien ou d'un polonais devant une
$EntiteDeProductionC'est sûr... tiens tu fais bien de parler des Indiens, j'ai un copain qui est actuellement en Inde pour aider à la mise en place de l'offshore du projet sur lequel il bosse... je suis sûr qu'il aura plein de super anecdotes à me raconter d'ici quelques semaines !
Enfin, si ça peut te « rassurer », la plupart des termes métier restent abstrus à la plupart des développeurs un bon moment ! C'est génial en phase de validation, quand ils manipulent des données et des éléments dont ils ne comprennent pas la signification (je le sais, j'ai commencé comme ça !).
Et puis de toute façon, ce qui est bien c'est que tout est abrégé. Entité de Production, c'est naze, alors qu'EDP c'est tellement plus fnu ! Du coup, getEDP, que tu sois français, polonais ou chinois, ça a a peu près la même signification : trois lettres qui ne veulent rien dire
Pierre> C'est dans ce genre de cas que la (php|java|etc.)doc rédigée en anglais est clairement indispensable, sans oublier une page de wiki de définitions de termes métier
Moi je dis, une seule solution pour éviter les problèmes d'indentation: on met tout sur une seul ligne.
Rhalala, ce troll espaces vs tab, qu'est-ce qu'il part vite et bien
J'hésite à en remettre une couche, rien que pour le plaisir.
L'avantage des tabulations, c'est que justement on peut configurer son éditeur avec la taille d'indentation qu'on veut. L'argument "les tabs, ça s'affiche pas partout pareil" n'est pas valable : c'est exactement le but recherché.
Désolé, je n'ai pas pu me retenir :P
thibault> T'as raison, il est trop bon ce troll
Perso ce qui me dérange avec les tabs, c'est que quand on balance un snippet de code sur une page web dans une balise <pre/>, elles s'affichent à huit espaces par défaut, et donc ça pue (je suis fort en troll de tabs, hein ?).
@NiKo: je suis sûr que tu la lancé volontairement, ce débat stérile :P
L'argument "L'argument \"les tabs, ça s'affiche pas partout pareil\" n'est pas valable : c'est exactement le but recherché." n'est pas valable : le but de la convention est que tout le monde fasse pareil, pas que chacun la personalise à son goût.
mais:
L'argument "L'argument \"L'argument \\\"les tabs, ça s'affiche pas partout pareil\\\" n'est pas valable : c'est exactement le but recherché.\" n'est pas valable : le but de la convention est que tout le monde fasse pareil, pas que chacun la personalise à son goût." n'est pas valable :
[insérez votre troll ici]
remarquez l'échappement des guillemets, pour que votre parser (aussi appelé cerveau) ne plante pas
... je suis déjà dehors ==>[]
Content de voir que tu as retenu la signification de TMA
Y a un an, tu faisais moins le cador ;-P
~~~~> []
(je sais ce commentaire ne sert strictement à rien)
Pensée récursive !!!!! http://www.nojhan.net/geekscottes/i...
Oh oui, donne moi des leçons NiCoS
La devise normande étant "p't'être ben qu'oui, p't'être ben qu'non", j'aurais tendance à prétendre qu'entre tab et espaces, autant prendre les deux
En règle générale je favorise les tabs. Par contre pour certains alignements particuliers, les espaces sont nécessaires.
Un petit exemple qui me vient à l'esprit :
Quand on a une condition multiple, et que l'on veut éviter une ligne trop longue, on peut vouloir la mettre sur plusieurs lignes. Dans ces cas pour une meilleur lisibilité il est préférable que les différents composant de la condition soient alignés verticalement. Dans ce cas le tab sert à mettre au niveau d'indentation et les espaces servent à aligner :
(ça va sûrement rien donner ici, faudrait pouvoir visualiser les caractères blancs)
function foo($bar, $ba, $papa) {
if($bar === 'bar' &&
is_null($ba) &&
$papa === 'papa') {
$toto = $tata;
}
return true;
}
Comme on le voit pas je précise que dans ce cas je met un tab plus trois espaces devant les lignes 3 et 4. La ligne 2 (if) ayant un tab, et la ligne 5 deux.
Merci pour le troll, ça fait du bien de se lâcher de temps en temps
Pour le troll tab/espaces :
L'avantage des tabulations c'est que si tu aimes voir des indentations de largeur 2 espaces et que ton collègue en préfère 4, avec les tabulations c'est configurable dans l'éditeur alors qu'avec les espaces tu perds des heures à essayer de convaincre ton collègue.
Donc à moins de vouloir faire des l'ASCII Art en codant nos proses en C/C++/Java/PHP, les espaces ça pu. (je suis un ancien utilisateur des espaces (3) jusqu'à ce que je me fasse engueuler par un pote geek avec qui je codais)
L'accolade sur la même ligne :
Alors déjà, quand je code en C et C++, je met sur la ligne d'en dessous et lorsque je suis en Java ou PHP, je met sur la même ligne (conventions).
J'ai une préférence pour l'accolade à la ligne pour 2 raisons :
- Le bloc est plus lisible car les 2 accolades sont au même niveau.
- Lorsqu'on est en phase de débuggage, on peut très rapidement désactiver un test pour le passer à true en commentant la ligne du if. Les accolades deviennent alors superflue mais ça compile toujours. Si on a mis l'accolade sur la même ligne, il faut aussi commenter l'accolade fermante.
Mais le plus important, c'est surtout de ne pas mélanger les conventions et de s'en tenir à une seule par projet.