Developpez.com - Rubrique ALM

Le Club des Développeurs et IT Pro

Qualité logicielle : Qu'est ce qu'un code propre selon vous ?

Le 2009-04-24 14:15:22, par brice01, Membre régulier
qu'un code "propre" selon vous ?
  Discussion forum
499 commentaires
  • gwenBZH
    Membre du Club
    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.
    le 24/04/2009 à 14:44
  • Hephaistos007
    Expert confirmé
    Envoyé par gwenBZH
    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.
    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
    le 28/04/2009 à 18:30
  • Nebulix
    Membre expérimenté
    Envoyé par jabbounet
    C'est aussi le tiens, si tu as un rôle quelconque par rapport au devenir de ce logiciel, que ce soit en tant que codeur ou big boss , chaque personne a sa part de responsabilité.
    je suis peu être un peu bête mais j'ai horreur de me défausser sur quelqu'un d'autre...

    Le style direct d'un forum peut conduire à des incompréhensions. Le "tu" que j'ai employé s'adresse à tout le monde, moi compris. Nous sommes là pour partager nos expériences et améliorer nos pratiques, exprimer des désaccords, pas critiquer des personnes. Si tu t'es senti personnellemnt visé, je te prie de m'excuser.
    le 10/09/2009 à 9:25
  • el_slapper
    Expert éminent sénior
    Envoyé par ouhraniufr
    Bonjour,
    Qui peut me dire, comment peut on améliorer la lisibilité d'un code? je serai très reconnaissante si je trouve une repense
    Merci

    Très bonne question, mais la réponse dépend fortement du langage - et de son état. Je peux te donner des conseils pour du Cobol généré automatiquement(une horreur que j'ai appris à dompter par la force des choses), mais pas pour du java(dont les contraintes structurelles sont radicalement différentes).

    Un truc quand même : les tests. Rendre un code plus lisible, c'est prendre le risque de le casser(surtout si on réorganise un boucle qui fait 2 pages et qui tourne sur des GO TO et des compteurs gérés en dur). Donc, avoir une couverture de tests complète, si possible automatique, pour vérifier qu'on ne casse rien. Et avoir les moyens de revenir en arrière(versions, sauvegardes...).
    le 15/03/2012 à 16:16
  • koala01
    Expert éminent sénior
    Envoyé par ouhraniufr
    Bonjour,
    Qui peut me dire, comment peut on améliorer la lisibilité d'un code? je serai très reconnaissante si je trouve une repense
    Merci
    De manière très générale (car toutes les situations sont différentes), je conseillerais, dans un premier temps:
    1. de choisir des noms explicites (qui indiquent, rien qu'à la lecture, de que l'on fait), en fonction des restrictions imposées par le langage
    2. de respecter des règles strictes de nommages (éviter d'avoir un nom de fonction qui commence par une majuscules et un autre qui commence par une minuscule, par exemple )
    3. d'indenter correctement les différents blocs les uns par rapport aux autres, de manière à pouvoir les repérer
    4. de respecter la règle d'une ligne par instruction
    5. de placer les symboles de blocs (si le langage en définis) même lorsqu'ils ne sont pas requis
    6. de ne pas hésiter à commenter un bloc de code qui serait vraiment trop nébuleux (en veillant cependant autant que possible à décrire la raison pour laquelle on fait quelque chose et non ce que l'on fait )
    7. d'éviter autant que possible les sucres syntaxiques s'ils n'apportent vraiment rien

    Dans un deuxième temps, on peut envisager un refactoring au niveau des fonctions en:
    1. séparant correctement les différentes responsabilités de sorte à ce que chaque fonction n'en ai pas plus d'une
    2. factorisant au besoin certains blocs de fonction
    3. essayant d'arriver à des fonctions de "taille acceptable": 20 à 30 lignes ( +/- XX ) par fonction, c'est déjà pas mal
    Si le code reste encore nébuleux malgré tout cela, peut etre faudra-t-il refactorer plus en profondeur, mais on entre alors dans un autre débat qui tient carrément de la conception
    le 15/03/2012 à 18:13
  • chaplin
    Membre chevronné
    Envoyé par souviron34
    Ce qui se conçoit bien s'énnonce clairement
    D'un point de vue plus subjectif, quand un code est propre, on a envie de le lire par opposition à sale ou dégoutant.
    le 24/04/2009 à 14:42
  • rakakabe
    Membre habitué
    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.
    le 24/04/2009 à 18:08
  • Melem
    Expert éminent
    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.
    le 26/04/2009 à 10:26
  • souviron34
    Expert éminent sénior
    Envoyé par Melem
    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.
    Si, cela en fait partie, même si ce n'est pas exhaustif..

    Mais c'est un élément essentiel..

    Envoyé par Melem
    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.
    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 rougis d'être cité
    le 26/04/2009 à 15:45
  • chaplin
    Membre chevronné
    Envoyé par souviron34
    @chaplin : je rougis d'être cité
    - C'est une parole de sage , et comme je tu l'as cité plusieurs fois et de façon plus ou moins développée, ça me fait penser :

    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 .
    le 26/04/2009 à 15:57
  Poster une réponse