Tiens, c’est marrant, j’allais justement faire un post un de ces quatre sur mes conventions de programmation, histoire de vous demander votre avis et pour voir quelles sont les vôtres. Même si je n’ai pas été invité à la fête, cette chaîne initiée par Godefroy et relayée par Babozor tombe à point nommé et je la reprends !
Tout d’abord, allez jeter un coup d’oeil à cet exemple de code PHP que j’ai écrit pour le site Pikaboo.
Notations
J’utilise des notations relativement standard : UpperCamelCase pour les noms de classes et lowerCamelCase pour les noms de fonctions et méthodes. Par contre, pour les variables, j’écris tout en minuscules et je sépare les mots par le caractère underscore. Depuis peu, j’essaye également d’utiliser cette notation (minuscules + underscore) pour les class et id en HTML (afin de répercuter cette notation en CSS).
Indentation
J’indente uniquement par tabulation (de la taille de quatre espaces), aussi bien pour PHP et JavaScript que pour HTML et XML. Je trouve qu’il s’agit du truc le plus important pour obtenir un code lisible. Dans certains langages (Python par exemple), il est même obligatoire de travailler de cette façon.
Accolades
Ma façon de placer les accolades me vient de je ne sais où mais je la trouve efficace : je place l’accolade ouvrante à la fin de la ligne contenant la déclaration de fonction ou la structure de contrôle (if, while, foreach, etc.), précédée par un espace. Par exemple :
foreach (...) {
...
}
ou
function myFunction(...) {
...
}
Autre détail important : même si le contenu d’une condition ou d’une boucle comporte une seule instruction, j’utilise les accolades. Cela évite de les ajouter si on rajoute une instruction mais ça évite surtout des arrachages de cheveux futurs.
Espaces
La, c’est un peu freestyle. J’utilise parfois des espaces pour séparer les paramètres dans une fonction, séparer les instructions dans une boucle for, autour des opérateurs de comparaison mais pas toujours ! Ca doit dépendre de mon humeur du moment… Par contre, je place un espace après le nom des structures de contrôle pour ne pas les confondre avec des déclarations de fonction (voire les exemples plus haut).
Guillemets
J’utilise toujours les simple quotes sauf si je n’ai pas le choix : variable dans la chaîne, tabulation (\t), retour à la ligne (\n) ou retour chariot (\r), etc. Ce n’est pas seulement une convention, c’est plus performant de bosser comme ça (enfin, c’est ce qu’on m’a dit, je n’ai pas fait de benchmarks, j’avoue).
Commentaires
Je suis mauvais élève pour ça. J’écris peu de commentaires. Je me dis toujours que je commenterai comme un fou et que je générerai de la documentation avec phpDoc mais je le fais rarement (jamais en fait). Par contre, quand un client m’ennuie, je mets des insultes à son égard dans les commentaires (je déconne).
En gros, je suis assez pointilleux sur certains points mais pas du tout sur d’autres. Y a t-il de bonnes pratiques officielles à ce sujet ? Quoi qu’il en soit et je répète ce que j’ai déjà lu à de nombreux endroits : peu importe la convention qu’on utilise, l’important est d’en suivre une et de s’y tenir.
Je refile la chaîne à qui le veut.
Le blog de Vincent Battaglia 
En ce qui concerne le choix des single/double quotes, je ne pense plus qu’il y ait réellement une différence dans les versions actuelles de PHP.
En général, j’ai les même conventions que toi. Excepté pour les espaces pour lesquels ce n’est pas du tout freestyle, j’ai une certaine notation où je mets des espaces à peu près partout (ça rend plus visible le code je trouve). Excepté entre les nom des fonctions/opérateur et les paramètres.
Je ne vois pas comment on peut confondre entre les deux donc bon ^^
LikeLike
@tommy: oui ca n’a pas changé, pour php les simples quote entoure une simple chaîne, alors qu’en double quote c’est une chaîne à parser pour y trouver d’éventuels caractères spéciaux ou variables. moi (issu des règles claroline) j’utilise des concaténation de chaînes simples et de variable plutôt que d’utiliser des chaîne à parser avec variable incluse.
Ca complique un chouya la lisibilité mais ca le rend plus rapide et ca le rend lisibile de manière identique dans les editeurs qui ne savent pas highlighter les variable qui sont DANS les chaines.
Je n’utilise jamais les tabulations ‘pour les même raison que vinch’ 🙂 en effet l’indentation est importantes et je veut qu’elle soit la même, quelque soit l’éditeur et sa configuration. Même si la plupart donnent un rendu de 4 espace pour 1 tab, ce n’est pas le cas avec tous, donc je mets moi-même 4 espaces.
Il faut savoir que j’ai travaillé essentiellement dans des codes opensources, où l’on ne maitrise pas du tout l’environnement de travail de tous les acteurs. Et c’est un critère important dans le choix de certaines conventions de codages.
Pour les commentaires j’essaye d’en mettre de 3 sortes.
les phpDoc
Les marqueurs (déclaration, traitements, affichagee…)
Les @todo @fixme @bug …
J’avais un collègue qui avait une autre habitude pour les commentaire, c’est de mettre la “doc du script” dans un gros bloc de commentaire en début de script. Ca avait l’avantage que la doc suivait toujours le code. mieux que dans un txt a coté ou dans un wiki
LikeLike
Merci pour ton avis d’expert.
Pour les espaces, je trouve ça lourd de devoir en taper quatre à chaque fois. Si tu es au troisième niveau d’indentation, tu en tapes douze ? Enfin, j’imagine que ton éditeur se remet directement au bon endroit quand tu fais un passage à la ligne et que du coup, tu ne tapes jamais plus de quatre espaces à la fois, mais quand même…
LikeLike
Comme toi, sauf:
pas de tabulations mais des espaces (géré par l’éditeur)
je laisse des lignes blanches entre les méthodes quand même!
pas trop fan de l’accolade ouvrante Java-style 😀
LikeLike
L’essentiel dans les conventions est que si tu travailles en groupe est que tout le monde respect la même notation.
Comme je l’ai dis précédemment dans tes commentaires, il faut toujours avoir un code compréhensible et clair qui pourra (ou pourrait) être repris par un tiers personnes.
PS: cfr. mon poste à ce sujet sur mon blog.
LikeLike
de même pour tout sauf que j’utilise pour les variables un petit truc vieux datant de matusalem…
J’ajoute au début de la variable une lettre permettant d’identifier le type.
Du style : oObject , iInt, aArray,…
Quand on a juste qlq lignes de code, ca peut paraitre ridicule mais quand on travaille dans un framework complet, ca aide bcp.
LikeLike
Ah oui, “quelqu’un” m’avait dit que vous travailliez comme ça 😉 C’est vrai que ça peut être utile quand on travaille sur de gros trucs.
LikeLike
…”Quelqu’un”… huhuhuh
LikeLike
J’aime aussi quand les règles sont compatible avec la réindentation automatique. Ce qui me permet de lancer cette réindentation avant de commencer à coder.
Cela pose un problème. Plus on bosse avec des gens qui ne respecte pas les convention plus on a du bruit dans les diff ou alors il faut faire réindentation, commit , code, commit,…
LikeLike
Personnellement, j’utilise E-TextEditor (proche de TextMate mais disponible sous Windows) et il gère tout comme ce dernier, les “soft tabs”. Je règle donc une fois pour toute qu’un “soft tab” = 4 espaces (par exemple) et je peux donc utiliser la touche tabulation pour faire 4 vrais espaces d’un coup. 🙂
LikeLike
Je passe par ici à la recherche au hasard de python … aouch, justement ça fait mal de revoir du code PHP full frontal sans une once d’ORM ! :-s
LikeLike
Un ORM c’est bien, mais quand tu as trois requêtes SQL sur tout le site, je ne vois pas l’intérêt… Alors, quand on ne connait pas les contraintes, on … sa … 🙂
LikeLike