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.
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.
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.
tout à fait.
Cependant, pour le goto, cela semble (malheureusement) enseigné .. Et comme il est dispo dans une majorité de langages, utilisé pas mal par de jeunes débutants.
Comme son utilisation - recommandée - est pour un très petit nombre de cas vraiments spécifiques, il est à mon avis judicieux de mettre en à priori et en gros "à bannir SAUF..." plutôt que "existe, mais très peu recommandé dans ....", la liste y étant beaucoup plus longue...
Disons que dans un thread comme celui-ci, il n'est pas forcément besoin de le spécifier (vu qu'il fait partie (à contrario) du chapitre d'une conception claire), mais au vu du nombre de posts de jeunes l'utilisant, j'aurais tendance à penser que affirmer régulièrement que ce nest pas à utiliser est quand même utile...
Un code propre pour moi c'est aussi un code 'stupide'.
En tout cas très simple, facilement lisible, facilement compréhensible
et facilement deboguable par quelqu'un d'autre.
Qui utilise des design patterns documentes plutot que des petit bijoux de
conception logiciel que personnes d'autre ne poura jamais comprendre.
Si tu écris un morceau de code tres intelligent, en cas de probleme il faudra
etre encore plus intelligent pour le comprendre. En debugging il faut presque etre 2X plus intelligent que le code .... (j'avais lu ca qqpart).
De toute façon dans chaque boite, dans chaque langage et meme parfois projet les gens font des choix differents, d'indentation de nommages etc, le plus important c'est de tous coder de la meme facon et d'arriver a bosser sur le code des autres.
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.
un code propre est lisible, on l'a vu. Il ne comprend que ce qui est nécéssaire - donc le code doit être mutualisé, peu importe comment. Et il évite le spaghetti(qui ne nécéssite hélas pas de goto, des procédures/méthodes mal rangées peuvent avoir un effet désastreux sur la maintenabilité du code).
perso, le goto, c'est uniquement goto fin-procédure, pour éviter un else à 300 lignes. Question de gout.
Ce que dit andr386 est important aussi, mais n'est pas forcément de la propreté de code, c'est juste une bonne pratique. Le super code de la mort peut être parfaitement lisible, propre, clair...et peu compréhensible.
Pour paraphraser ce qui a été dis, la programmation objet va naturellement dans le sens d'un code plus "propre".
un code respectant le standard du langage ou de l'api du framework dont il s'appuit.
Pas nécessairement, il est très aisé de faire du code "malpropre" en objet. L'abstraction rajoute quand même une difficulté parfois difficile à maîtriser qui se traduit dans beaucoup de code par une lisibilité moindre et une complexification du code accrue.
En fait, le problème est souvent le même : savoir respecter des conventions, documenter son code, bien concevoir son application etc. (tout ce qui a été dit en gros).
une convention est standardisée,
le standard est documenté
on ne parle de conception que lorsqu'elle est est standardisée.
L'objet va dans le sens d'un code plus propre. Est-ce vraiment nécessaire ne préciser "quand on sait utiliser correctement l'objet" ? Toi même tu nous parles de maintenance simplifiée, de découper le programme. etc. Ces bonnes intentions sont à l'origine de la programmation objet.
Cf. à ce sujet les 5 principes fondamentaux (SOLID) qui accompagnent la programmation objet.
PS : et vive Quimper
Mais si tu précises que le développeur sait développer correctement, le problème ne se pose plus et tous les paradigmes deviennent lisibles… Par contre si tu prends des développeurs moyens qui ont des défauts, est-ce vraiment mieux ? Et des débutants ? Là c'est tout de suite moins évident.
Et pis « plus propre que quoi » ? Que toutes les autres manières de faire ? C'est un peu rapide comme jugement.
La lisibilité du code ne repose pas beaucoup sur le paradigme… à la limite sur le langage, mais alors Java et C++ produise selon moi du code plutôt moche. OCaml, Pascal et Smalltalk par contre font du bon travail de ce côté. J'en met un fonctionnel, un procédural et un OO exprès bien sûr.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager