S’il y a une chose que l’on remarque à force de travailler sur du code source que l’on n’a pas soi-même engendré, c’est que… On n’aime pas les autres.
Non, franchement, pourquoi indenter son code comme ça ? Si on peut appeler ça indenté !… Pourquoi cette accolade à droite, cet espace à gauche ? Et lui qui n’aère rien… La touche Entrée, tu connais ? Hé ! C’est pas pour autant qu’il faut faire de l’hyper-ventilation ! Mais c’est quoi ce bord** !? Je comprends rien à ce qu’il a codé ce c** ! Et puis, qui utilise encore les underscores dans les noms de méthodes ou de variables !? Le camel case, c’est pour les chiens ? HEIN !?

Bref ! Trêve de douloureuses réminiscences : l’hyper-tension est un fléau, alors respirons un bon coup et poursuivons. Il faut pourtant bien l’avouer : lire du code source, c’est sympa seulement quand on l’a écrit pour soi. Et encore, passe les mois et les tendances, et nos soi passés deviennent eux-même les ennemis, de ceux que l’on maudirait pour l’éternité. Pourtant, dans langage de programmation, il n’y a pas que programmation : il y a langage. On a tendance à l’oublier, mais un langage sert à communiquer. Communiquer avec la machine, certes, mais pas seulement : communiquer entre développeurs également.

Mais dans le brouhaha de ces discussions, qui a raison ? Qui devrait-on suivre dans les errances de la programmation ? Ce billet s’adresse à vous, ô développeurs aux existentielles questions, ô chercheurs de vérités parfaitement normées. Nous ne parlerons pourtant aucunement de vérité, mais plutôt de standardisation : parce qu’à défaut de tyrannie de la pensée, on fera ce que l’on peut avec notre belle démocratie partagée…

Alors allons-y ! Anarchistes et artisans de la haine, allez donc faire un tour, nous on a quelques trucs à passer en revue 🙂

PHP STANDARD RECOMMANDATIONS
Au sein de la communauté PHP, s’est formé un groupe nommé PHP FIG : PHP Framework Interop Group. Les membres éminents de ce rassemblement ont pour objectif commun la standardisation de méthodologies de développement PHP. En ce sens, cinq jeux de normes ont été présentés et se répandent joyeusement (Symfony2 en est le meilleur exemple) :

– PSR-0 : Autoloading Standard (standard de répartitions des classes PHP par (pseudo-)namespaces et chargement par autoload)
– PSR-1 : Basic Coding Standard (recommandations sur l’organisation du code PHP et les règles de nommages entre autres)
– PSR-2 : Coding Style Guide (recommandations sur l’écriture du code : positions des accolades, sauts de ligne, etc.)
– PSR-3 : Logger Interface (standard pour l’écriture de fichiers de logs)
– PSR-4 : Improved Autoloading (encore de l’autoloading, en mieux)

CSS GUIDELINES
Eh oui ! Même une feuille de styles CSS peut devenir le théâtre du chaos absolu… À première vue, la marge de manoeuvre semble étroite et pourtant, de nombreuses propositions existent.

CSS Guidelines est l’une d’entre-elles : cette proposition de standardisation est proposée par Harry Roberts, un architecte front-end du Royaume-Uni. Depuis longtemps disponibles sur Github, ses recommandations sont désormais disponibles en français sur un joli site dédié.

GOOGLE JAVASCRIPT STYLE GUIDE
En particulier quand on débarque du monde PHP, JavaScript peut sembler être un sac de noeud dont on abandonnerait vite l’idée de se dépêtrer (beaucoup semblent avoir abandonné d’ailleurs). Si d’excellentes sites, comme le Mozilla Developer Network, permettent d’aprivoiser la bête, subsiste néanmoins la question de la standardisation.

Google a mis à disposition la standardisation que ses développeurs s’accordent à suivre dans leurs projets JavaScript. Même si le guide ne paie pas de mine, il n’en demeure pas moins très intéressant, notamment parce que chaque proposition est argumentée.

PHPDOCUMENTOR ET JSDOC
Faut-il encore présenter phpDocumentor ? Depuis de nombreuses années, ce projet est la référence en terme de documentation du code source PHP. Si vous ignoriez son existence, il est urgent de vous rattraper !

Moins connu mais tout aussi utile, JSDoc est à JavaScript ce que phpDocumentor est à PHP. Question syntaxe des commentaires, vous ne serez pas dépaysés : c’est sensiblement la même chose.

CONCLUSION
Et nous nous arrêterons là : il y a déjà beaucoup de choses à assimiler, et beaucoup de questions à se poser. Mais peut-être qu’au fil de votre lecture quelques réponses vous auront illuminé(e)s ?

Bien entendu, ce ne sont que des recommandations parmi d’autres. Libre à chacun de se ranger aux côtés de telle ou telle proposition. Cependant, si l’homogénéité parfaite reste une utopie, elle n’en demeure pas moins un axe incontournable dans la mise en place de règles de développement collaboratif, voire d’une charte de qualité, qui permettrait à un groupe de développeurs donné de travailler plus efficacement ensemble. Et en évitant de s’entre-tuer.

Gaëtan