Mes Conventions en Programmation

Attention, cet article a été déplacé dans les archives, donc le contenu peut ne plus être à jour. A vous de voir 🙂

Car il fallait que ça tombe sur moi : Skreo, de la plate-forme Eklablog m’a transmis une chaîne pour parler de ses conventions en programmation.

Notation

Je n’utilise pas CamelCase ou autre notation Hongroise, je préfère de longs noms explicites pour savoir exactement sur quoi je bosse 🙂
Dans mes bases de données, par contre, mes champs ont des noms de type [initiale unique de la table]_[contenu du champ], ce qui permet de faire des jointures sans avoir à renommer de champ.

Indentation

J’indente avec la touche TAB, je sais, c’est mal. Mais sous Notepad++, ça donne exactement 4 espaces, donc pas si coupable que ça 🙂

Accolades

Je mets l’accolade de départ un espace après l’instruction, et celle de fermeture, seule sur sa ligne.
Je ne mets jamais d’accolades pour les instructions monolignes, je saute une ligne et je rajoute un TAB.

Espaces

Toujours un espace avant et après les opérandes, et après une virgule. à part ça, tout dépend du script ( longueurs max des instructions, etc ).

Guillemets

J’utilise toujours des simples-quotes ‘, sauf pour les caractères d’échappement ( « \n », « \t » ).

Commentaires

Les commentaires me servent essentiellement à annoter des bouts de code sur lesquels je compte revenir plus tard, ou à expliquer ma méthode sur des scripts amenés à être partagés.
Sinon, en règle générale, je comprends plutôt bien mes scripts à la relecture 😉

Soyons fous, un petit exemple de code :


Je passe la chaine à … ShadowKris, Br1o et JarodXXX. Et, pour le faire grave, à toi, lecteur 😉

Partager cet article

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

  • Je vois pas le concept de rajouter l’initiale de la table au nom du champs, vraiment pas 🙂

    A part dans certains cas ou on doit sélectionner deux champs qui ont le même nom sur deux tables.

    Mais est-ce que rajouter deux caractères sur chaque champs est vraiment la meilleure solution et est-ce nécessaire ? Pour ces rares cas tu peux faire :

    select a.var1, b.var1 as bVar1 where a.id=b.id;

    voilà … « as bVar1 » au lieu de rajouter 2 caractères * nombre de tables.

  • ça permet d’avoir un nom de champ unique, et de ne pas avoir à perdre du temps lors des requêtes jointes.
    ça me sert aussi lors de l’utilisation dans PHP à montrer quelle table est utilisée.

    Bon après, ça reste une démo de ma façon de coder, pas une incitation à coder comme moi 🙂
    Cette technique fait partie de ces petits trucs qui ne sont utiles qu’à ceux qui en ont besoin ^^

  • Je vois que je te rejoins sur presque tous tes points même si je voudrais maintenant me mettre à coder en notation Hongroise (surtout utile pour des langages fortement typés donc pour PHP et Javascript on s’en fou presque ^^) en tout cas bonne continuation 🙂

  • Au niveau clés primaire chez moi, c’est toujours id. Sans l’initiale de la table avant.
    Et quand j’ai une clé étrangère, c’est table_id. user_id par exemple.

    Après, certains frameworks forcent certaines conventions. Quand on utilise plusieurs frameworks qui ont les mêmes conventions (RoR et CakePHP entre autres pour ma part), on prends comme habitude de toujours utiliser celle-ci.

  • Pas bête pour les noms de champ mysql 😉
    Pour les indentations en TAB, je fais pareil, j’ai jamais dit que c’était mal :p D’ailleurs les tabulations sont faites pour ça, donc pourquoi s’en priver et mettre des espaces ?
    Dans l’ensemble j’aime bien ta manière de coder ^^

  • Je suis pas d’accord : utiliser TAB c’est pas mal du tout ! Au moins chacun peut les adapter à la taille qu’il souhaite dans son éditeur.

    Sinon j’ai quasiment les même conventions que toi, mais je me pose une question : c’est normal que dans l’extrait de code que tu montre il y ai un espace après ‘while’ et pas après ‘if’ ? (moi je le met les deux fois, je conçoit qu’on ne le mette pas, mais par contre une fois sur deux… ^^).

    🙂

  • En effet, j’ai pas fait attention à ça 😉
    Merci pour avoir signalé l’erreur, je la corrigerais dans mon script ^^

  • Avoir ses propres conventions, c’est bien, ça aide à travailler proprement et uniformiser son code, mais uniquement tant qu’on travaille seul. Le but ultime d’une convention est justement d’être unanime afin que tout le monde code d’une façon similaire et ainsi se comprenne mieux. C’est pourquoi personnellement j’essaie de respecter au maximum les conventions proposées par des organismes crédibles. Pour PHP : PEAR, PHP.net, ou Zend (cf. conventions d’écritures du Zend Framework)

  • while ($file = readdir($dir_open))

    Ouaille, mes yeux me font mal : tester l’affectation d’une condition…

    Je préfère quelque chose de plus propre (notez la syntaxe française, beaucoup plus sympa que l’anglais !) :

    $fichier = readdir($dir_open)
    while ($fichier!==false)
    {
    $fichier = readdir($dir_open)
    }