Sondage Les commentaires et vous ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes : aucune
11
22
oct.
2013

Pour faire suite à ce journal sur les commentaires, commentez-vous votre code ?

be brave

  • Oui :
    1249
    (49.2 %)
  • Non :
    259
    (10.2 %)
  • Chuck Norris ne commente pas son code c'est le code qui commente Chuck Norris :) :
    416
    (16.4 %)
  • 42 lignes de commentaires, pas plus :
    196
    (7.7 %)
  • La Matrice n'est pas commentée :
    194
    (7.6 %)
  • Je ne code pas, je ne fais que commenter les codes des autres. :
    227
    (8.9 %)

Total : 2541 votes

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # no comment.

    Posté par  . Évalué à 10.

    no comment.

    • [^] # Re: no comment.

      Posté par  . Évalué à 5.

      Je commente systématiquement. Mais, tout à fait bizarrement, chaque fois que je dois intervenir dans du code écrit par un autre, je m'aperçois que cet autre fait parie de 9,4 % de gens qui ne commentent pas ! C'est trop injuste.

  • # Faut voir...

    Posté par  . Évalué à 4.

    Les noms de variable et de fonction, ça compte? :p

    • [^] # Re: Faut voir...

      Posté par  . Évalué à 10.

      Bin pareil, le code se doit d'être auto-documenté (compréhensible par les noms de vars/fonctions),
      je ne commente que les parties dites "tricky".

      • [^] # Re: Faut voir...

        Posté par  . Évalué à 3.

        Pour être honnête, je document aussi les pré-conditions, post-conditions et invariants qui ne sont pas évidents et/ou des fonctions publiques. Histoire de pas aller fouiner dans le code lui-même à chaque fois…

        Mais j'appelle pas trop ça du commentaire, plutôt de la doc, même si c'est fait via des commentaires doxygen.

        • [^] # Re: Faut voir...

          Posté par  . Évalué à 4.

          Oui,

          plus que commenter, je dirai qu'il est important de documenter son code. Comment on utilise telle ou telle fonction, etc. Ça me semble primordial.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 4. Dernière modification le 22 octobre 2013 à 22:57.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 6.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # L'art de programmer

    Posté par  (site web personnel) . Évalué à 10.

    Programmer est un art…

    Titre de l'image

    (Geek&Poke, CC-BY 3.0)

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 10. Dernière modification le 22 octobre 2013 à 13:08.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Oh, le joli commentaire !

    Posté par  (site web personnel) . Évalué à 10.

    Je viens de reconnaître le code de l'illustration : c'est du coffeescript que j'ai écrit pour le teabook-open-reader.

    • [^] # Re: Oh, le joli commentaire !

      Posté par  (site web personnel) . Évalué à 6.

      Enfin quelqu'un qui a trouvé l'origine ;-)

      J'avais pris l'exemple là (après avoir bossé dessus) parce que je trouvais que ça illustrait pas mal un aspect important des commentaires : quelque chose que le code ne peut pas dire.
      Typiquement c'est le genre de commentaire qui ne peut pas être traduit en code et si on l'enlève il manque réellement quelque chose (en plus du fait que c'est un commentaire qui indique qu'il faut lire les commentaires)

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 10.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Oh, le joli commentaire !

          Posté par  (site web personnel) . Évalué à 3.

          Pfff… évidemment si tu prends celui là. Et je parlais bien évidemment du 

          # So, you should avoid to modify this file. But if you have to, be brave and
# read the comments to avoid some pitfalls.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 2.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Oh, le joli commentaire !

              Posté par  . Évalué à 2.

              Peut-être était-ce du second degré. C'est plausible, non ?

              • [^] # Re: Oh, le joli commentaire !

                Posté par  (site web personnel) . Évalué à 5.

                Non (nono pourra préciser) ça voulait vraiment dire : « Fait gaffe, c'est beaucoup plus complexe que tu ne crois et tout se base sur les comportements défini ici. Donc fait pas nimp avec et si tu as besoin de le modifier réfléchis bien à ce que tu fais. »

                En tout cas c'est comme cela que je l'ai interprété, et vu que j'ai eu à bosser dedans j'étais satisfait de voir cet avertissement. Alors c'est vrai qu'on peut débattre de manière théorique de l'utilité de de la possibilité de faire passer le message autrement, mais en pratique ce commentaire était je trouve fort à propos.

                • [^] # Re: Oh, le joli commentaire !

                  Posté par  (site web personnel) . Évalué à 7.

                  Je confirme. Ce fichier est assez central, il implémente une bonne partie de la spec epub3 fixed layouts. Il peut être assez tentant de venir modifier des choses dans ce fichier pour implémenter certains fonctionnalités en prenant un raccourci. Mais c'est une fausse bonne idée, on se retrouve vite avec plein de cas particuliers qui ne fonctionnent plus. La spec epub3 fixed layout a été écrite par des gens qui ne sont pas forcément super techniques (elle a été poussée par les gens qui créent les contenus, pas ceux qui s'occupent des outils autour des epub, et ça s'en ressent). Du coup, le commentaire sert à prévenir les futurs contributeurs que n'importe quelle modification dans ce fichier prendra plus de temps que ce que l'on pourrait croire et qu'il faudra souvent beaucoup de courage pour chasser les bugs sur des cas très particuliers.

  • # Les commentaires c'est bien

    Posté par  . Évalué à 7.

    Je trouve que des bons commentaires, c'est un vrai bonheur.

    Pour ma part, deux règles simples :
    - donner des exemples aux fonctions simples (ce qui permet de voir ce que fait une fonction, sans avoir a lire son code !)
    - donner des liens croisés : vers d'autres parties du code quand cela permet d'aller plus vite (ou est la classe XXXX qui utilise ce bout de code que je regarde ?), ou des urls pour expliquer un truc compliqué (on évite de laisser le lecteur sans explication)

    Pensez à celui qui relit votre code (souvent, c'est vous-mêmes, 6 mois plus tard).

    Ahem, heu, voila.

    • [^] # Re: Les commentaires c'est bien

      Posté par  . Évalué à 2.

      "ou est la classe XXXX qui utilise ce bout de code que je regarde ?", c'est le boulot de l'IDE.

      • [^] # Re: Les commentaires c'est bien

        Posté par  (site web personnel) . Évalué à 5. Dernière modification le 22 octobre 2013 à 13:29.

        "ou est la classe XXXX qui utilise ce bout de code que je regarde ?", c'est le boulot de l'IDE.

        Pas forcément ! Tout dépend du langage dans lequel tu codes. C'est vrai quand tu fais du Java dans Eclipse, ou plus généralement quand tu utilises un langage fortement typé. Mais si tu utilises un langage à base de « duck typing » ou plus généralement à inférence de type, l'IDE est généralement perdu!

        Je fais pas mal de Java et de ruby et j'adopte les deux techniques : Java/Eclipse et commentaires/tags dans Ruby/Vim. Ce sont deux approches différentes qui ont chacune leurs avantages et inconvénients.

        Mais soyons clair : Java sans IDE, c'est même pas la peine :)

    • [^] # Re: Les commentaires c'est bien

      Posté par  (site web personnel) . Évalué à 10.

      Pensez à celui qui relit votre code (souvent, c'est vous-mêmes, 6 mois plus tard).

      "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
      - Martin Golding

      • [^] # Re: Les commentaires c'est bien

        Posté par  . Évalué à 5.

        "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."

        C'est marrant, moi j'ai toujours appliqué :

        "Always code so the guy who ends up maintaining your code will be a violent psychopath".

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Les commentaires c'est bien

      Posté par  . Évalué à 4.

      • donner des exemples aux fonctions simples (ce qui permet de voir ce que fait une fonction, sans avoir a lire son code !)

      Non, pour ça tu fais des tests unitaires. Les commentaires se déprécient facilement, les tests unitaires ne mentent pas.

      • donner des liens croisés : vers d'autres parties du code quand cela permet d'aller plus vite (ou est la classe XXXX qui utilise ce bout de code que je regarde ?), ou des urls pour expliquer un truc compliqué (on évite de laisser le lecteur sans explication)

      Pareil trop complexe à mettre à jour c'est le boulot d'un outil qui va analyser le code. Tu peut mettre des grands principes en commentaire (par module par exemple), mais pas de qui utilise quoi comment.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Méthode moyenageuse

    Posté par  (site web personnel) . Évalué à 3.

    Coupons une main aux développeurs qui ne commentent pas leur code

    • [^] # Re: Méthode moyenageuse

      Posté par  . Évalué à 10.

      Bah oui mais après ils vont encore moins commenter…

      • [^] # Re: Méthode moyenageuse

        Posté par  . Évalué à 2.

        … tout en ayant pas de mal à continuer à coder (voire en devenant même plus productif) : code by voice faster than keyboard.

        • [^] # Re: Méthode moyenageuse

          Posté par  . Évalué à 3.

          Même si c'est génial, c'est quand même beaucoup plus efficace d'apprendre la frappe à 10 doigts sur une vraie disposition.

          Écrit en Bépo selon l’orthographe de 1990

          • [^] # Re: Méthode moyenageuse

            Posté par  (site web personnel) . Évalué à 1.

            Le bépo (non modifié) n'est clairement pas orienté programmation.

            • [^] # Re: Méthode moyenageuse

              Posté par  . Évalué à 1.

              Subjectivement, je dirais que c'est la meilleure.

              Objectivement, je dirais que c'est 10× meilleur que l'azerty, le qwerty et le Colemak, et meilleur que le Dvorak.

              Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Méthode moyenageuse

                Posté par  . Évalué à 4.

                Objectivement, je dirais que c'est 10× meilleur que l'azerty, le qwerty et le Colemak, et meilleur que le Dvorak.

                Objectivement je dirais que si tu as investi le temps d'apprendre correctement plus de 5 layouts pour écrire du code (qui d'ailleurs demande très peu de frappe) tu as un peu fait fausse route à un moment… Niveau productivité y'a moyen d'investir sont temps de manière plus payante je pense…

                • [^] # Re: Méthode moyenageuse

                  Posté par  . Évalué à 2.

                  J’ai appris que le Bépo, mais juste à voir la place des symboles sur les dispositions, ça fait peur (l’exemple le plus frappant selon moi, c’est que {}, [] et () sont sur l’annulaire et l’auriculaire droit — à part sur l’azerty).

                  Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Méthode moyenageuse

                Posté par  . Évalué à 2.

                Objectivement, je pense que les dispositions suivantes sont plus adaptées à la programmation, à l'administration système et dès que l'on touche à de l'anglais en générale.

                http://bepo.fr/wiki/B%C3%A9po_technique

                • [^] # Re: Méthode moyenageuse

                  Posté par  . Évalué à 2.

                  Tu m’a vraiment donné envie de modifier ma disposition pour qu’elle soit encore plus efficace, par contre je sens que ça va me prendre du temps, grâce à toi j’aurais encore moins de temps pour mes projets persos! Greu.

                  Écrit en Bépo selon l’orthographe de 1990

                  • [^] # Re: Méthode moyenageuse

                    Posté par  . Évalué à 1.

                    L'inconvénient c'est que c'est impossible d'avoir une disposition qui soit parfaite pour tous les usages, et du coup il faudrait apprendre plusieurs variantes du bépo suivant les cas (c'est sans doute possible, mais de quoi s'embrouiller quand même un peu, en tous cas moi j'aurais du mal). Par exemple, pour écrire de la prose les dispositions optimisées pour la programmation du wiki sont logiquement moins adaptées, et ça se sent encore plus si on veut écrire dans d'autres langues. Actuellement j'utilise bépo pour écrire en français, espagnol, espéranto et anglais, et le bépo standard marche globalement bien pour toutes ces langues (à part le « w » en anglais), et c'est difficile de faire des changements pour gagner d'un côté sans perdre trop ailleurs : en pratique je fais juste quelques remapages sur vim dans des cas spécifiques où je sais que telle touche ne me sert pas pour un certain type de document.

                    • [^] # Re: Méthode moyenageuse

                      Posté par  . Évalué à 3.

                      Bah en virant tout ce que t’utilises pas et que tu n’as aucune chance d’utiliser un jour, ça fait beaucoup de place. Beaucoup beaucoup beaucoup de place. Et plaçant les symboles de façon moins logique, tu peux encore optimiser. Par exemple, en mettant ©, ® et ™ à un endroit moins facile d’accès parce qu’on ne les utilise presque jamais. J’ai pensé à mettre © et ® en AltGr+Maj+C et AltGr+Maj+R par exemple.

                      Écrit en Bépo selon l’orthographe de 1990

              • [^] # Re: Méthode moyenageuse

                Posté par  (site web personnel) . Évalué à 1. Dernière modification le 23 octobre 2013 à 22:51.

                J'ai utilisé aucune disposition que tu cites. En Suisse on a du qwertz. C'est pas l'idéal pour coder, mais c'est correct.
                Mais à propos du bépo, j'ai personnellement dû modifier la disposition avant de me sentir à l'aise pour programmer.

                Tu peux voir les changements apportés ici :
                https://gist.github.com/dgellow/5915994

                • [^] # Re: Méthode moyenageuse

                  Posté par  . Évalué à 2.

                  Pour le problème majeur pour le qwertz, c’est le même que pour le qwerty: la position désastreuse des parenthèses.

                  Bon j’avoue que pour le Bépo il faudrait améliorer la position de = et de $ (pour moi les deux gros trucs à changer).

                  Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: Méthode moyenageuse

                  Posté par  . Évalué à 7.

                  Dommage qu'en Suisse vous n'utilisiez pas du qwartz…

                  Je ne suis plus là → []

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Méthode moyenageuse

                    Posté par  . Évalué à 0.

                    Ben ? je croyais que c'était les spécialistes des montres (à qwartz) en suisse ?

                    attend moi → []

            • [^] # Re: Méthode moyenageuse

              Posté par  . Évalué à 1. Dernière modification le 24 octobre 2013 à 00:30.

              Si en plus le type utilise EMACS, ce ne serait pas très gentil pour lui.

            • [^] # Re: Méthode moyenageuse

              Posté par  (site web personnel) . Évalué à -1.

              si si tu programme en logo français, les mots clefs sont en français LOL.

        • [^] # Re: Méthode moyenageuse

          Posté par  . Évalué à 5.

          Lorsque je code, le temps de réfléction est toujours bien plus grand que le temps de frappe, donc coder à la voix, bof, bof.

    • [^] # Re: Méthode moyenageuse

      Posté par  . Évalué à 4.

      Et l'autre à ceux qui ne codent pas leurs commentaires…

      • [^] # Re: Méthode moyenageuse

        Posté par  . Évalué à 9.

        Moi mon soucis c'est quand le code et le commentaires ne disent pas la même chose…
        Du coup je mets pas de commentaires pour ne pas m'enduire d'erreur.

        • [^] # Re: Méthode moyenageuse

          Posté par  . Évalué à 0.

          T'induire, non ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # La bonne question serait plutôt : Que commentez-vous ?

    Posté par  . Évalué à 7.

    J'ai le sentiment que ce n'est pas forcément faisable, ni souhaitable, de commenter la totalité de son code. Par commenter la totalité de son code j'entends associer un commentaire type "javadoc" à chaque fonction/méthode que l'on code. D'autant que dans certains cas la valeur ajoutée est vraiment très faible. Quelle est l'utilité réelle de commentaires comme les suivants :

    /** Computes the threshold based on the red component
  * on the pixel with the highest red component in
  * the picture
  *
  * @param maxRedValue
  *     The red component of the pixel with the highest red component
  * @return the computed threshold
  */
double computeThreshold(int maxRedValue) {
   ...
}

/**
  * Get the user ID
  *
  * @return the user ID
  */
int getID() {
   ...
}

    Mieux vaut dépenser son temps à bien penser l'architecture de son application/refactoriser si nécessaire plutôt que de le perdre à écrire ce genre de commentaires. Un document expliquant l'architecture de l'application/la manière dont elle a été conçue et pensée sera bien plus utile à quelqu'un voulant la modifier que ce type de commentaires.

    La situation est évidemment différent quand il s'agit d'API publiques. Dans ce cas, évidemment tout doit être précisément documenté sinon elles sont inutilisables et donc inutiles.

    Il faut bien garder à l'esprit qu'écrire des bons commentaires pour son code, c'est pas juste une bonne pratique, ça prend beaucoup, beaucoup de temps. D'autant plus qu'il faut maintenir les commentaires avec le code sinon ils font plus de mal que de bien. Je crois donc qu'on peut se passer de commentaires dans les classes utilisées en interne.

    J'ai eu l'occasion de mettre les mains dans le code d'Hadoop et apparemment, c'est l'approche qu'ils ont choisi. Les classes utilisés en interne ne sont pas commentées (si ce n'est de petits commentaires pour indiquer des choses pas évidentes au premier coup d'œil). Les API publiques sont par contre parfaitement documentées.

    • [^] # Re: La bonne question serait plutôt : Que commentez-vous ?

      Posté par  (site web personnel) . Évalué à 3.

      Je suis assez d'accord, mais des fois je me surprends à commenter des trucs évidents, car j'ai l'impression que le temps que je passe à commenter est inférieur au temps que je passerai à me demander si je dois commenter ou non….

      Je crois que la solution est un mélange de « code de bonne pratique » (des règles qui permettent de couvrir pas mal de cas sans se poser de question) et de systématisme (commenter par défaut, et ne pas commenter pour les cas d'exception). Sinon on ne commente rien.

      PS : le code que tu donnes en exemple ne me choque pas, je ne trouve pas les commentaires néfastes. Il y a des cas bien pires.

    • [^] # Re: La bonne question serait plutôt : Que commentez-vous ?

      Posté par  . Évalué à 2.

      C'est pour ça que j'ai arrêté les documentations qui paraphrasent le nom et le type de la variable. Ca sert juste a rien dans 95% des cas.

      Je préfère documenter les pré/post conditions, les invariants et les throw.
      Bref, le contrat, et ce qui est fait si le contrat n'est pas respecté.
      Je pense vraiment que c'est la meilleure approche, ça m'évite de paraphraser mon code, et donc la quantité de merde commentaires diminue drastiquement, tout en fournissant des informations bien plus pertinentes (même si il est vrai qu'on les retrouve dans le code, mais c'est parfois éparpillé dans les 20-30 lignes de fonction…)

      Quant aux return… bah c'est aussi rarement utile que les paramètres dans un langage qui supporte les exceptions, puisque dans ce cas on peut se permettre de ne pas s'en servir pour indique si y'a eu ratage ou pas.

      Et même comme ça, je ne commente pas les fonctions triviales (genre moins de 5 lignes). Bon, après, j'ai une très nette préférence pour les langages ayant un typage fort, donc je pense que ça aide pas mal. Quand on passe un const &uint8_t, on sait déjà beaucoup de choses sur le paramètre, même sans son nom.
      Et si j'ai besoin de flags, plutôt que d'utiliser un moche int, je lui mets au moins un typedef, et en général je suis plutôt du genre à vouloir utiliser des bitfield. Plutôt que d'utiliser des #define dont on ne sait jamais trop où, quand et comment ils sont définis, et ne seront jamais vérifiés par le compilo.

  • # 42

    Posté par  . Évalué à 8. Dernière modification le 22 octobre 2013 à 15:30. 

    # grep "^#" libweb.php  | wc -l
40

# wc -l libweb.php 
2594 libweb.php

    D'ici 2 jours, je serai à 42 commentaires. Ça sera donc la version finale.

    • [^] # Re: 42

      Posté par  (site web personnel) . Évalué à 2.

      J'ai jamais compris pourquoi les gens faisaient 'grep pat file | wc -l' au lieu d'un simple 'grep -c pat file'.

      git is great because linus did it, mercurial is better because he didn't

      • [^] # Re: 42

        Posté par  (site web personnel) . Évalué à 6.

        J'ai jamais compris pourquoi les gens faisaient 'grep pat file | wc -l' au lieu d'un simple 'grep -c pat file'.

        Simple : ils ont commencé par faire un 'grep pat2 file' mais ça ne renvoyait pas ce qui était attendu, alors ils ont essayé 'grep pat file' qui était ce qu'ils voulaient. Du coup ils rajoutent un '| wc -l' pour compter les lignes. Évidemment si on leur demandait le nombre de lignes contenant pat dans un fichier, ils auraient écrit directement 'grep -c pat file'. Quand on écrit une ligne plus ou moins compliquée à coup de '|', on se préoccupe rarement de la simplifier après coup si elle donne le bon résultat (et que l'on en compte pas exécuter 1 million de fois cette ligne ou l'exécuter sur 1 giga ou 1 gibi de données, donc qu'aucune optimisation n'est nécessaire).

        • [^] # Re: 42

          Posté par  . Évalué à 2.

          À vrai dire, rien de tout ça. Je dirais que j'ai utilisé 'grep pat file | wc -l' pour que la commande soit le plus compréhensible possible.

          • [^] # Re: 42

            Posté par  . Évalué à 10.

            Oui, alors qu'elle aurait été tout aussi compréhensible s'il l'avait commentée, par exemple:

            grep -c pat file # compter le nombre d'occurrences de pat dans file

            (désolé, pas pu résister)

            • [^] # Commentaire supprimé

              Posté par  . Évalué à -10.

              Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: 42

          Posté par  . Évalué à 10.

          et que l'on en compte pas exécuter 1 million de fois cette ligne ou l'exécuter sur 1 giga ou 1 gibi de données, donc qu'aucune optimisation n'est nécessaire

          Franchement pour avoir beaucoup bossé sur des vrais gros volumes de données et sur des échantillons qui permettent de ne pas être IO bound bien franchement l'optimisation des pipes inutiles et les adaptes du UUOC me font juste marrer. Dans 99.9% il n'y a aucune différence. Les années 90 c'est fini depuis un moment…

          $ ls -lh source.1GB  ; wc -l source.1GB 
-rw-rw-r--. 1 user user 1.2G Oct 23 20:06 source.1GB
15993320 source.1GB

# Baseline des perfs IO
$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" && pv source.1GB > /dev/null
1.16GiB 0:00:16 [72.9MiB/s] [=================================================================================================>] 100%

          IO bound:

          $ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" && /usr/bin/time -f "=> %E" sh -c 'grep -c foo source.1GB'
7860
=> 0:16.25

$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" && /usr/bin/time -f "=> %E" sh -c 'grep foo source.1GB | wc -l'
7860
=> 0:16.17

$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" && /usr/bin/time -f "=> %E" sh -c 'cat source.1GB | grep foo | cat | grep -v ======== | cat | cat | sed "s/bar/baz/" | awk "{print $0 }" |wc -l'
7860
=> 0:16.45

          En cache:

          $ /usr/bin/time -f "=> %E" sh -c 'grep -c foo source.1GB'
7860
=> 0:01.69

$ /usr/bin/time -f "=> %E" sh -c 'grep foo source.1GB | wc -l'
7860
=> 0:01.69

$ /usr/bin/time -f "=> %E" sh -c 'cat source.1GB | grep foo | cat | grep -v ======== | cat | cat | sed "s/bar/baz/" | awk "{print $0 }" |wc -l'
7860
=> 0:01.71

          Notons que les exemples sont sur ~1Go, mais les différences n'évoluent pas quelque soit la taille des fichiers que ce soit sur 10Mo ou 100Go.

          Bref sauf cas totalement patologique, tu peux faire autant de UUOC que tu veux, utiliser trois outils différents alors qu'un pourrait suffire ça n'a strictement aucun impact dans la vie réelle. La différence de perf est bien plus petite que la marge d'erreur. Si tu cherches à optimiser tes batchs tu te bas clairement pas sur cet ordre de grandeur et tu fais les choses bien différemment.

          Donc il faut arrêter avec les UUOC et autres bêtises. Construisez vos commandes de la façon la plus pratique possible pour l'édition. Par exemple il peut être très pratique de laisser la partie qu'on est en train de bidouiller à la fin de la ligne plutôt qu'au début. Par exemple "grep token file" peut être plus chiant à éditer que "cat file | grep token". De même quand on construit ses enchaînement de pipes petits à petit.

          • [^] # Re: 42

            Posté par  . Évalué à 3.

            Donc il faut arrêter avec les UUOC et autres bêtises.

            C'est une manière de dire que lire les man c'est vachement instructif même quand on crois connaître une commande (donc même sur ls par exemple).

            Ensuite pour les performances. Ça ne pose aucun souci de multiplier les pipe c'est assez logique car on lance simplement 2 processus en pipe leur entrée/sortie standard. Ça ne coûte pas grand chose. Par contre tu vois les choses très différemment si tu as tout ça dans une boucle ou plus sérieusement dans un script lancé via xargs. Il y a un moment où le coût des fork() va avoir un impact non négligeable sur les performances (de l'ordre de 30 % dans le cas que j'avais observé) en réduisant au maximum les commandes externe pour les remplacer soit par une commande builtin soit par une seule commande externe, on a eu un gain assez important. C'était un cas un peu extrême mais qui a existé.

            Enfin les pipe peuvent au contraire augmenter les performances. Lancer une commande qui met un temps t a traiter chaque ligne est moins intéressant que lancer 2 commandes avec un pipe qui mettent chacune un temps t/2 pour faire le boulot.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: 42

          Posté par  . Évalué à 3.

          Je pense que ça viens surtout d'un manque de déplacement dans la CLI. Peut de gens (je trouve) utilisent Ctrl+a, Ctrl+w, Ctrl+e, Alt+f,…¹

          Ici, tu fais ton grep de test, tu vois que ça marche Ctrl+a,Alt+f puis "-c ", entrée. C'est plus rapide à écrire.

          [1] les terminaux virtuels sont souvent à blâmer ils interceptent la plupart de ces raccourcis par défaut.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Code auto-documente

    Posté par  . Évalué à 2.

    Un code qui a besoin de documentation est souvent un code qui a besoin d'un bon refactoring : reorganiser, diviser en sous-fonctions/methodes, mieux nommer les variables. Si le code n'est pas toujours bien a jour, les commentaires ne le sont quasiment jamais. Pour citer le bouquin clean code : "les commentaires mentent". Dont je recommande par ailleurs la lecture.
    Le commentaire doit etre occasionnel, indispensable et justifie (les commentaires auto en Java sur les getters/setters sont justes inutiles…). Le manque de temps pour ameliorer le code n'etant pas une justification ;). Si c'est du code rapide et jetable, il doit pouvoir etre jete, et ne pas devenir vital…

    • [^] # Re: Code auto-documente

      Posté par  . Évalué à 3.

      Le code auto-documenté, c'est surtout une excuse à la con pour justifier quelque chose dont on devrait avoir honte (à savoir ne pas ecrire de commentaires). Un code a toujours besoin de documentation/commentaire, ne serait ce que pour indiquer le role des fonctions, pour expliciter une astuce ou un truc pas evident à voir. Jamais j'utiliserais une librairie qui n'a pas un minimum de doc expliquant en detail chacune des methodes disponibles. Apres peut etre qu'il y en a qui aiment le risque : vous le paierez un jour.

      J'ai jamais vu "in real life" des commentaires du style "j'initialise x à 3", et pour les getters/setters quen j'ai vu commentés, c'etait à chaque fois l'edi qui generait ce code : pourquoi prendre ces exemples bidons pour justifier quelque chose qui en devrait pas l'etre ?
      Quant aux commentaires qui mentent, malheureusement il y en a. Est ce que pour autant, on doit jeter le bebe avec l'eau du bain ?

      HS : j'aime beaucoup la police de l'image, quelqu'un a une idée de son nom ?

      • [^] # Re: Code auto-documente

        Posté par  . Évalué à 3. Dernière modification le 22 octobre 2013 à 17:17.

        HS : j'aime beaucoup la police de l'image, quelqu'un a une idée de son nom ?

        Ubuntu.

        La fonte sans empattement est chouette, mais celle à chasse fixe a des point/virgule/deux points trop petits (1 pixel) et elle est trop grosse en gras avec lissage moyen ou fort, et le rendu est pas terrible en léger je trouve (d'ailleurs je suis allergique au lissage léger, je trouve ça moche).

        Du coup j'utilise Ubuntu pour tout sauf pour programmer; si quelqu'un connait le réglage des polices sous Ubuntu ça m'intéresse.

        Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Code auto-documente

        Posté par  . Évalué à 4.

        la question ce n'est pas "j'initialise x à 3" mais pourquoi je le fais.

        • [^] # Re: Code auto-documente

          Posté par  . Évalué à 4.

          Bha t'es on ou quoi ?

          Pourquoi tu veux expliquer ça alors qu'il suffit de "reorganiser, diviser en sous-fonctions/methodes, mieux nommer les variables". Franchement c'est tellement évident pour moi que je vois pas pourquoi je devrais expliquer pourquoi j'ai fait les choses. Suffit de lire le code… Si le lecteur à pas le niveau j'y peux rien…

          • [^] # Re: Code auto-documente

            Posté par  (site web personnel) . Évalué à 3.

            Je ne sais pas trop si tu fais de l'humour mais je vais assumer que c'est sérieux pour l'exercice, parce que je sais que beaucoup pensent comme ça.

            Le problème, c'est qu'on ne bosse pas forcément toujours sur du code bien propre et bien structuré. Et lorsque un fichier fait plus de 20.000 lignes, est un héritage de plus de 10 ans de travail, qu'il est passé entre les mains de dizaines de personnes, et que l'on doit le modifier, on aime bien parfois expliquer en commentaire pourquoi telle routine fait telle chose, pourquoi on en est arrivé à devoir passer par un mutex à cet endroit alors qu'à un autre non, etc etc.

            • [^] # Re: Code auto-documente

              Posté par  . Évalué à 4.

              Sinon pour les débutants, parce qu’à chaque fois que je vois un code de gros logiciel j’ai l’impression qu’il n’y a aucun commentaire, et j’arrive pas à comprendre les trucs les plus simples (ça viendra sans doute avec le temps, en attendant c’est très chiant).

              Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: Code auto-documente

              Posté par  . Évalué à 3.

              Je ne sais pas trop si tu fais de l'humour

              Tu as sérieusement eu un doute ?!?

          • [^] # Re: Code auto-documente

            Posté par  . Évalué à 4. Dernière modification le 24 octobre 2013 à 11:27.

            Souvent (je n'ai pas dis tout le temps), c'est surtout x qui devrait porter cette information. Si au lieu de l'appeler x, tu lui donne comme nom ce qu'il représente alors tu as déjà au moins la moitié de l'information disponible.

            Donc dans ce cas, ce qui me choque ce n'est pas la présence ou l’absence de commentaire mais le nommage de la variable. Une fois qu'elle est nommée correctement tu peut te poser la question de savoir si ce traîner un magic number dans le code est pertinent ou non, enfin si tu garde effectivement le magic number tu peut commenter (si tu ne le garde pas, tu le met dans la conf' du logiciel et tu la documente).

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: Code auto-documente

              Posté par  . Évalué à 1.

              En fait lire du code je pense que ce n'est tellement pas trivial que tous (ou presque) les moyens sont bons pour le rendre plus lisibles.

              Ce serait comme essayer de lire un texte avec des trous (lettres ou mots manquants). Le cerveau peut très bien interpoler les éléments manquants, mais ça va tout de même beaucoup plus vite si il ne manque pas de lettre ni de mots dans la phrases.

              Le pire du pire arrive quand on est obligé de faire des suppositions sur « ce qu'est sensé faire ce bout de code » et qu'invariablement on se plante, alors que quelques commentaires bien choisis eurent levé le doute en quelques secondes.

              Notons que certains langages, sans commentaires, sont complètement illisibles. Notamment le langage C. Le python est très lisible, c'est vraiment un plaisir de travailler avec.

              • [^] # Re: Code auto-documente

                Posté par  . Évalué à 3.

                Notons que certains langages, sans commentaires, sont complètement illisibles. Notamment le langage C. Le python est très lisible, c'est vraiment un plaisir de travailler avec.

                Je ne suis pas d'accord, dans les deux cas ça dépend de ce que tu en fait.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Code auto-documente

          Posté par  . Évalué à 1.

          Merci.

      • [^] # Re: Code auto-documente

        Posté par  . Évalué à 5.

        Je distingue documentation et commentaires. La documentation, c'est du texte et des specs.
        Bien souvent, quand le code n'est pas clair, c'est qu'il faut revoir les noms des variables, des fonction, l'organisation. C'est facile de cacher la m**** avec 3 lignes de commentaires, qui ne seront pas forcement plus claires que le code. Par experience, je pourrai meme dire moins : quand le code est modifie pour fixer un bug, la documentation ne l'est jamais.
        Il y a des cas, oui, ou les choses ne sont pas evidentes : un algorithme metier est l'exemple typique. Mais la plupart du code devrait se lire comme une phrase. Si on respecte les bonnes pratiques, ca pose assez peu de probleme (5 lignes max/fonction, une fonction pour une chose a faire). Le probleme, c'est que 90% du temps, on pond une phrase de commentaire pour remplacer une reflexion sur une factorisation de code, un bon nommage de methodes et de fonctions.
        J'aimai bien le code commente. Mais apres avoir applique les recommandations du bouquin, la conclusion est sans appel : le code est plus lisible, plus concis, plus clair, etc.

        Concernant les commentaires de code qui mentent, je peux donner une demi douzaine de projets actifs sur github dont les commentaires indiquent le contraire de ce que fait le code, et induisent le lecteur en erreur : au lieu d'aller voir la fonction appelee, il fait confiance au commentaire, qui n'a pas ete mis a jour apres refacto. Sur des projets publics ca arrive, alors sur des projets prives…

        Ensuite vient la question du langage/IDE utilise : Java+Eclipse, avec l'aide interractive, ca peut etre utile d'avoir des commentaires 'getAccountList retourne une liste de comptes'. Ca remplace la fraction de seconde de reflection sur la lecture de la fonction. Sur des langages faiblement type, de toute facon il faut lire la documentation et/ou code. le gain de temps est donc ridicule.

        Bon, soyons honnetes au final :
        * Celui qui va lire le code apprendra (methodes, bonnes pratiques, …) naturellement. Donc codeur plus efficace.
        * Les 5 minutes de lecture du code lui eviteront de se palucher la documentation a chaque appel, de comprendre les choses en prodonfeur. Donc debug plus rapide.
        * Avec un peu d'experience sont code sera normalise, plus clair. Donc plus facile a comprendre et debugger pour les autres.
        * Le code devrait etre teste. Un test clair qui echoue vaut plus que tout commentaire dans le code. Pour peu que le test soit correctement documente et pas trop tordu (sinon, il faut mettre des commentaires)

        Donc au final, je ne suis pas convaincu que commenter systematiquement chaque methode/variable/classe soit bon au final. Ca fait de belles courbes statistiques, mais aucune mesure n'est realis(ee|able) sur la pertinence des commentaires. Pour l'appliquer actuellement, je comprends mieux ce que je fais, je suis plus clair et je comprends plus facilement le code des autres devs. En plus ,je lis du code de personnes techniquement meilleures que moi, du coup je gagne en experience…

    • [^] # Re: Code auto-documente

      Posté par  . Évalué à 1.

      Je confirme que le livre "the clean Code" de Robert C. Martin est une petite perle. Il détaille les différents "types" de commentaires et explique pourquoi ils ne servent pas.

      Les trucs du style :

      int i=0; // indice de mon tableau d'articles

      devrait s'écrire :

      int indice_tableau_articles=0;

      Les commentaires pour mettre de côté du code que l'on n'a plus besoin "pour le moment" mais que l'on veut garder sous le coude peuvent rentrer dans le gestionnaire de version de source (git, svn…)

      Certains commentaires peuvent aussi rentrer en "commentaire des commits" à la place de l'intérieur du code.

      Bref, il y a sans doute des cas de figure où le commentaire est utile, mais beaucoup de cas où ils ne sont là que pour contourner une autre faiblesse du code.

      • [^] # Re: Code auto-documente

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 23 octobre 2013 à 14:35.

        Tu as raison d'insister sur un meilleur nommage pour éviter les commentaires mais pour le coup, le nom de variable "i" est relativement singulier, non seulement son nom est universellement connu comme étant un indice de boucle, mais aussi il arrive souvent qu'il soit mutualisé pour plusieurs boucles au sein du même bloc d'instructions, ce qui ne permet pas un nommage très spécifique.
        Bon après, on me répondra "quoi ? Deux boucles dans un même bloc d'instructions ?!" et je répondrai : "bande de nazis !" :)

        • [^] # Re: Code auto-documente

          Posté par  (site web personnel, Mastodon) . Évalué à 0.

          Je considère que seuls les débutants utilisent i, j ou k, dans le monde PHP le couple (k, v) a aussi pas mal de succès. Quand je vois ce genre de choses, je commence déjà à me plaindre, parce que je sais qu'il y aura aucun indice quand à la sémantique de la clé. Si c'est un traitement générique, key peut passer, mais dans le cas où c'est un param_name, c'est mieux de le nommer.

          Bref, pour en revenir à i, personne n'utilises plus de boucles brutes de toute façon. Totu le monde utilise les STL algos, non ? :D

          • [^] # Re: Code auto-documente

            Posté par  (site web personnel) . Évalué à 4.

            Tu as raison, plus personne ne fait de C.
            Mes excuses.

            • [^] # Re: Code auto-documente

              Posté par  (site web personnel, Mastodon) . Évalué à 1.

              En C plus qu'ailleurs, employer i comme nom de variable est un crime. Je préfère éviter toute variable d'index, et privilégie des pointeurs (on itère généralement sur une structure contiguë).

              Si je veux incrémenter un compteur, je l'appelle « counter ».

              Si je veux vraiment indiquer une position dans un tableau, j'utilise « position ».

              • [^] # Re: Code auto-documente

                Posté par  (site web personnel) . Évalué à 6.

                Voilà typiquement le genre d'extrémisme dans lequel je ne veux pas tomber.

                i est pour moi une variable de type int, qui sert à aller de 0 à n.

                Je n'ai pas envie de taper "counter" dans ce cas alors que for (i = 0; i < n; i++) me parle immédiatement (certainement un vieil héritage de mes cours de mathématique).

                Pour le reste, je n'hésite jamais à utiliser des noms à rallonge pour les variables qui ont un rôle spécifique, c'est-à-dire la plupart, et je râle quand je vois un "t" au lieu de "current_time" pour un stime_t par exemple.

                Après, le coup d'itérer sur des structures contiguës en mémoire, moi c'est clairement pas toujours le cas, je manipule beaucoup des structures qui ressemblent un peu au QList (des tableaux de pointeurs sur des objets) par exemple.

                • [^] # Re: Code auto-documente

                  Posté par  (site web personnel, Mastodon) . Évalué à -4.

                  Le problème est que i est utilisé à tord et à travers, et vu qu'il est couramment utilisé, on a souvent des problèmes de shadowing.

                  for (i = 0; i < n; i++)

                  Ceci est un problème. Qu'est-ce que représente i ? Est-ce une position ? Est-ce un indice (le PIB par exemple) ?

                  certainement un vieil héritage de mes cours de mathématique

                  Donc tu vois le nombre i dont le carré est -1 dans cette expression ?

                  je manipule beaucoup des structures qui ressemblent un peu au QList (des tableaux de pointeurs sur des objets) par exemple.

                  Tu parcours une liste chaînée en accédant à ces éléments en utilisant leur position ? Du genre :

                  QList<Troll *> trolls = dlfp.get_people(less_than<&Troll::get_note>(0));

for(int i = 0; i < trolls.size(); ++i)
    if(trolls[i]->name == "LupusMic")
        --trolls[i];

                  Dis-moi que je t'ai mal compris.

                  • [^] # Re: Code auto-documente

                    Posté par  (site web personnel) . Évalué à 3.

                    Ceci est un problème. Qu'est-ce que représente i ? Est-ce une position ? Est-ce un indice (le PIB par exemple) ?

                    Lorsque j'utilise i, c'est généralement pour référencer un élément dans une structure de données à accès "random", donc un index (d'où le "i", comme "index").
                    Mes routines sont généralement courtes, on voit plutôt immédiatement ce que signifie i.

                    C'est vraiment une question de feeling, je ne vais naturellement pas utiliser i pour référencer une position particulière dans un tableau, j'espère que tu saisis la nuance.

                    Tu parcours une liste chaînée en accédant à ces éléments en utilisant leur position ? Du genre :

                    En C++ ? non, j'utilise principalement les macros Qt (en sachant que ces macros peuvent dans certains cas dupliquer la structure de donnée, donc méfiance quand même).
                    Là je parlais de C, j'ai utilisé le QList uniquement de façon informative. En C, il m'arrive souvent de devoir faire des accès "random" à des structures de données, je sais bien qu'on est en 2013, je dois certainement être un peu has been ;)

                    • [^] # Re: Code auto-documente

                      Posté par  (site web personnel, Mastodon) . Évalué à 1.

                      Mes routines sont généralement courtes, on voit plutôt immédiatement ce que signifie i.

                      C'est-à-dire des routines d'un p'tit millier de lignes ? :o) C'est très subjectif tout ça, c'est pour ça que je préfère nommer spécifiquement une variable, histoire d'éviter au relecteur de devoir interpréter.

                      j'espère que tu saisis la nuance

                      Oui, mais c'est bien là mon problème : c'est forcément une position particulière, qui peut être la position current, ou last, etc. Bref, je n'aime pas les noms génériques.

                      Là je parlais de C, j'ai utilisé le QList uniquement de façon informative. En C, il m'arrive souvent de devoir faire des accès "random" à des structures de données, je sais bien qu'on est en 2013, je dois certainement être un peu has been ;)

                      Non, ce qui me gêne c'est un accès random dans une liste dans une boucle. La complexité de l'algo est démentielle dans l'exemple que j'ai donné, alors qu'on aurait tout intérêt à itérer la collection. Et que tu n'ai pas relevé ça me permet de relativiser ton opinion.

                      • [^] # Re: Code auto-documente

                        Posté par  (site web personnel) . Évalué à 2.

                        Non, ce qui me gêne c'est un accès random dans une liste dans une boucle. La complexité de l'algo est démentielle dans l'exemple que j'ai donné, alors qu'on aurait tout intérêt à itérer la collection. Et que tu n'ai pas relevé ça me permet de relativiser ton opinion.

                        Je me rends surtout compte que je t'ai lu trop vite dans le commentaire précédent.
                        Une QList n'est pas une liste chaînée. (pour ça, Qt propose une QLinkedList).

                • [^] # Re: Code auto-documente

                  Posté par  . Évalué à 2.

                  Après, le coup d'itérer sur des structures contiguës en mémoire, moi c'est clairement pas toujours le cas, je manipule beaucoup des structures qui ressemblent un peu au QList (des tableaux de pointeurs sur des objets) par exemple.

                  C'est donc un tableau (de pointeurs et pas d'objet). Si tu as un accès par index c'est que tu as des données séquentielles, sinon c'est que tu a une surcouche qui te cache la complexité de ton appel.

                  Si tu as une autre forme de structure le parcourt séquentiel n'a pas forcément de sens (comme sur un ensemble) et tu as des accès autrement (comme dans le cas d'une liste chaîner). Le seul cas où ça a du sens d'utiliser un indexe, c'est quand tu ne traite pas toutes ta structure (tu veux éviter de passer sur les premiers éléments, comme dans certains tris, ou si tu ne parcourt pas l'ensemble de la structure) ou quand tu veut utiliser cet index comme résultat pour un traitement ultérieur (mais dans ce cas il faut pas l'appeler i).

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: Code auto-documente

                    Posté par  (site web personnel) . Évalué à 2.

                    C'est donc un tableau (de pointeurs et pas d'objet). Si tu as un accès par index c'est que tu as des données séquentielles, sinon c'est que tu a une surcouche qui te cache la complexité de ton appel.

                    Tu as la garantie que tes pointeurs sont séquentiels oui, mais je ne vois pas où tu veux en venir, on parlait d'incrémenter un pointeur sur des données réparties sur une zone contiguë pour éviter l'index, chose impossible quand il s'agît d'un tableau de pointeurs sur des objets placés ailleurs en mémoire sans aucune garantie de séquentialité en mémoire.

        • [^] # Re: Code auto-documente

          Posté par  (site web personnel) . Évalué à 3.

          Je pense que le le choix des noms de variables dépend aussi du langage, et plus que du langage lui-même de la « culture » des développeurs qu'il y a autour et du fait que tel nom de variable va sembler évident ou pas à un lecteur potentiel. Par exemple il me semble que "x" et "xs" sont souvent utilisés dans certains langages pour désigner respectivement le premier élement d'une liste et le reste de la liste (quand tu parcours une liste par récursion), et je pense que c'est assez clair. Par contre si tu le fais en C où c'est pas habituel je pense qu'il ne vaut mieux pas être aussi concis.

  • # Quand on me refile du code non commenté

    Posté par  . Évalué à 10.

    Beurk

    (source Les joies du code)

    Commenter, c'est aussi l'occasion de glisser des petits blagues pour ceux qui passent après. Et ça, c'est bien.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 10.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # Tout le monde sait que...

    Posté par  (site web personnel) . Évalué à 3.

    …un code propre n'a pas besoin de commentaire. Un commentaire ça sert juste à expliquer ce que fait un code mal écrit.

    Je sors avant que tous les gens qui me lisent au premier degré ne me jettent des trucs à la figure. => [ -]

  • # Commentaire supprimé

    Posté par  . Évalué à 8.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # Commentaire supprimé

    Posté par  . Évalué à -10. Dernière modification le 23 octobre 2013 à 03:06.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Les commentaires et l'ordre des tâches

      Posté par  . Évalué à 1.

      J'ai répondu oui. Je commente toujours le code. Je fais plus : je commence par les commentaires. Lorsque je suis satisfait, je commence le code. [ rires ]

      C'est à ça que ressemble mes cours de programmation fonctionnelle (sur une sorte de dérivé de Lisp).
      On commence par écrire les algos sous forme de commentaires, et seulement ensuite on écrit les fonctions (le vrai code quoi).

      Franchement, c'est une bonne méthode pour s'assurer qu'on part sur quelque chose qui « devrait fonctionner ».

  • # Code Tells You How, Comments Tell You Why

    Posté par  . Évalué à 2.

    http://www.codinghorror.com/blog/2006/12/code-tells-you-how-comments-tell-you-why.html

  • # Doxygen et spécificités

    Posté par  (site web personnel) . Évalué à 3.

    Moi je code toute fonction publique au format doxygen dans son .h, du coup la plupart de mes commentaires se situent dans mes .h et non dans mes .cpp.

    En revanche, il m'arrive de commenter des parties difficiles ou des cas d'utilisation spéciaux.

    git is great because linus did it, mercurial is better because he didn't

  • # j'ai arrêté, ça marche pas.

    Posté par  (site web personnel) . Évalué à 4.

    Moi j'ai essayé de commenter mon code mais j'ai vite arrêté.

    Je ne sais pas pourquoi mais à chaque fois, le compilo ne lit pas la ligne commentée et j'ai des comportements bizarres.

    Vous, vous faites comment pour commenter un if un peu compliqué ? Vous mettez un // devant ?

    Matthieu Gautier|irc:starmad

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -10.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: j'ai arrêté, ça marche pas.

        Posté par  . Évalué à 2.

        Non il a raison. Les trailing comments sont une très mauvaise pratique. Du coup il vaut mieux les mettre devant…

        • [^] # Re: j'ai arrêté, ça marche pas.

          Posté par  (site web personnel, Mastodon) . Évalué à 1.

          Je ne serais pas aussi catégorique. En assembleur, ne pas avoir les trailing comments serait invivable. Mais on parle de code dont les lignes sont courtes et où les trailings comments ne peuvent être ignorés.

          Ensuite, pour documenter un données membre, la notation suivante est tout de même pratique:

          <?php
class state {
    public $is_alive; ///<  \param bool 
}

          • [^] # Re: j'ai arrêté, ça marche pas.

            Posté par  . Évalué à 4.

            Je ne serais pas aussi catégorique

            Moi non plus. Après si tu réponds au premier degré sur ce thread je pense que tu as raté quelque chose.

            public $is_alive; ///< \param bool

            Mon bon monsieur il suffit d'utiliser un vrai langage de programmation et pas un commently-typed…

            • [^] # Re: j'ai arrêté, ça marche pas.

              Posté par  (site web personnel, Mastodon) . Évalué à 1.

              Mon bon monsieur il suffit d'utiliser un vrai langage de programmation et pas un commently-typed…

              Au début je voulais donner un exemple avec C++, et ben comme ça, au débotté, j'ai eu bien du mal à trouver quelque chose de pertinent.

        • [^] # Re: j'ai arrêté, ça marche pas.

          Posté par  . Évalué à 1.

          Mouaih, le lien que tu pointes (et beaucoup de règles de style du même genre) tiens plus du grammar nazi ou de l'opinion subjective que de la vraie bonne pratique de programmation objective.

          Tiens d'ailleurs à deux pages de la tienne il est aussi dit qu'il ne faut jamais avoir plus de 2 "return" dans la même fonction. C'est rigolo aussi.

          • [^] # Re: j'ai arrêté, ça marche pas.

            Posté par  . Évalué à 2.

            Tiens d'ailleurs à deux pages de la tienne il est aussi dit qu'il ne faut jamais avoir plus de 2 "return" dans la même fonction. C'est rigolo aussi.

            J’arrive pas à retrouver mais dans un GOTW, il est dit que c’est stupide de vouloir absolument un seul return parce que dans la plupart des situations où on est amené à le faire, c’est légèrement plus performant (en tout cas en C++, mais ça doit être sans doute la même chose dans les autres langages) qu’un seul return (et c’est pas forcément plus lisible).

            Écrit en Bépo selon l’orthographe de 1990

            • [^] # Re: j'ai arrêté, ça marche pas.

              Posté par  . Évalué à 3.

              Oui, à l'école on m'a appris qu'il ne fallait ni utiliser des return multiples, ni des break et autres continue mais plutôt utiliser un booléen qu'on vérifie dans la condition de terminaison de la boucle.
              J'ai arrêté de respecter cette règle après avoir vu des tonnes de break dans du code libre. Et en plus, subjectivement, je trouve que ça rend le code vraiment plus lisible d'utiliser des break.

              • [^] # Re: j'ai arrêté, ça marche pas.

                Posté par  . Évalué à 2.

                D’ailleurs maintenant je n’utilise plus de do {} while(); quasiment, mais plutôt des while(true) { … break } parce qu’en général on duplique la condition du while final (par exemple, dans les exemples de base, quand on veut afficher un mot d’erreur à l’utilisateur lors d’une saisie).

                while(true) {
    demande_saisie();
    if(saisie_est_fausse) {
        afficher_mot_erreur();
    } else {
        break;
    }
}

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: j'ai arrêté, ça marche pas.

                  Posté par  . Évalué à 5. Dernière modification le 26 octobre 2013 à 22:00. 

                  demande_saisie();
while(saisie_est_fausse) {
    afficher_mot_erreur();
    demande_saisie();
}

                  En effet la demande est dupliquée, mais je trouve tout de même le code plus court (ça c'est factuel) et plus lisible¹ (on vois tout de suite que la boucle sert uniquement à valider la saisie sans avoir à parcourir l'ensemble de la boucle.

                  Par contre, je suis d'accord que ce n'est pas optimal, on a pas de boucle qui rend vraiment la sémantique en question.

                  Personnellement sans m'en faire une règle inviolable, j'évite au maximum les break et les return multiples. Ils peuvent facilement rendre un code illisible car ce sont des sauts qui ne portent pas de sémantique (contrairement à un foreach par exemple). De plus d'un point de vu maintenabilité, ils multiplient les points de sorties (du coup ajouter des traitements à la fin peu devenir plus délicat). AMHA la taille du code et la complexité cyclomatique peuvent être de bonnes métriques pour essayer de choisir (je dis pas de les suivre aveuglément juste que ça aide à choisir).

                  [1] ça dépend largement de la taille de la boucle (et c'est subjectif), mais si une boucle devient trop grande j'essaie de sortir son corps (ou une partie de son corps dans une méthode séparée)

                  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                  • [^] # Re: j'ai arrêté, ça marche pas.

                    Posté par  . Évalué à 1.

                    Pour moi la règle n°1 c’est de ne pas dupliquer de code. Dans ces cas là, je n’hésite pas à utiliser break, et je trouve ça plus lisible (mes boucles ne sont pas très longues en général). C’est un peu comme un do {} while(); amélioré je trouve.

                    Écrit en Bépo selon l’orthographe de 1990

                • [^] # Re: j'ai arrêté, ça marche pas.

                  Posté par  . Évalué à 2.

                  À la limite, je trouve que dans certaines situations comme celle-là, un goto peut être approprié.

                  (Pour peu que l’étiquette soit raisonnable et qu’il soit clair que le saut est local.)

                  demande: {
    demande_saisie();

    if (saisie_est_fausse) {
        afficher_mot_erreur();
        redo demande;
    }
}

    • [^] # Re: j'ai arrêté, ça marche pas.

      Posté par  (site web personnel) . Évalué à 2.

      En C/C++, la référence pour commenter en masse est le #if 0 … #endif. Ça permet de pallier le problème des commentaires intérieurs notamment :

      #if 0
/*
 * Ce commentaire fonctionne
 */
if (true) {
}
#endif

      git is great because linus did it, mercurial is better because he didn't

  • # il ne faut pas commenter, car au bout de plusieurs années les commentaires sont faux

    Posté par  . Évalué à 2.

    Oui, je sais, le sujet du commentaire est de la provoc.

    Mais qui n'a jamais eu à modifier un code de 10 ans dans lequel les commentaires sont trompeurs car une partie des gens qui ont modifié le code n'ont modifié que le code et pas les commentaires ?

  • # C’est honteux

    Posté par  . Évalué à 2.

    que ce sondage soit aussi peu pertinenté!

    Écrit en Bépo selon l’orthographe de 1990

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -10.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # ça me fait penser à un truc

    Posté par  . Évalué à 1.

    une petite aventure d'un ami avec un commentaire qui influait sur le code :

    https://skyduino.wordpress.com/2012/02/26/gcc-is-trolling-you-problem-its-not-a-bug-its-a-feature/

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -10.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: ça me fait penser à un truc

      Posté par  . Évalué à 2. Dernière modification le 24 octobre 2013 à 19:12.

      C'est rigolo, mais bon c'est quand même très connu, et tous les IDE qui se respectent (y compris vim) font la coloration syntaxique en conséquence.

      En plus compiler avec -Wall c'est pas hyper original non plus, voire c'est une très bonne pratique, au besoin assorti de quelques -Wno-xxx si le code a des spécificités qui rendent -Wall illisible, mais sans -Wno-comment dont je ne vois vraiment pas à quoi elle peut servir à part à rendre cette mésaventure possible.

      Tu peux essayer #\ dans un makefile aussi, ça fait pareil (et les IDE le savent aussi).

      Bref, c'est pas un commentaire qui influe sur le code, c'est une subtilité des priorités des tokens dans la syntaxe C, qui attire des ennuis au néophyte mal outillé.

      Accessoirement appeler "commentaire" un gros ascii-art utilisant des backslash en fin de ligne reste quand même un peu osé. En tout cas c'est sûr que c'est pas un commentaire à visée documentaire.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -10.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # Commentaire supprimé

    Posté par  . Évalué à -10. Dernière modification le 24 octobre 2013 à 20:29.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Moi et mes commentaires

      Posté par  . Évalué à 5.

      Merci à l'équipe de modération, c'était effectivement pénible à lire.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -10.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à -10. Dernière modification le 25 octobre 2013 à 06:07.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -10.

            Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -10. Dernière modification le 30 octobre 2013 à 08:58.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Moi et mes commentaires

              Posté par  . Évalué à 3.

              Si ça t'amuse de perdre ton temps à écrire des commentaires que personne n'a envie de lire… pas étonnant que tu te sentes seul.

              "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

              • [^] # Re: Moi et mes commentaires

                Posté par  . Évalué à 4.

                Do not feed the troll

                Écrit en Bépo selon l’orthographe de 1990

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à -10.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à -10.

                    Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à -10.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Moi et mes commentaires

                  Posté par  (site web personnel, Mastodon) . Évalué à 7.

                  Si vous êtes en train de tester les limites des modérateurs, vous allez vite les trouver. On ne va pas forcément attendre le point Godwin pour savoir si vos écrits sont répréhensibles ou pas. On a autre chose de plus sympa à faire de notre temps.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à -10.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Re: Moi et mes commentaires

                      Posté par  . Évalué à 2.

                      A l'intention des curieux, le monsieur donne un lien vers un document sous-titré Sous la responsabilité du professeur Robert Faurisson, personnage réputé antisémite, déjà condamné à plusieurs reprises en France pour « incitation à la haine raciale » et « contestation de crime contre l'humanité » (source Wikipedia).

                      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

                      • [^] # Commentaire supprimé

                        Posté par  . Évalué à -10.

                        Ce commentaire a été supprimé par l’équipe de modération.

  • # Impossible de commenter un contenu vieux de plus de 3 mois

    Posté par  . Évalué à 1.

    pourquoi faire revivre un contenu que nous ne pouvons plus commenter ? Linuxfr passe en mode télé ?

    • [^] # Re: Impossible de commenter un contenu vieux de plus de 3 mois

      Posté par  (site web personnel) . Évalué à 7.

      Tu postes un commentaire pour dire que tu ne peux pas commenter ?

    • [^] # Re: Impossible de commenter un contenu vieux de plus de 3 mois

      Posté par  . Évalué à 2.

      Les résultats de deux sondages réalisés à des périodes différentes peuvent beaucoup changer, et c’est ça qui est intéressant.

      Écrit en Bépo selon l’orthographe de 1990

      • [^] # Re: Impossible de commenter un contenu vieux de plus de 3 mois

        Posté par  . Évalué à 1.

        En fait je voulais poster sur l'autre thread, que j'avais sauté à l'époque apparemment, alors qu'il est (merci crev) encore une fois hyper instructif et intéressant. Rapport au slides sur SQLite, rien de neuf en soit, mais d'avoir un support pour exprimer l'idée qu'un bug informatique, au delà d'être une erreur d'écriture-conception est d'abord et avant tout le stigmate d'un prolème de process. Idée qui me semble hautement importante, et dont je souhaitais évidemment vous rabacher les oreilles…
        Pour ceux qui se demandent de Koi je parle : http://www.sqlite.org/talks/wroclaw-20090310.pdf

        Mais bon. Le contenu à vieilli, alors j'imagines que si l'envie m'en reprend il me faudra m'y prendre autrement, histoire de polluer utilement la base de données de linuxfr (?).

        C'est juste ça… Et oui sur le coup cela m'a semblait d'une crasse telle, que venir baver ici me semblât justifié.

        • [^] # Re: Impossible de commenter un contenu vieux de plus de 3 mois

          Posté par  (site web personnel) . Évalué à 10.

          Dans un monde idéal, on laisserait tout le monde aller poster partout, et on verrait que cela serait bon.

          Mais en vrai y a des spammeurs, des monomaniaques égocentriques, des hallucinés, des prosélytes politiques/religieux/etc., bref des gens qui profiteront du fait que quasi personne d'humain n'ira lire les vieux contenus (donc pas de système d'auto-modération effectif) mais les moteurs de recherche si. Sans parler des innocents qui attendront désespérément une réponse à leur question formulée sur l'antédéluvienne dépêche de sortie de WindowMaker 0.7.2. Bref ça pose des problèmes.

          Autre effet : au bout de 3 mois de parution d'un contenu, on est plus tranquilles vis-à-vis d'une hypothétique diffamation en raison de la prescription. Et au bout de 6 mois, on est donc plus tranquilles sur les commentaires dudit contenu (du genre de ceux qui évoquent la non-validation HTML de sites). Ça évite le risque sur 89000 contenus et 1,5 million de commentaires.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à -10.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -10.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à -10.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Commentaire supprimé

          Posté par  . Évalué à -10. Dernière modification le 05 janvier 2014 à 20:51.

          Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -10. Dernière modification le 05 janvier 2014 à 20:49.

            Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -10.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à -10.

              Ce commentaire a été supprimé par l’équipe de modération.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à -10.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à -10.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à -10. Dernière modification le 03 novembre 2013 à 19:23.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Impossible de commenter un contenu vieux de plus de 3 mois

                  Posté par  (site web personnel) . Évalué à 7.

                  Un fil de 13 commentaires, donc 9 à toi tout seul. Fil qui a nécessité 3 interventions de modérateurs. Tout ça pour poster des commentaires hors-sujets et pour utiliser n'importe comment les commentaires comme si c'était un wiki ou ta page perso. Plus loin un autre fil avec encore 12 de tes commentaires et un maximum d'auto-réponse. Et c'est loin d'être la première fois.

                  Clairement ton comportement est en dehors des règles du site : utilisation détournée, commentaires problématiques. Ceci est le dernier avertissement avant fermeture de ton compte.

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à -10.

                    Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Impossible de commenter un contenu vieux de plus de 3 mois

        Posté par  . Évalué à 5.

        ON S'EN FOUT !

        "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.