[Coding style] Vos solutions pour un code lisible ? - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : [Coding style] Vos solutions pour un code lisible ? (/showthread.php?tid=4309) |
RE: [Coding style] Vos solutions pour un code lisible ? - Sephi-Chan - 29-08-2009 (29-08-2009, 12:55 PM)NicoMSEvent a écrit : moi par contre, je préfixe mes variables en fonction de leur portée. C'est amusant que tu soulèves ce point. En Ruby, la portée est définie par un caractère qui préfixe le nom de la variable.
Encre une fois, Ruby se montre peu verbeux est très clair. On écrit peu et on identifie les portées d'un simple coup d'oeil. (29-08-2009, 03:11 PM)OncleJames a écrit : Travaillant en équipe et à distance, cette notation nous a fait gagner bien du temps. À mons sens, le nommage et la documentation suffisent. Mais du moment que ça vous aide, c'est l'essentiel. Sephi-Chan RE: [Coding style] Vos solutions pour un code lisible ? - naholyr - 29-08-2009 Pas de variables globales, ça simplifie encore plus le processus :lol: Et des fonctions suffisamment courtes pour que la liste des paramètres soit toujours à portée de vue, ça permet d'être sûr qu'on sait toujours si on manipule une variable locale "classique" ou un paramètre d'entrée. Finalement, en s'astreignant à ne pas faire joujou avec des notations exotiques, on s'ajoute des règles très saines RE: [Coding style] Vos solutions pour un code lisible ? - Zamentur - 01-09-2009 Alors pour ma part j'utilise dans al-gol des conventions décrite dans un document à destination des éventuel développeur qui voudrait rejoindre le projet, en voici donc un extrait: Citation :Les commentaires Il y aussi des conventions pour l'arborescence des fichiers. Et je part du principe qu'une méthode/fonction ne doit faire qu'une action et que son code doit se concentrer la dessus. Par exemple, pas question de mettre if ($number>0) $text.='s'; en plein milieu d'une méthode d'affichage d'un message, car sa génération n'est pas de son ressort. Sinon je porte beaucoup d'importance à l'écriture d'un fichier de test pour chaque classe, avant même que celle ci soit créer voir même complètement conceptualisé. Cette technique permet de voir comment doit réagir la boite avant même son existence. La revue de ce fichier peut être faite pendant qu'on code la classe proprement dite si une idée vient. A la fin le code est revu, réorganisé, simplifié, les commentaires phpdocumentor complété si inexistant. La classe est alors considéré comme stable. Je n'utilise pas de framework pour l'instant, mais j'y viendrait peut être, par contre j'utilise une organisation MVC basique de mon cru. RE: [Coding style] Vos solutions pour un code lisible ? - Argorate - 01-09-2009 Personnellement, je n'aime pas du tout la pratique asymétrique dans le code de ce style: Code PHP :
Pour plus de clarté et de visibilité, je préfère une écriture en alignement, on vois d'où on part et où ça s'arrete. Code PHP :
RE: [Coding style] Vos solutions pour un code lisible ? - Sephi-Chan - 01-09-2009 Quand j'écrivais en PHP, je préférais la notation :
Je n'aime pas la notation qui consiste à omettre les accolades, à moins que l'unique instruction soit très courte et soit placé sur la même ligne. Une autre notation que je ne supporte pas :
Les espaces de part et d'autres des parenthèses n'ont pas de sens et sont source d'erreur. Côté Ruby, j'utilise cette syntaxe :
Notons toutefois qu'on peut mettre l'instruction sur une seule ligne, et/ou remplacer le do par un { et le end par un }. Comme cela :
J'expliquerai l'utilisation des blocs dans un article à part. C'est une autre petite perle du langage Ruby. Sephi-Chan RE: [Coding style] Vos solutions pour un code lisible ? - Argorate - 01-09-2009 Autant la notion d'espace entre condition et accolade - ou entre mot clé et parenthèse - je trouve que c'est totalement libre a chacun et que ça ne nuit pas a la lisibilité ni au fonctionnement, autant je n'aime pas cette histoire d'accolade "caché"... PS: j'imagine bien que c'est pour l'exemple, mais pas d'accolade pour une instruction^^ et pas de guillemet pour un echo de ce genre :p Si je dis ça, c’est pour empêcher que des gens qui passent vite fait, retiennent des mauvaises choses. RE: [Coding style] Vos solutions pour un code lisible ? - Sephi-Chan - 01-09-2009 (01-09-2009, 08:07 PM)Argorate a écrit : PS: j'imagine bien que c'est pour l'exemple, mais pas d'accolade pour une instruction^^ et pas de guillemet pour un echo de ce genre :p J'utilise des guillemets doubles pour ne pas avoir à échapper l'apostrophe de ma chaîne. C'est la meilleure alternative pour la lisibilité.
De même, quand on doit intégrer des variables, il est plus lisible (et donc maintenable) d'utiliser les guillemets doubles, et de toujours encadrer la variable (que ce soit une variable scalaire, un tableau ou un objet) d'accolades.
Et justement, s'il y a bien quelque chose à retenir, c'est — à mon avis — de ne pas utiliser la forme sans accolade. Voici mon (donc ça n'est que mon avis) classement, du pire vers le meilleur :
À mon sens, ce sont les clés d'un code utilisable dans l'industrie du développement, où le travail en équipe et la maintenabilité sont de vrais challenge. Sephi-Chan RE: [Coding style] Vos solutions pour un code lisible ? - Argorate - 01-09-2009 Tien donc, encore un truc où je ne suis pas de cette avis ^^ Les guillemets te font perdre du temps d'exécution. et mettre un anti-slash ce n’est pas la mort et n'a rien d'horrible ou d'ambigu. Quand a rajouter des accolade quand il n'y en a pas besoin => rajout de caractères inutiles => lisibilité-- M'enfin comme tu veux RE: [Coding style] Vos solutions pour un code lisible ? - NicoMSEvent - 01-09-2009 Pour moi, déjà, ne pas avoir de données dans les traitements (idéalement ) Donc, pas de chaine de caractères, ce qui signifie pas de " ni de ' ^^ On les stocke en DB, avec des htmlentities($chaine,ENT_QUOTES,'UTF-8') afin d'éviter tout problème de caractères spéciaux, guillements, apostrophes, etc... J'apprécie ce genre de code aussi : Code : echo $condition?$resultat_db['msg_ok']:$resultat_db['msg_fail']; Code : echo $resultat_db[$condition?'msg_ok':'msg_fail']; j'externalise en maximum, j'ai un fichier avec toutes mes requetes SQL, paramétrables avec un sprintf Code : $req_insert_operation="INSERT INTO operation (nom,password,msg_ok,msg_fail) VALUES ('%s',PASSWORD('%s'),'%s','%s');"; Code : RequestDB( //j'appelle ici a ma couche d'abstraction DB RE: [Coding style] Vos solutions pour un code lisible ? - Allwise - 01-09-2009 Pour ma part, pas grand chose à ajouter, tout ce que je fais / m'efforce de faire a été dit. J'avoue que même si j'essaie de bien faire au départ, je finis souvent par mélanger du français et de l'anglais dans mon code. Quand l'anglais est plus court et plus parlant j'y recours, sûrement mon côté flemmard / bordélique ^^ Quant à l'utilisation des accolades, au début, tant en PHP qu'en javascript, je les omettais quand c'était possible, mais avec le temps je les ai mises partout, parce que je trouvais que c'était naturellement plus lisible. De même, au départ j'étais plus du genre Code PHP :
Code PHP :
Quant à l'utilisation des quote / double quote, ça dépend du contexte. Si j'ai un gros pavé de texte ce seront les double, si c'est une ptite phrase ce sera les simples. Au début j'étais plus partisan des simples pour des raisons d'optimisation mais encore une fois, le temps m'a fait changer d'avis et m'a fait comprendre que c'était pas là qu'il fallait chercher. Certes PHP parse chaque mot à la recherche d'une variable quand on utilise les guillemets, mais je ne suis pas convaincu du gain que ça peut apporter dans une application et du ressenti des utilisateurs. D'ailleurs, t'as un cas concret qui met en évidence ce gain de temps d'exécution, à part des boucles énormes qui servent à rien ? :bisou: Je n'utilise jamais de préfixe à mes noms de variables, sauf en Javascript ( et éventuellement dans d'autres langages ) quand je définis des champs de formulaire. Je les préfixe par le type de champ : lstPays, txtNom, chkSexe... Ça m'aide à m'y retrouver quand il y en a beaucoup Sinon Argo, le code le plus concis n'est pas forcément le plus lisible. En fait, c'est le contraire. Si on suit ton raisonnement, les indentations et les retours chariots sont inutiles Ce qu'on fait pour rendre un code illisible, c'est en partie ça, supprimer les espaces / indentations, et raccourcir au maximum le nom des variables. Bon ok j'avoue je suis un chieur :glace: EDIT Ce qui est dommage avec ta façon de faire Nico, c'est que tant au niveau de l'utilisation d'IDE PHP genre Eclipse qui affichent la liste des arguments, tant au niveau de la doc ( phpDoc ), c'est pas parlant du tout. Pourquoi ne pas intégrer le sprintf dans une fonction plutôt ? Code PHP :
|