1. #141
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 576
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 576
    Points : 13 423
    Points
    13 423

    Par défaut

    salut el_slapper 9 et 10 pour moi ça ne veut rien dire; ce n'est pas du tout explicite
    Ne dites pas : "chercher la petite bête" mais plutôt "effectuer un travail d'entomologiste."
    Pour corriger des bugs c'est pareil

  2. #142
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 104
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 104
    Points : 22 257
    Points
    22 257

    Par défaut

    Citation Envoyé par Mat.M Voir le message
    salut el_slapper 9 et 10 pour moi ça ne veut rien dire; ce n'est pas du tout explicite
    Ah, je comprends ce que tu veux dire, ça ouvre un autre débat. Le truc, c'est que quand on est sur l'application, c'est explicite : 9, c'est "autres", et 10, c'est "SMUR". (on a aussi ambulances, hélicos, véhicule personnel, pompiers, etc.....). Est-ce que ça a de la valeur ajoutée de créer une liste qui fait correspondre le code à sa valeur? Pour l'appli elle-même, évidemment. If codeTransportSMUR(ou un équivalent explicite), est bien plus lisible que If codeTransport = 10. On est d'accord.

    Mais je ne suis pas coté applicatif. Je suis coté script de test automatique, et, au final, que 10 signifie SMUR, je m'en fous. A la maintenance du script, ça n'a aucune valeur ajoutée. Faut-il le mettre quand même? Mmmmh, bonne question. L'action que j'essaye de coder(entretemps, j'ai fini par la faire marcher, d'ailleurs), c'est juste de choisir la valeur "10" dans cet ActiveX piégeux. Je ne peux pas décemment mettre une valeur "SMUR" (d'autant plus que ça ne marcherait pas, puisque quand le robot tape deux chiffres, ça ne prend que le dernier, et que le code SMUR est sur deux chiffres, à moins de faire une usine à gaz pour un truc que je fais une fois en tout et pour tout).

    Dit autrement, est-ce que ça vaut le cout de surarchitecturer le truc avec une fonction complexe que je ne rappellerais jamais ailleurs(j'en suis à peu près certain), juste pour que le code soit limpide et n'aie pas besoin de commentaires(suite à ta remarque, je crois que je vais juste rajouter un commentaire qui dit que 10="SMUR")? Vaste question. Je ne vais pas le faire, mais je sais que certains me le préconiseraient.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #143
    Modérateur
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    3 363
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 3 363
    Points : 12 744
    Points
    12 744

    Par défaut

    Citation Envoyé par Michael Guilloux Voir le message
    À quelle fréquence pensez-vous utiliser des commentaires ? Rarement, souvent, très souvent ?
    Jamais. Ça a été dur à écrire, ça doit être dur à lire.

    Blague à part, le moins possible, il n'y a rien de pire que du commentaire obsolète induisant en erreur. Les tests automatisés ont bien plus de valeur, il vaut donc mieux écrire un test qu'un commentaire !

    EDIT : Une seule exception, les commentaires de documentation d'API publique.
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  4. #144
    Nouveau membre du Club
    Avatar de the_mummy
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2017
    Messages
    12
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Industrie

    Informations forums :
    Inscription : août 2017
    Messages : 12
    Points : 26
    Points
    26
    Billets dans le blog
    1

    Par défaut

    Ceci devrait faire l'objet d'une UE dans les formations de développement!!!
    il y a trop de développeur (commentateur) chevronnés dans cet univers

  5. #145
    Membre émérite
    Homme Profil pro
    Ingénieur Exploitation Mainframe
    Inscrit en
    octobre 2005
    Messages
    1 321
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Seine Saint Denis (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Exploitation Mainframe
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2005
    Messages : 1 321
    Points : 2 678
    Points
    2 678

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    ...

    Bon, le COBOL est verbeux et les majuscules ont tendance à faire fuir les petits jeunes, désolé. Et tout ceci marche parcequ'on a soigneusement préparé ses booléens en amont. Le SELECT CASE TRUE est considéré comme une horreur dans d'autres langages, mais en COBOL, ça passe très bien ...
    Petite précision, l'instruction de CHOIX multiple en COBOL n'est pas SELECT CASE mais EVALUATE WHEN ...

  6. #146
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    5 104
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 5 104
    Points : 22 257
    Points
    22 257

    Par défaut

    Citation Envoyé par Luc Orient Voir le message
    Petite précision, l'instruction de CHOIX multiple en COBOL n'est pas SELECT CASE mais EVALUATE WHEN ...
    Exact, mais je parlais à des non cobolistes....(et j'ai beaucoup pratiqué le EVALUATE TRUE, donc)
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  7. #147
    Membre éprouvé
    Profil pro
    Inscrit en
    avril 2004
    Messages
    693
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations forums :
    Inscription : avril 2004
    Messages : 693
    Points : 999
    Points
    999

    Par défaut exemples un peu moins niais

    Il est intéressant de considérer des exemples un peu moins niais.
    Soit
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    //data[1..d1,1..d2]
    // somme des carrés
    for i:=1 to d1 do
    for j:=1 to d2 do
    somme:=somme+sqr(data[i,j]);
    ou bien

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    for indice_balayant_la_première_dimension_du_tableau_des_données:=1 to première_dimension_tableau_des_données do
    for indice_balayant_la_deuxième_dimension_du_tableau_des_données:=1 to deuxième_dimension_tableau_des_données do
    somme_des_carrés_des_éléments_du_tableau_des_données:=somme_des_carrés_des_éléments_du_tableau_des_données+sqr(tableau_des_données[indice_balayant_la_première_dimension_du_tableau_des_données,indice_balayant_la_deuxième_dimension_du_tableau_des_données]);
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  8. #148
    Membre expert Avatar de psychadelic
    Profil pro
    Inscrit en
    mai 2010
    Messages
    1 679
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2010
    Messages : 1 679
    Points : 3 416
    Points
    3 416

    Par défaut

    Je me suis fait les dents en C en épluchant les bouquins de Scott Knaster.
    J'ai travaillé sur des bibliotheques en C et C++ sur des produits financiers devant réaliser des formules complexes sur des indices complexes avec des variables complexe ou il faut parfois plusieurs heures avant d'en comprendre le sens et le comment du pourquoi.
    Alors quand t'a passé un semaine sur un swap de taux avec des conversions de monnaies fluctuantes, ben ,tes super content de retrouver un gros commentaire qui t'explique ce qu'il ne faut surtout pas tripoter et un rappel des règles qui s'y appliquent, voir même des petits rappels triviaux pour te dire que cette variable joue sur un taux directeur, même si elle s'appelle justement taux_directeur, parce que je ne connais pas un développeur capable de garder la tête froide en jonglant avec 36 formules mathématiques et financières à longueur de journée.

    Et pour en revenir à Scott Knaster, je fais comme lui, je dissémine de l'humour au second degré dans mon code (mais toujours en lien avec l’algorithme, parce que je me suis rendu compte que cela faisait toujours plaisir à ceux devaient re-tripoter le code, et que s'il est placé au bon endroit cela leur permettait de mieux se souvenir des écueils à éviter.

    Les exemples de codes sur le sujet , c'est du flan à coté.
    «La pluralité des voix n'est pas une preuve, pour les vérités malaisées à découvrir, tant il est bien plus vraisemblable qu'un homme seul les ait rencontrées que tout un peuple.» [ René Descartes ] - Discours de la méthode

  9. #149
    Membre du Club
    Profil pro
    Inscrit en
    juin 2009
    Messages
    18
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 18
    Points : 45
    Points
    45

    Par défaut

    Citation Envoyé par hotcryx Voir le message
    Les commentaires ça sert à rien, c'est pas compilé (troll off)
    Y a pire : ajouter un checkArgument compilé à la place d'un commentaire rappelant pourquoi on peut s'en passer ... (cf. l'avant dernier exemple ... qui est peut-être situé juste 10 lignes en dessous du checkArgument)

  10. #150
    Membre averti

    Profil pro
    Étudiant
    Inscrit en
    décembre 2004
    Messages
    499
    Détails du profil
    Informations personnelles :
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2004
    Messages : 499
    Points : 445
    Points
    445

    Par défaut

    Il me semble que vous n'avez pas parlé de la distinction énorme entre lire le code et l'exécuter avec un débugger.

    À mon avis utiliser un débugger pour comprendre comment fonctionne un code c'est tout un art, dont bien des aspects restent encore à être développés,

    et qu'en la matière les bonnes pratiques vont beaucoup plus loin que l'idée d'écrire un code propre et localement lisible avec quelques commentaires pertinents.

    Typiquement la facilité à comprendre une méthode dépend énormément des paramètres donnés en entrée. C'est con mais pour comprendre un algorithme sur une liste, donner en entrée la liste vide ça marche moins bien.

  11. #151
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    1 931
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 1 931
    Points : 6 147
    Points
    6 147
    Billets dans le blog
    2

    Par défaut

    Un code bien fait a des messages d'erreurs assez clairs pour comprendre ce qui ne va pas. Nécessiter le débogueur (ou des prints supplémentaires) pour comprendre ce qui ne va pas indique avant tout un code qui mériterait d'être amélioré.

    Dit autrement, si "comprendre comment fonctionne un code c'est tout un art", que ce soit avec un débogueur ou un outil plus adapté, c'est que le code n'est pas aisément compréhensible. Or c'est justement l'objet d'une structuration logique du code, d'un nommage clair, de la documentation (messages d'erreurs inclus) et des commentaires (ce dernier étant l'objet du sujet). Si une information est nécessaire à la compréhension, soit elle doit être donnée, soit les informations nécessaires pour l'obtenir doivent être données à la place. Pour le dernier cas, je pense notamment aux informations qui sont techniquement ou légalement indisponibles.

    Même si on peut toujours parler du débogueur pour être plus exhaustif, c'est regarder les conséquences plutôt que les causes, ce n'est donc pas régler le problème de manière définitive.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

Discussions similaires

  1. Réponses: 25
    Dernier message: 06/01/2013, 17h22
  2. Faut-il commenter son code source pour le rendre plus lisible et maintenable ?
    Par mayayu dans le forum Débats sur le développement - Le Best Of
    Réponses: 149
    Dernier message: 09/11/2009, 02h30
  3. Bien commenter son code Java
    Par shaun_the_sheep dans le forum Général Java
    Réponses: 2
    Dernier message: 27/05/2008, 11h13
  4. Comment commenter son code source proprement ...
    Par basnifo dans le forum MFC
    Réponses: 3
    Dernier message: 31/03/2006, 16h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo