Mes conventions de programmation…
Publié le 17 July 2008, par Babozor dans la catégorie Développement, Gestion de projet, Organisation, méthodo...Normalement je ne réponds pas aux espèces de chaînes débiles de bloggers qui se taggent avec des sujets stupides (genre “5 trucs que vous savez pas sur moi”… on s’en fout en général), mais là exception à la règle, puisque Godefroy (le Monsieur derrière Eklablog) propose une chaîne spécial dev: “Mes conventions en programmation”
Allez zou un petit exemple de code:
Notation
Moi aussi j’utilise la notation lowerCamelCase pour tout mes nommages: variables, fonctions, classes, méthodes, etc… avec une petite spécificité: tout en anglais (pour un portage plus simple si un autre dev parle pas français)
Indentation
Tabulation 4 espaces aussi
En général j’indente par bloc (après un if par exemple) sans les accolades, pour avoir un code le plus structuré et le plus lisible possible
Accolades
J’avoue, j’aime beaucoup les accolades 
En général je saute une ligne avant le début d’une accolade, ça fait une ligne de plus, mais je trouve qu’on gagne beaucoup en lisibilité, fermeture au même niveau que l’ouverture, en sautant une ligne.
Je mets des accolades même pour les instructions “mono-lignes”, une mauvaise habitude sûrement, mais je trouve ça plus lisible (décidément…)
Espaces
Je mets très peu d’espace en fait, en général entre une instruction et sa condition (un if par exemple)
Pas d’espace pour les opérandes… (= etc…)
Je trouve que les espaces un peu partout nuisent à la lisibilité
Guillemets
En général j’utilise la simple cote ‘, sauf pour les caractères d’échappement (\r \t, etc…) et pour mes requêtes SQL
Commentaires
Je commente peu, sauf quand le besoin s’en fait vraiment sentir pour un calcul vraiment funky ou qu’un script doit être compléter, etc…
Ma façon de coder et de normmer mon code a peu évolué ces 2-3 dernières années, puisque je pense avoir trouvé une méthode pour pouvoir lire un code de façon rapide et efficace, je garde un code compacte pour les opérations communes, mais avec une bonne indentation et des retours à la ligne pour identifier rapidement les divers conditions (if, for, etc…) ce qui me permet d’avoir une première vision précise et rapide de ce que fait le code.
Mon soucis reste toujours la lisibilité et le portage pour d’autres codeurs… donc j’essaye d’apporter un soin tout particulier au nommage des divers fonctions et variables. J’utilise pas mal des préfixes: trois lettres et un underscore, par exemple pour les user: usr_blablabla pour les variables intermédiaires, sinon le nommage est en anglais en respectant le lowerCamelCase.
Bon je repasse le bébé à Boldr, Kilgore, Dame Tartine, Seb et Damien (ça leur apprendra tiens…)
le 17 July 2008 à 10h30
Je dois être idiot mais :
dans ton screenshot et dans tes explications tu dis utiliser le lowerCamelCase pour toutes tes variables mais tu donnes comme exemple : usr_blablabla et dans ton screenshot on voit : mbr_id.
de plus dans le screenshot on voit ausis pas mal de variables du style $membre et tes commentaires sont en français ?!?
D’ailleurs, si tu codes en anglais, tu devrais aussi documenter en anglais …
Dernière remarque de pinailleur, tu dis utiliser les espaces pour ta programmation, c’est PAS BIEN DU TOUT ! Je m’explique : si tu indentes avec 4 espaces alors il sera difficile pour un autre programmeur de réduire visuellement cette indentation puisque les 4 espaces seront tjrs là.
En utilisant les tabulations tu économises des octets (ok c’est minime) et tu augmentes la portabilité, en effet la plupart des éditeurs permettent de modifier visuellement la longueur d’une tabulation.
Maintenant ça reste une habitude bien sûr mais j’aimerais avoir ton avis sur espaces vs tabs.
Merci pour l’article tout de même !
le 17 July 2008 à 10h38
@Vincent: effectivement, j’ai pris le premier bout de code qui me tombait sous la main (une importation de données pourries en fait) donc ce n’est pas super représentatif de la façon de code “proprement” je suis d’accord
Pour l’indentation, j’utilise une tabulation (qui est l’équivalent de 4 espaces) et non des vrais espaces…
Même remarque pour l’anglais, puisque ce script est destiné à moi et personne d’autre… la prochaine fois je tenterais de screenshoter un meilleur exemple, tu a raison
le 17 July 2008 à 10h43
Ok j’avais juste eu du mal à comprendre le concept de tabulation = a quatre espace.
C’est juste que ton logiciel t’affiche 4 espaces pour ta tabulation mais en soit une tabulation on ne peut pas vraiment dire qu’elle vaut 1-2-3 ou 4 espaces, ça dépends du système/logiciel qui affiche la tabulation
a plus
le 17 July 2008 à 10h48
Ton il est pas en XHTML ! bouh
le 17 July 2008 à 10h49
Sorry pr le double post, il à bouffer ma balise. Je disais donc le “br” n’est pas en XHTML ! re-bouh
le 17 July 2008 à 10h57
héhé, moi aussi j’ai la mauvaise habitude d’ouvrir mes accolades a la ligne, j’ai jamais compris pourquoi ça n’était pas la convention retenue.
le 17 July 2008 à 11h12
En Python, les conventions de codage, c’est le grand manitou qui nous les a donné :
http://www.python.org/dev/peps/pep-0008/
le 17 July 2008 à 12h26
Et bien idem, mais de toute façon, je crois qu’on a tous plus où moins notre vision du code propre et qu’on essaie de l’appliquer.
Pour les accolades, je suis aussi du genre à faire un retour à la ligne, à chaque fois, accompagné de tab quand il y a plusieurs niveau, je trouve ça pratique et ça facilite vraiment la fermeture des conditions ou autres …
Pour l’”identation”, même si je n’ai pas bien saisie, et je pense qu’il s’agit des variables … j’ai tendance à tout re-déclarer de façon plus simple, pour tout ce qui est récupéré par POST, GET, ou par une requête simple et sans boucle.
Si je me plante sur la signification du mot, ne me tuez pas, on en a pas besoin pour bien coder …
Mes commentaires sont toujours en français, et il y en a le plus possible, à chaque bloc de code ou autre …
Je me dit à chaque fois que si un junior reprend le code, un mec comme je l’ai été qui est encore un débutant et qui patauge un peu dans la semoule, ça va l’aider tout ça.
Je commente tout, pourquoi telle requête, que fait cette fonction, que définit cette boucle, qu’est-ce qui est affiché, etc …
Pour les quillemets, je suis plus ” que ‘, question d’habitude.
le 17 July 2008 à 12h28
Autant pour moi, au sujet de l’indentation, qui est la façon de mettre en valeur les blocs indépendamment des autres.
Et j’utilise donc des sauts de ligne et (beaucoup ?) tabulations …
Excusez le double post !
le 17 July 2008 à 12h58
Ah tiens une chaîne intéressante. Bon je la ferais dès que j’ai un peu de temps (je viens d’avoir mon iPhone 3G et je fais bien joujou avec :).
le 17 July 2008 à 13h16
C’est marrant on a pas du tout la même manière de coder ^^ Finalement ma chaîne n’est peut-être pas si débile
Merci d’avoir suivi !
le 17 July 2008 à 13h34
Pour ma part j’ai lors de la l’écriture d’un array qui s’écrirai comme ceci
$a = array(’a', ‘b’, ‘c’);
Pour éviter tout oublie de virgule ou pour des raison de maintenance ajout ou suppresion je le code plutot comme ceci
$a = array (
‘a’
,’b’
,’c’
);
ça bouffe plus de ligne mais encore une fois je trouve ça plus lisible
le 19 July 2008 à 10h42
@Olivier : je fais pareil pour les tableaux des fichiers de configuration (liste de pages, ou autres trucs) pour les tableaux associatifs, ça améliore grandement la lisibilité du code.
Pour l’indentation, je pense que tout le monde utilise tab, c’est juste une histoire de nombre d’espaces utilisés (pour coder hécatombe, on avait eu des petits soucis à cause de npp et de kate (oui je sais, coder avec kate…) qui utilisaient respectivement 4 et 8 espaces pour représenter une tabulation)