Qu'est-ce qu'un code "propre" selon vous ?
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Qu'est-ce qu'un code "propre" selon vous ?
Qu'est-ce qu'un code "propre" selon vous ?
D'un point de vue plus subjectif, quand un code est propre, on a envie de le lire par opposition à sale ou dégoutant.Envoyé par souviron34
Un code propre permet une lisibilité correcte et surtout une maintenance simplifiée.
Des bugs simples (syntaxes, inattention etc.) se trouvent beaucoup plus rapidement corrigés avec un code "propre".
Comment rendre propre son code ?
Un certain nombre de points doit être pris en considération dés qu'on commence à coder un programme :
- Structuration du code : Indentation, noms de fonction, classes, variables "explicites" (une variable représentant l'âge, appelez-la age et pas x). Respectez les conventions (ex : nommage des classes : première lettre en majuscule)
- Savoir commenter son code : Expliquer ce que fait telle fonction, telle partie un peu complexe du code. Ne pas tomber non plus dans l'effet pervers de vouloir tout commenter. La fonction printf a rarement besoin d'être commentée, on sait ce qu'elle fait.
- Découper le programme : Tâcher de séparer les parties logiques de votre code en créant des fonctions, classes pour chaque entité logique. La classe ConnexionBDD n'a sans doute pas besoin d'implémenter la méthode envoyerMail().
Voila comme ça ce qui me vient à l'esprit.
Un code propre pour moi c'est un code qu'on lit sans trop d'effort (comprehension rapide, meme sans commentaire).
Plus important encore, un code propre c'est un code que j'ai pas envie de remplacer par d'autres lignes.
D'après toutes les réponses apportées jusqu'ici, code propre signifierait donc code lisible (bien présenté) ? Je ne suis pas de cet avis. Selon moi, un code est dit propre s'il contient un minimum de valeurs "hard-codées", n'appelle pas de fonction d'arrêt prématuré du programme, déclare "const" un objet qui n'est pas garanti être modifiable, etc.
J'oubliais, pas d'instruction GOTO dans les programmes. Par soucis de comptabilité certains langages conservent cette instruction.
Non, il ne faut pas bannir le goto de façon si définitive. En certaines circonstances, son utilisation est tout à fait légitime.
Un code propre est avant tout un code qui respecte les règles qualités qui le concerne. Des exemples de règles ont été données ici, mais si certaines de ces règles sont universelles, d'autres sont bel et bien contextuelles.
Si, cela en fait partie, même si ce n'est pas exhaustif..
Mais c'est un élément essentiel..
0 serait mieux que "minimum".
Point 2 vrai, mais cela dépend des contextes. Dans un contexte d'applications d'usage réel, cela devrait être vrai..
Point 3, bof..
Principalement, c'est : bien structuré, prend bien en compte les erreurs, les variables et les noms de fonctions / méthodes / etc. ont des noms compréhensibles, descriptifs, pas trop à rallonge, comprend des commentaires là où il faut (pas partout), donne les références exactes quand un algo est tiré de quelque part, une entête explicative par fichier, les fichiers portent des noms compréhensibles et descriptifs, etc etc..
La lisibilité du code fait partie de cela (indentations, différences entre variables globales et locales, entre noms de fonctions / méthodes locales et externes, structuration des répertoires, etc etc).
Bref, un code propre est un code permettant à quelqu'un qui ne le connaît pas mais connaît le but de l'application de s'y retrouver facilement.
Idéalement quelqu'un devrait être capable de comprendre à peu près n'importe quoi y compris d'une très grosse application en moins d'une demie-journée.
@chaplin : je rougisd'être cité
- C'est une parole de sage@chaplin : je rougis
En outre, éviter les redondances de code, c'est à dire executer le même jeux d'instructions plusieurs fois dans un programme, c'est le fondement de la programmation procédurale, valable aussi en POO.
Ce que tu donnes est aussi un critère de lisibilité.
J'insiste sur le « aussi » car ce n'est bien sûr pas seulement ça.
En fait, c'est surtout parce que quand un code est propre, il est généralement plus lisible que la version non propre. Mais un code propre n'est pas forcément lisible et un code lisible n'est pas forcément propre, j'insiste surtout sur le deuxième cas. Donc lisibilité (bonne présentation) et propreté pour moi sont deux choses bien différentes.
Mais c'est aussi un code que l'on aurait plaisir à faire évoluer en le respectant et en conservant son ame. Un code où la cohérence serait forte et où l'information ne serait pas duppliqué.
J'ai lu tous les posts mais comme il y en as pas mal , je me suis peutêtre un peu perdu dans l'amas
j'ai l'impression en vous lisant que pour avoir un code propre , il faut faire de l'anti optimisation ...
etre clair dans son code pour la plupart d'entre vous semblerai dire :
éviter de répéter le même code plusieurs fois dans le programme.
faire des procédures les plus courtes possibles quitte a découper une "action" en plusieurs sous actions dans des procédures diffèrentes.
le point sur lequel je serai assez d'accord avec vous mais auquel j'ai un mal de chien a me tenir, c'est les commentaires.
pour avoir un code parfaitement optimisé, il faudrai n'avoir en vb par exemple que ces procédures ci :
le main sub ou les form load pour initier le programme et les forms
ensuite uniquement une procédure par évenement.
toute écriture de procédure "de confort" devrait être totalement bannie.
mais voila , une mise a jour d'une fonction , impliquerai immédiatement des heures et des heures voir des jours et plus encore pour la plus petite modification alors que si on as 50 fois la même routine dans le programme et qu'on la remplace par une procédure , on ne devra modifier que le code de cette procédure la et rien d'autre.
il est évident que "ma" version de codage n'aurai pas du tout votre assentiment, mais ne nous demandons plus pourquoi par exemple , les programmes quenous avons écrit il y a 10 ans sur des P3 , tourne tjs sur des p3 aussi vite que nos dernières versions le font sur des dual core voir des quadracore ...
je travaille dans un pays ou il n est pas déja absolument sur de decouvrir que le pc sur lequel mon soft tournera sera au moins un p3, si j' applique les specifications normales d'un code propre et facile a maintenir ( petite procédure spécialisée dans une action comptant le moins de ligne possible) je peut vous garantir que la plus part de mes soft serai inutilisables.
je me prépare a créer un soft pour une entreprise , qui va m'obliger à faire ce que j'ai dit plus haut :pas de procédure inutile que les procédures d'initialisations et les procédures evenements. je cherche même des techniques permettant de prémacher certaine opérations sur un autre pc de facon a ne plus avoir qu'à importer par exemple les modifications d'une base de données sous forme d'un fichier qui ne monopoliserai pas celui ou mon soft tournera une seule seconde de trop (son domaine est la sécurité de lieu divers). J'ai déja réalisé un certain nombre de test et je peut dire que par exemple dans le maximum de cas possible je devrai eviter toutes boucles. preferant répéter autant de fois que nécessaires le code en modifiant ce que la boucle aurai modifié. un truc de ouf , mais c'est le prix a payé pour ne pas avoir a modifier le parc ordinateur de la société.
le cout supplémentaire en heures de travail , est compensé par le cout enorme des ordinateurs dans mon pays. Et le fait que si plus tard mon soft doit tourner sur des pc plus puissant, il n'en sera que plus rapide encore.
(cet effort d'optimisation est exigé pour gèrer une possible mais très peu probable montée en charges maximal du système d'alerte).
Mais de toutes façon il s' agit d'un strict respect des recommandations de la "bible" du programmeur visual studio :"msdn"
alors comment gèrer ce type de code et l'aspect propre et facile a maintenir que vous pronez ?
Je comprend ton besoin d'assurer des performances correctes sur des configurations que l'on qualifie facilement de vieilles et de faibles dans nos contrées...
Cependant, je ne suis pas intimement persuadé que le fait de dérouler des boucles (si tant est qu'il soit possible de le faire) ou d'éviter deux appels de fonctions (même si, en réalité, tu en arrive à quatre ou dix fonctions plus basiques) soient réellement de nature à améliorer très fortement les performances...
Comprenons nous, je ne dis pas que c'est toujours inutile mais seulement que c'est très rarement utile
Il ne faut pas oublier que des langages aussi anciens que COBOL fournissent déjà la possibilité de créer des procédures et des boucles...
C'est à dire que ces facilités existaient déjà lorsque les ordinateurs dont on disposait étaient encore très loin d'avoir les capacité d'un P3, et que cela n'empêchait pas d'avoir des applications "relativement rapides" en tenant compte du matériel sur lequel elles fonctionnaient
(Pense que, pour Appolo 11, l'ensemble des "super ordinateurs" de la NASA n'avait la puissance que d'un ordinateur portable actuel
Bien sur, il ne faut pas se leurrer: Au niveau du processeur une boucle fonctionne fatalement sur une comparaison et un jump, l'appel d'une fonction doit commencer par placer des valeurs sur la pile, et cela lui demande, effectivement, quelques tours d'horloges de le faire.
Mais, avant de décider de se passer de ces facilités, il me semble important d'au moins s'assurer que le gain de performances obtenu à le faire en vaut réellement la peine
Et cette certitude ne peut, à mon sens, n'être acquise qu'en effectuant de mesures des deux possibilités envisagées
En effet, avant que le gain ne soit seulement perceptible par l'homme (disons d'un dixième de seconde), il faut épargner de nombreux cycles d'horloge d'un processeur... Même si celui-ci ne tourne "qu'à" 600Mhz
Par contre, j'estime que, si un test permet de n'entrer dans une boucle que 9 fois sur dix (par rapport à une version sans test), il est souvent plus intéressant de commencer par comparer les performances obtenues avec ces deux versions que de mettre en oeuvre les solutions dont tu parles
En un mot, je dirais que, avant de commencer à vouloir "grappiller" quelques cycles d'horloges en déroulant les boucles ou en supprimant une fonction qui serait appelée à de nombreux endroits, il est surement préférable de s'intéresser à toutes les optimisations que l'on peut apporter à l'algorithme
Un simple exemple: tu gagnera beaucoup plus en performances en utilisant un algorithme dichotomique (si tu peux l'utiliser) plutôt qu'un "simple" algorithme itératif, et tu gagnera d'autant plus en performances que le nombre de données à traiter est important
Bien sur, je ne parle ici que dans le cas général, et il est tout à fait possible de trouver des cas particuliers dans lesquels ceci ne s'appliquerait pas... Mais ces cas particuliers restent malgré tout l'exception
A méditer: La solution la plus simple est toujours la moins compliquée
A te lire, il y a une chose qui m'étonne beaucoup. Si tu as de telles contraintes de performances, pourquoi coder en utilisant un langage interprété, réputé pour sa lenteur et son absence de performances !J'ai lu tous les posts mais comme il y en as pas mal , je me suis peutêtre un peu perdu dans l'amas
j'ai l'impression en vous lisant que pour avoir un code propre , il faut faire de l'anti optimisation ...
etre clair dans son code pour la plupart d'entre vous semblerai dire :
éviter de répéter le même code plusieurs fois dans le programme.
faire des procédures les plus courtes possibles quitte a découper une "action" en plusieurs sous actions dans des procédures diffèrentes.
le point sur lequel je serai assez d'accord avec vous mais auquel j'ai un mal de chien a me tenir, c'est les commentaires.
pour avoir un code parfaitement optimisé, il faudrai n'avoir en vb par exemple que ces procédures ci :
le main sub ou les form load pour initier le programme et les forms
ensuite uniquement une procédure par évenement.
toute écriture de procédure "de confort" devrait être totalement bannie.
..
alors comment gèrer ce type de code et l'aspect propre et facile a maintenir que vous pronez ?
Même il y a 10 ans, on connaissait le rapport entre les différentes vitesses d'exécution des langages du moment : Assembleur = 1, C/C++ = 1.1, Pascal = 2, VB = 10 !
Depuis les langages ont évolués, les compilos se sont fortement améliorés, tous les langages compilés commencent à ce valoir côté performances et valent largement un code assembleur.
Il n'y a que VB qui a été abandonné par Microsoft et donc qui n'a pas progressé.
Développer les boucles, c'était une technique d'optimisation à la mode, du temps des 80486 et premiers Pentium. Le but était de tirer parti de l'architecture du processeur en pipeline en évitant les sauts car chaque saut réinitialisait le pipeline, ce qui pouvait diviser les perfs par 2 ou 3 sur les petites boucles.
Dans un langage de plus haut niveau, lorsqu'on fait une boucle, il y a le code qui est exécuté dans la boucle, mais aussi le code qui gère le compteur de la boucle. Si la boucle est petite (genre on remplit un tableau avec une constante), la gestion de la boucle coûte plus cher que le code à l'intérieur de la boucle. Mais là encore, on a rarement ce problème avec un compilo moderne qui sait gérer les boucles de façon efficace.
L'appel d'une méthode avec passage de paramètre, dans les langages modernes, l'appel se fait par registre, sans passer par la pile. Autant dire que l'effet sur les perfs est quasi négligeable.
En un mot, si tu veux avoir de bonnes perfs sans perdre en lisibilité : Change de langage ! (bon je sais, on a rarement le choix).
Après comme l'a dit koala01, les plus gros gains de perfs, on les obtient en utilisant des algorithmes performants et adaptés, en surveillant la combinatoire... L'implémentation et langage donneront des écarts de perf de 1 à 10. Un mauvais algorithme, donnera des écarts de perfs de 1 à ... l'infini.
Juste une petite remarque sur les performances et les commentaires : Dans un langage interprété qui ne fait pas une pré-compilation, (certains langages BASIC très anciens, tous les langages de scripts), les commentaires eux-mêmes dégradent les perfs !
Car pour l'interpréteur, une instruction est une ligne de texte qu'il faut analyser avant de se rendre compte qu'il s'agit d'un commentaire et qu'il n'y a rien à faire. Sans pré-compilation du source, cette analyse est faite à chaque exécution !
Je me demande si le problème ne se situe pas ailleurs que là où tu le vois. A l'époque où les microprocesseurs tournaient à 8Mhz, les programmeurs ne s'amusaient pas (plus ?) à dérouler les boucles sous prétexte qu'ils avaient besoin de performance. (Sauf exceptionnellement, par exemple quand quelqu'un voulait programmer une démo ultra rapide sur un Atari ST avec un langage qui n'était pas prévu pour cela comme le GFA BASIC)
Donc sur un P3, tu ne devrais pas en avoir besoin non plus. Ni même sur un 386... à condition bien sûr d'utiliser les bons outils. Si tes programmes doivent tourner sur des machines qui ont quinze ans, tu dois les développer avec les environnements et compilateurs de l'époque, car ceux d'aujourd'hui sont bien plus lourds et feront ramer ton code quel qu'il soit. Inutile après de vouloir économiser quelques cycles en déroulant des boucles.
Puis VB a toujours été lent.
Un code lisible. Coder c'est exprimer selon un langage de programmation une succession de tâches.
Un code propre se lit et se comprend en le lisant. Et oui, on n'y pense pas assez, mais nous parlons plusieurs langues étrangères. C'est quand il y a des jargons, du patois, au sein d'un langage que cela devient difficile.
Un morceau de programme est un livre, un formulaire un chapitre, une procédure un paragraphe. Il faut parfois un sommaire, une introduction, un résumé, une conclusion pour comprendre l'ensemble.
J'ai collègue pour qui un code lisible est, en plus, un code correctement indenté, les variables et les propriétés dans l'ordre alphabétique. Les méthodes, les propriétés séparée...
A+
"Winter is coming" (ma nouvelle page d'accueil)
ok
Un code propre est un code où lorsqu'on enlève le code, il ne reste que des lignes de commentaires parlant et explicites retraçant les SF et/ou le CDC !
si il ne reste rien, c'est un code sale !
Pas tout à fait d'accord non plus. Le code doit être une documentation à lui tout seul. De nombreux développeurs reconnus pour leur demande de code propre écrivent le moins de commentaires possible. A partir du moment où une fonction a un nom explicite quant à ce qu'elle fait, qu'elle est courte et que le code fait ce que le nom indique, pourquoi ajouter des commentaires ?
code
un code propre, c'est avant tout la structuration de ce dernier, c'est -à-dire de la declaration de variables, classes, methodes, fonction à leurs utlisations doit etre le resultat d'une approche systematique. en ajoutant à cela une documentation (commentaire) suffisante.
Répondre avec citation
Partager