Qu'est-ce qu'un code "propre" selon vous ?

Citation:

---

Envoyé par souviron34

Citation:

---

Cependant qu'est-ce qui doit être facilement compréhensible :
1. Ce que le code fait ? (indispensable pour corriger un bug)
2. Ce que le développeur a voulu faire lorsqu'il l'a écrit ? (idem. Sauf que s'il y a un bug, c'est que 1<>2 donc le code ne va pas faire clairement appraitre les deux)
3. Ce que le développeur avait besoin de faire ? (autrement dit quel était le problème qu'il cherchait à résoudre ?) (autrement dit, même si 1=2 (ou une fois que 1=2) est-ce que ça permet de résoudre le bug ?)

En théorie, les trois sont identiques mais dans la pratique...
Avec le cas pratique tellement classique : On vient de découvrir un bug dans l'appli qui doit être corrigé en urgence. Le développeur qui a codé cette partie est en vacances ou a quitter la société. Et c'est quelqu'un qui n'a jamais mis le nez dedans qui doit résoudre le problème.

---

c'est bien ce qu'on dit depuis le début de cette discussion, non ??

La bonne compréhension passe par le fait que ce soit lisible (et pas "obsufqué"), bien présenté pour que ce soit clair, les blocs bien séparés, des commentaires, si possibles des commentaires (même longs) aux endroits "chauds" ou en tête des fonctions..

---

... euh je posais une question :koi:
Lorsqu'on cherche à écrire un code lisible, quel aspect faut-il chercher à rendre le plus clair lorsque ces derniers se contredisent ?
Que penser lorsqu'on a un commentaire qui dit quelque chose, et que le code fait autre chose ?
Si on cherche un bug rapidement et qu'on utilise le commentaire pour se repérer, une fois qu'on a lu ce que le commentaire dit qu'il pense faire, on a tendance à ne pas se rendre compte que le code fait autre chose. D'un autre côté, si le commentaire résume bien ce que le code fait, on risque d'avoir du mal à comprendre la démarche de l'algorithme.

Pour le reste, ce que je dis c'est que "code propre" ça ne veut rien dire. Ca relève du traité de pifométrie. Chacun est libre de mettre la définition qu'il veut derrière. Pour toi (et un certain nombre d'intervenants dans cette discussion) "qu'est-ce qu'un code propre ?" = "qu'est-ce qu'un code lisible ?". La lisibilité est quelque chose d'important. Je ne dit pas le contraire.
Pour moi, dans le domaine où je travaille, le code a toujours un minimum de lisibilité suffisant pour que je parvienne à le comprendre.
La lisibilité c'est un pré-requis. Si le code est illisible, je ne vais pas me demander s'il est "propre" puisque je n'arrive même pas à le lire.
Donc quand on me demande si "un code est propre", je regarde s'il est bien codé. Et d'une façon générale, si après l'avoir lu j'ai envi de tout refaire...

Citation:

---

Envoyé par benwit

Je sais bien que ce sont des conventions mais l'exemple ocaml m'y fait penser : un code avec une syntaxe horrible et/ou pleins de caractères "spéciaux", je trouve ça moche :

;;
$
***a->c
%%
##

---

La surcharge d'opérateur fait de C++ un langage plein de caractère non textuel il me semble. Ce n'est donc pas forcément mieux sur ce point. Cependant les caractères spéciaux peuvent être un plus.

Code:

---

{ (x,y) | x <- [1..10] /\ y <- [1..5] }

---

Trouves-tu ça si difficile à lire ?
un « -> » pour une flèche, un « <- » pour un « appartient », « /\ » pour un « et logique » n'est pas si terrible non ? Pas plus tordu qu'un « & » pour une référence, un « :: » pour un opérateur d'accès, un « << » pour un opérateur de flot ou un « && » pour un « et logique ».

Mais bon, quoi qu'il en soit, il serait légitime que tu n'aimes pas ça. C'est affaire de goût après tout. C'est donc un critère peu pertinent pour la lisibilité. Un habitué de Java préférera plus probablement Java à C++.

La question se poserait plutôt sous la forme : si on prend le même langage, qu'est-ce qu'un code lisible écrit dans ce langage. Ça évacue un peu les affaires de goûts personnels.

Pour précision, le double point-virgule en ocaml n'est souvent pas nécessaire pour des programmes compilés. C'est surtout l'interpréteur qui en a besoin car sinon on ne sait pas si on est passé à une évaluation ou si on continue une définition ou un passage d'argument.. Au final, le C++ utilise bien plus de point-virgule puisque ceci indique une fin d'instruction. Je ne juge pas que ce soit un bien ou un mal. C'est finalement un détail à mes yeux.

Citation:

---

Envoyé par Franck SORIANO

[...]
Pour le reste, ce que je dis c'est que "code propre" ça ne veut rien dire. Ca relève du traité de pifométrie.[...]

---

Globalement je suis entièrement d'accord avec toi. La question, comme de nombreuses ici, ne mènera nulle part. Mais n'est-ce pas parce qu'on s'ennuie qu'on poste ici ? J'espère que personne n'espère avoir une vraie réponse :mrgreen:

Plutôt que la pifométrie cela reléve de l'assurance qualité mais cela m'étonnerait que 'code propre' y soit dans un quelconque glossaire c'est plus un dialecte de programmeur.

Il peut y avoir des gardes-fou de placés comme une charte de programmation (si possible intégré dans l'éditeur) une relecture de code en binome/trinome. En fait pour ma part code propre c'est synonyme de code maintenable d'où les gardes-fou.

Citation:

---

Envoyé par Franck SORIANO

... euh je posais une question :koi:

---

Excuse-moi, je pensais que c'était un effet de rhétorique (ou de style) :oops:

Citation:

---

Envoyé par Franck SORIANO

Lorsqu'on cherche à écrire un code lisible, quel aspect faut-il chercher à rendre le plus clair lorsque ces derniers se contredisent ?

---

par rapport à tes 3 questions, je dirais, dans l'ordre :

1. ce que le prog fait : documentation de ce qui existe
2. ce que le programmeur a voulu faire : on peut peut être trouver un algo plus simple, mais si celui-ci fonctionne pourquoi pas ?
3. ce qu'il fallait faire : normalement, c'est dans la doc de specs, pas dans le code.

Citation:

---

Envoyé par Franck SORIANO

Que penser lorsqu'on a un commentaire qui dit quelque chose, et que le code fait autre chose ?

---

Changer le commentaire pour l'accorder au code.

Un changement du code impose une re-conczption (et, dans une équipe, un minimum de concertation et d'accord)

Citation:

---

Envoyé par Franck SORIANO

Si on cherche un bug rapidement et qu'on utilise le commentaire pour se repérer, une fois qu'on a lu ce que le commentaire dit qu'il pense faire, on a tendance à ne pas se rendre compte que le code fait autre chose. D'un autre côté, si le commentaire résume bien ce que le code fait, on risque d'avoir du mal à comprendre la démarche de l'algorithme.

---

Pour le premier point, pas vraiment. Le code est la base. Le commentaire vient "en surplus", au cas où on ne comprenne pas la logique de certains passages.. Donc une bonne exploration consiste à comprendre le code..

Pour le second point, normalement un bon commentaire de fonction devrait expliquer l'algorithme (y compris les références éventuelles), PUIS dans le corps avoir les commentaires sur ce que le code fait..

Citation:

---

Envoyé par Franck SORIANO

Pour le reste, ce que je dis c'est que "code propre" ça ne veut rien dire. Ca relève du traité de pifométrie. Chacun est libre de mettre la définition qu'il veut derrière.

---

Plus ou moins vrai...

Comme on l'a dit plus haut, quand tu te plonges dans un code nouveau, si tu t'arraches les cheveux pour comprendre, c'est qu'il est mal fait, et donc pas "propre", même si il est rusé..

Donc, réciproquement, même si tu ne connais pas le langage ou le code, si c'est et bien présenté et bien documenté, c'est compréhensible, et donc "propre"..

Après, on peut pinailler sur le "propre technique" comme toi ou quelqu'un d'autre citait, mais à mon avis ce n'est pas l'essentiel..

Citation:

---

Envoyé par Franck SORIANO

Pour toi (et un certain nombre d'intervenants dans cette discussion) "qu'est-ce qu'un code propre ?" = "qu'est-ce qu'un code lisible ?".

---

tu as mal lu...

Si tu reprends depuis le début, on va nettement plus loin que la simple "lisibilité..

Citation:

---

Envoyé par Franck SORIANO

La lisibilité c'est un pré-requis.

---

Tu serais étonné des codes (y compris industriels) traînant un peu partout et qui sont "illisibles"..

Citation:

---

Envoyé par Franck SORIANO

Donc quand on me demande si "un code est propre", je regarde s'il est bien codé. Et d'une façon générale, si après l'avoir lu j'ai envi de tout refaire...

---

Ce n'est pas forcément un critère : langage avec lequel tu n'es pas à l'aise, nouveautés du langages, manière personnelle de coder..

Après l'avoir lu, les questions à se poser (je vais résumer les arguments précédents) sont : marche-t-il ? sera-t-il facile à maintenir ? sera-t-il facile à améliorer ? est-il bien documenté ? se retrouve-t-on logiquement avec les noms (de fonctions, de variables, de modules) ? se retrouve-t-on logiquement dans l'arborescence ? est-il trop obfsuqué inutilement, ou bien cette partie difficilement compréhensible était-elle nécessaire (contraintes d'optimisation, de matériel, etc etc) ?

Il est des cas où il est nécessaire d'avoir une partie "difficillement" lisible.. Mais elle se doit d'être bien documentée.. Et il n'est pas toujours nécessaire de la modifier.. Elle peut être très brillante et difficile à améliorer.. Même si, au premier coup d'oeil, elle n'est pas "propre"..

Mais chaque personne a sa manière de coder. Du moment qu'elle est claire, logique, et suit ce qu'on a dit plus haut, pour moi j'appelle ça "un code propre"..

Je m'aperçois que la définition d'un code propre est subjectif.

N'y a t il pas une définition acceptée de tous (une norme ?) afin que l'on puisse tous se comprendre ?
En effet notre domaine est régie par des normes, règles ... alors pourquoi notre langage familier ne l'est il pas ?

Citation:

---

Envoyé par brice01

alors pourquoi notre langage familier ne l'est il pas ?

---

tu viens d'y répondre ;)

Dans le langage de la norme on pourrait dire que 'code propre' c'est relative à la qualité interne on pourrait donc se référer à ISO. On trouverait un certain nombre de facteur comme la maintenabilité, l'extensibilité, la portabilité mais nul part de facteur 'code propre' c'est trop 'familier' justement aux programmeurs.

Citation:

---

Envoyé par Franck Soriano

Donc quand on me demande si "un code est propre", je regarde s'il est bien codé. Et d'une façon générale, si après l'avoir lu j'ai envi de tout refaire...

---

Quand les chaussettes sont sales, on a envi de les laver pour qu'elles deviennent propres, j'ajoute: et hygiéniques pour éviter les infections, ou des développements de champignions. Laver ou nettoyer consiste à faire un acte préventif contre une forme de mal pas simplement pour le plaisir des yeux.

Pour être plus basique, je dirais que le code est lisible au niveau du compilateur quand il compile.

Ensuite, si le programme déclenche des erreurs/exceptions qui échappent au programmeur qu'on appelle bugs:
1) Si le code a bloqué l'execution du programme (plantage), le code n'est pas propre.
2) S'il a déclenché une erreur inopinée dans le programme, mais qu'il est géré malgré tout sans provoquer de "dégats", le code est propre.

Citation:

---

Envoyé par Garulfo

J'espère que personne n'espère avoir une vraie réponse

---

J'ai essayé de transposer la notion de "propreté" à l'informatique, suis-je dans le vrai ou le faux;).

@Garulfo: on s'ennuit pas sur des discussions argumentées :aie::mrgreen:.

Citation:

---

Envoyé par Souviron

Comme on l'a dit plus haut, quand tu te plonges dans un code nouveau, si tu t'arraches les cheveux pour comprendre, c'est qu'il est mal fait, et donc pas "propre", même si il est rusé..

---

- le terme "rusé" est bien choisi, car il explique souvent des manières de coder qu'on a envi de qualifier de pas propre (et pour cause) même s'il est lisible (par le compilateur).

EDIT:
Voici un exemple d'apprentissage de la propreté, hors contexte informatique, on se fait une meilleure idée du terme propreté ... propre :mrgreen:.

Citation:

---

Envoyé par chaplin

Quand les chaussettes sont sales, on a envi de les laver pour qu'elles deviennent propres, j'ajoute: et hygiéniques pour éviter les infections, ou des développements de champignions. Laver ou nettoyer consiste à faire un acte préventif contre une forme de mal pas simplement pour le plaisir des yeux.

...

Ensuite, si le programme déclenche des erreurs/exceptions qui échappent au programmeur qu'on appelle bugs:
1) Si le code a bloqué l'execution du programme (plantage), le code n'est pas propre.
2) S'il a déclenché une erreur inopinée dans le programme, mais qu'il est géré malgré tout sans provoquer de "dégats", le code est propre.

---

Désolé mais tu n'es pas cohérent entre ta comparaison et ta conclusion. Dans un premier temps, tu dis que le nettoyage (nécessaire pour arriver à la propreté) est un acte préventif pour éviter que d'autres problèmes ne se manifestent ensuite.
Ca va exactement dans le même sens que moi lorsque je parle de bidouilles : Suppression des bidouilles (=nettoyage) avant que ça n'empire que d'autres problèmes plus graves n'apparaissent ;).

Par contre ensuite, tu conclues en définissant : code propre = code qui marche, peu-importe comment, même si dans l'ensemble tous tourne carré.

C'est pas contradictoire non ? :koi:

Citation:

---

Envoyé par Franck SORIANO

Par contre ensuite, tu conclues en définissant : code propre = code qui marche, peu-importe comment, même si dans l'ensemble tous tourne carré.

C'est pas contradictoire non ? :koi:

---

- C'est pas faux de dire qu'un code propre marche, au sens où l'un entraîne l'autre, du moins dans l'idée que je ME fais de la propreté que j'expose et qui peut être sciemment critiqué. Peu importe comment, j'ai donné deux cas de figures, effectivement sans donner une seule fois un exemple de code. Doit-on à ce moment là parler de robustesse d'un code ? Toutes ces notions sont subjectives, ce qui n'empèche pas de s'en faire une idée à partir de situations dont ils ont été tirés pour être "extrapoler" à l'informatique.

Citation:

---

Envoyé par Franck SORIANO

Ca va exactement dans le même sens que moi lorsque je parle de bidouilles : Suppression des bidouilles (=nettoyage) avant que ça n'empire que d'autres problèmes plus graves n'apparaissent .

---

- Oui, je ne te contredis pas, et milite dans ce sens, sinon je n'aurais pas commenté tes propos reformulés dans un langage plus médical.

Citation:

---

Dans un premier temps, tu dis que le nettoyage (nécessaire pour arriver à la propreté) est un acte préventif pour éviter que d'autres problèmes ne se manifestent ensuite.

---

-J'ai repris le terme propreté hors contexte informatique afin d'avoir une meilleure perception,visibilité, lisibilité ... de ce terme.

EDIT:

En fait, je pense que je parle plus de code hygiénique que de code propre :mouarf:.

Pour moi, un code n'est pas propre lorsqu'il sent mauvais. Une odeur de code se perçoit immédiatement et sans réfléchir par un développeur possédant un minimum d'expérience. De fait, la propreté d'un code ne relève pas de l'analyse détaillée d'un code mais capture simplement le ressenti qu'auront spontanément la plupart des développeurs en le découvrant.

Cette immédiateté est d'ailleurs ce qui fait de la propreté d'un code une notion en partie subjective, selon la pratique de chacun et éventuellement sa culture de développeur (un codeur Perl n'aura pas la même notion de propreté qu'un codeur C par exemple).

Dès qu'on explore le pourquoi d'un code qui n'est pas propre, on va commencer à parler de méthodes trop longues, d'effets de bords, de manque de lisibilité, etc. soit tout l'éventail possible de raisons pouvant expliquer pourquoi un code n'est viscéralement pas propre. On n'essaie pas pour autant de définir de manière absolue la notion de propreté.

En gros, pour moi, quand un développeur dit qu'on code n'est pas propre c'est comme un paysan qui annonce qu'il va pleuvoir en regardant le ciel. Les deux peuvent avoir du mal à expliquer pourquoi précisément ils le savent mais, s'ils sont suffisamment expérimentés, ils auront sans doute raison et la plupart de leurs collègues seront du même avis.

Citation:

---

Envoyé par Garulfo

La surcharge d'opérateur fait de C++ un langage plein de caractère non textuel il me semble. Ce n'est donc pas forcément mieux sur ce point. Cependant les caractères spéciaux peuvent être un plus.

Code:

---

{ (x,y) | x <- [1..10] /\ y <- [1..5] }

---

Trouves-tu ça si difficile à lire ?
un « -> » pour une flèche, un « <- » pour un « appartient », « /\ » pour un « et logique » n'est pas si terrible non ? Pas plus tordu qu'un « & » pour une référence, un « :: » pour un opérateur d'accès, un « << » pour un opérateur de flot ou un « && » pour un « et logique ».

Mais bon, quoi qu'il en soit, il serait légitime que tu n'aimes pas ça. C'est affaire de goût après tout. C'est donc un critère peu pertinent pour la lisibilité. Un habitué de Java préférera plus probablement Java à C++.

La question se poserait plutôt sous la forme : si on prend le même langage, qu'est-ce qu'un code lisible écrit dans ce langage. Ça évacue un peu les affaires de goûts personnels.
(.../...)

---

D'accord avec ta conclusion. Pour moi, tous ses signes cabalistiques sont une horreur illisible bonne à jeter à la poubelle. Mais évidemment, je bosse sur des langages "bavards"(VB et surtout COBOL), donc j'ai l'habitude d'avoir les choses en toutes lettres.

Pour moi;

Code:

---

1 2 3

IF A GREATER THAN B MOVE A TO B END-IF

---

est bien plus propre et lisible que

Code:

---

1 2 3 4

if(a>b) { b==a }

---

Alors que 90% des gens ici hurleront le contraire. Parcequ'ils sont habitués à la syntaxe JAVA/C++ et consorts.(il est d'ailleurs possible qu'il y ai une erreur de syntaxe dans mon exemple java, je pratique assez peu.....). J'ai pris l'habitude, en raison de mon domaine d'activité, de lire les éléments en toutes lettres. Et pour moi, c'est bien plus propre comme ça. Notamment parceque "->", sans le manuel, je ne peux pas deviner ce que c'est. ALors que "GREATER THAN", ça, c'est facile, suffit de comprendre l'anglais.....mais oui, c'est purement personel.

Dans le même ordre d'idée, on peut imager l'instanciation des objets comme une fabrique d'objets et
lorsque les objets "manufacturés" ne servent plus à rien il faut les détruire.

Soit, on le fait manuellement, je produis un objet, à la fin de sa vie, je dois le mettre à la décharge.
Soit, c'est fait automatiquement, je produis des objets jetables, mais le camion poubelle passera le
récupérer toute les semaines, c'est le principe du ramasse miette.

Dans la vie réelle, le traitement des déchets devient un vrai casse tête, lorsqu'il y a plusieurs communes, que toutes les décharges ont été fermé et qu'il ne reste plus qu'une décheterie, c'est l'engorgement.
C'est HS, mais il y a de curieuses similitudes entre l'informatique et d'autres domaines plus terre à terre.

Sauf que là tu parles de "propreté" à l'exécution, alors que jusqu'à présent seule la propreté du code en lui-même était évoquée. Mais cela alimente et élargie le débat. Nous allons bientôt pouvoir rédiger un super article intitulé runtime vs. design-time cleanliness 8-)

Citation:

---

Envoyé par chaplin

[..]
C'est HS, mais il y a de curieuses similitudes entre l'informatique et d'autres domaines plus terre à terre.

---

Ce n'est pas curieux. On a choisi les termes un peu en rapport avec similitude. C'est donc normal qu'on y trouve des points communs.

Un code propre, par définition, c'est un code qu'on a fait soi-même :).

Citation:

---

Envoyé par white_tentacle

Un code propre, par définition, c'est un code qu'on a fait soi-même :).

---

Sous la pression du temps, il m'est arrivé de commettre quelques infâmes bouses.....et de maintenir du code très propre fait par d'autres.

Citation:

---

Envoyé par Ricky81

Il existe un livre qui traite (sans doute partiellement) le sujet : http://www.developpez.net/forums/d65...e/#post4271208

---

Je suis en train de le lire, et il reprend dans l'introduction les différents points pré-cités. Plusieurs spécialistes reconnus donnent leur avis, et il y a des différences, comme ici.
En revanche, je n'ai pas encore vu de gars qui disait que 300 lignes pour une fonction, c'était acceptable (pourtant certains travaillaient dans des milieux très sensibles).

Citation:

---

Envoyé par Matthieu Brucher

(.../...)
En revanche, je n'ai pas encore vu de gars qui disait que 300 lignes pour une fonction, c'était acceptable (pourtant certains travaillaient dans des milieux très sensibles).

---

Réponse d'ingénieur : ça dépend. Ca dépend surtout de la complexité du traitement fait dans les 300 lignes. Si c'est un empilage de calculs zarbis, de garnissages divers et autres, C'est évidemment n'importe quoi. Si c'est juste une fonction SQL et son traitement d'erreur, je ne vois pas en quoi c'est mal, ni même comment faire mieux(à moins d'entasser les noms de champs sur quelques lignes, ce qui à mon sens est illisible).