Sondage Les commentaires et vous ?

Posté par (page perso) . Licence CC by-sa
Tags : aucun
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 sondés 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.

      • [^] # Re: Faut voir... C'est tout vu

        Posté par (page perso) . Évalué à 4. Dernière modification le 22/10/13 à 22:57.

        je ne commente que les parties dites "tricky".

        C'est même comme ça que je repère les parties en question dans mon code. Des trucs du genre

        canvas = FigureCanvas(f) # a gtk.DrawingArea

        Parce que là clairement, il est impossible de savoir juste en lisant le code de quelle nature exacte est l'objet FigureCanvas() donc paf, commentaire.

        L'idée étant de commenter seulement et exclusivement dans les cas où l'info n'est pas contenue dans le code lui-même.

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

        Posté par (page perso) . Évalué à 6.

        Sur une note non sans rapport (hum) j'ai tendance à raconter ma vie dans les messages de commit. Pourquoi telle implémentation, tel choix, ce qui va peut-être bouger, etc.

  • # L'art de programmer

    Posté par (page perso) . Évalué à 10.

    Programmer est un art…

    Titre de l'image

    (Geek&Poke, CC-BY 3.0)

    • [^] # Re: L'art de programmer

      Posté par (page perso) . Évalué à 10. Dernière modification le 22/10/13 à 13:08.

      Oui, Van Gogh a commenté son travail. Dans de nombreuses lettres, notamment à son frère Theo, il détaille ses œuvres, explique des choix techniques, effectue des critiques comparées, etc.

  • # Oh, le joli commentaire !

    Posté par (page perso) . É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 (page perso) . É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)

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

        Posté par (page perso) . Évalué à 10.

        Typiquement c'est le genre de commentaire qui ne peut pas être traduit en code

        Ahem

        # Initialize the reader
        initialize = ->
          p.reader = reader
        • [^] # Re: Oh, le joli commentaire !

          Posté par (page perso) . É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. 
          • [^] # Re: Oh, le joli commentaire !

            Posté par (page perso) . Évalué à 2.

            Je voudrais surtout pas avoir l'air de pinailler, mais celui-ci dit en gros "si tu sais pas ce que tu fais, touche à rien, et sinon, lis les commentaires (duh)" ce qui tombe un peu sous le sens, quoi. Et j'ajouterai perso "ne te contente pas des commentaires, lis le code aussi, dumbass" toutes choses redondantes, bien mieux exprimées à mon sens par l'absence de commentaires autres que ceux strictement nécessaires.

            Le code ne ment pas (enfin en principe) il est là, il passe dans le parser et s’exécute. Le rapport fonction-information est réel et tangible.
            Les commentaires, eux, sont complètement décorrelés de l'exécution (à part le fait qu'ils sont dans le même fichier) et peuvent raconter n'importe quoi, et si je dis ça c'est parce que ça m'est arrivé, et plus souvent que je le souhaiterai.

            Le coup du "ce fichier-là pas toucher, pour configurer / bidouiller c'est tel autre fichier" c'est
            1 - Idéalement perceptible tout de suite en raison de la forme du projet, des noms des objets (par exemple deux fichiers execute.ext et configure.ext) etc. et
            2 - du ressort de la doc.

            • [^] # 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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 5. Dernière modification le 22/10/13 à 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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 1.

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

            • [^] # Re: Méthode moyenageuse

              Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 1. Dernière modification le 23/10/13 à 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 (page perso) . É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/10/13 à 00:30.

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

            • [^] # Re: Méthode moyenageuse

              Posté par (page perso) . É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 (page perso) . É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/10/13 à 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 (page perso) . Évalué à 2.

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

      l'azerty est ce que subversion est aux SCMs

      • [^] # Re: 42

        Posté par (page perso) . É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)

            • [^] # Re: 42

              Posté par . Évalué à -10.

              Ton commentaire est indécidable pour un débutant. Entre autres questions soulevées : pourquoi Pat(rick) se retrouve en plusieurs occurrences dans la file (d'attente, pour aller bouffer je suppose) ? N'y a-t-il pas une sorte de complot ?

              Allo Pat ? Non mé alloooo, quoi ?

              Pat pour Pattern (un motif) ? Haaaa, ok ok ok !

              Fait pour valoir ce que de droit (pédagogie rigolote pour débutant)

        • [^] # 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 (page perso) . Évalué à 3. Dernière modification le 22/10/13 à 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 (page perso) . É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 (page perso) . É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/10/13 à 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 (page perso) . Évalué à 2. Dernière modification le 23/10/13 à 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 (page perso) . É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 (page perso) . Évalué à 4.

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

            • [^] # Re: Code auto-documente

              Posté par (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . Évalué à 2.

                      chose impossible quand il s'agît d'un tableau de pointeurs

                      Mais le truc serait d'itérer le pointeur de pointeur pour parcourir la collection.

        • [^] # Re: Code auto-documente

          Posté par (page perso) . É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.

  • # Tout le monde sait que...

    Posté par (page perso) . É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.

  • # Les commentaires et l'ordre des tâches

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

    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 ]

    Pour certains gros projets comme le TALNC (traitement automatisé du langage naturel contrôlé), certaines phases de codage peuvent même se révéler inutiles, si les commentaires sont de bonne facture1 :)

    1 mais à un moment, il faut bien coder un noyau de TALNC générique dans un langage disposant déjà d'un compilateur pour amorcer le processus.

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

      Posté par (page perso) . É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.

  • # Doxygen et spécificités

    Posté par (page perso) . É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.

    l'azerty est ce que subversion est aux SCMs

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

    Posté par (page perso) . É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

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

      Posté par . Évalué à -10.

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

      Devant ? Je dirais derrière, sinon c'est normal que le compilo ne lise pas la ligne.

          if (un_peu_compliquai) // ou pas
            {
              faisCeci();
              faisCela();
              faisBliPas();
              faisMoiRire();
            }

      J'ai bon ?

      Ok, je ----> [ ]

      • [^] # 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 (page perso) . É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 (page perso) . É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 (page perso) . É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 (page perso) . É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/10/13 à 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 (page perso) . É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 (page perso) . É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
      

      l'azerty est ce que subversion est aux SCMs

  • # 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 (page perso) . Évalué à 2.

    que ce sondage soit aussi peu pertinenté!

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

    • [^] # Re: C’est honteux

      Posté par . Évalué à -10.

      Oui, la prochaine fois je m'abstiendrai de commenter aussi tôt (dans le cycle de vie du sondage).

      Ainsi, la note pourra monter librement [:soupir]

  • # ç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/

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

      Posté par . Évalué à -10.

      Ouch !

      La situation a évolué, depuis lors ? GCC a été modifié en conséquence ?

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

        Posté par . Évalué à -10.

        (je veux dire, on prends au moins un warning, même sans le -wall ?)

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

          Posté par . Évalué à -10.

          Putain, j'ai fait l'con, j'ai pris l'mur. Le wall m'a tuer. "prend" prend pas d's à la 3e pers. du sing. Chiotte, les mecs, merde, grumpf ! Bombe nucléaire Rael is what the fuck ? Navré pour le surplus de travail aux salariés de la NSA, j'aide à la constitution du PIB des United (lol) States of America, voilà. Au fait le laser de puissance c'est chaud, quand même. Vaut mieux pas rester dans l'axe.

          Si ça compile pas sans warning cette fois, c'est normal, faut ajuster quelques paramètres.

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

      Posté par . Évalué à 2. Dernière modification le 24/10/13 à 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.

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

        Posté par . Évalué à -10.

        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.

        Ce peut être un commentaire à visée documentaire pour un public bien spécifique.
        Ce gros ascii-art pourrait très bien présenter un message stéganographique.

        Tels des "terma" [1] numériques, des messages secrets destinés à de futurs lecteurs avisés, à des échelles de temps variées.

        [1] lien wikipédia anglais. Pour faire court : un "terma" est un trésor caché du bouddhisme tibétain ou de la religion bön.

  • # Commentaire supprimé

    Posté par . Évalué à -10. Dernière modification le 24/10/13 à 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.

      • [^] # Re: Moi et mes commentaires

        Posté par . Évalué à -10.

        hmmm… La pression intra-communautaire est encore efficace.

        Pour moi comme pour nombre de mes compatriotes juifs et non juifs, il faut comprendre que c'est la patrie ou la mort.

        • [^] # Re: Moi et mes commentaires

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

          Je vais développer par respect pour l'Esprit.

          Cela constituera une vaste part de mon témoignage spirituel.

          J'assume le projet d'écrire dignement (sincèrement et avec un esprit de compassion), vastement (pour que se déploie la puissance de l'Esprit), les éléments modélisés de mon être spirituel. J'assume le principe d'y aller par étape, au fil des commentaires.

          Cela implique un choix d'écriture, dans la forme du commentaire :

          • des phrases plutôt courtes ;
          • la recherche d'une expression sans ambiguïté ;
          • donc une propension à la complétude (ce qui aide à lever l'ambiguïté sur les propos subtils) ;
          • un énoncé cohérent.

          Voici :

          La patrie, au sens subtil, est un axe.
          C'est un axe intérieur.
          Il se déploie à l'extérieur.
          Il n'implique pas la fixation sur des schémas, lorsqu'ils se révèlent erronés.
          Et cela y compris dans la dimension politique du choix de découpage géographique d'une nation.
          Une nation est comme une vaste cellule, au sens biologique.
          Elle garantit la préservation en limitant la contamination d'éléments indésirés (des influences, des objets nuisibles (comme les ordinateurs malveillants)).
          Une nation est bonne pour ses nationaux en cultivant l'esprit de partage, d'équanimité, d'équité.
          Elle est bonne pour ses extra-nationaux en cultivant des relations de respect, de recherche de bénéfice mutuel à toutes les échelles.

          La patrie ou la mort, vu ainsi, c'est l'attitude du Christ ou la mort.
          Je dis cela en tant que non chrétien.

          Incarner le Christ, c'est accueillir l'essence juive, qui est l'essence humaine.
          L'essence humaine, sur le plan de la conscience, est l'union de la clarté et de la vacuité.
          Dans un esprit vide (dans un état de vacuité) se manifeste clairement la perception.
          La perception laisse une trace dans l'esprit.
          La trace peut être cultivée, c'est l'outil intellectuel en action.
          La trace peut cesser, c'est le retour à la vacuité.
          Un esprit réellement vide est clair : nulle trace résiduelle d'une pensée ne gêne la juste perception.
          Il y a alors une parfaite réceptivité pour une perception non erronée, non contaminée.
          Incarner le Christ, c'est se situer au-delà de toute religion au sens commun. C'est être religieux.
          Le religieux relie.
          Sa parole est féconde.
          C'est n'est pas le fruit d'un choix, c'est l'expression naturelle de notre essence qui est amour.
          Que cela soit le fruit d'un choix et c'est la porte ouverte à toutes les influences.
          Dans l'union clarté-vacuité, tout apparaît comme étant des fruits, y compris les ananas.

          Notre monde a besoin d'autonomisation spirituelle des êtres.
          L'autonomie vient avec la contemplation.
          Elle implique l'action créatrice.
          La création se nourrit des échanges.
          Dans la contemplation, l'action créatrice se déploie à partir de la conscience en résonance avec le cosmos, l'environnement.

          Dans la matrice, 42.
          42 peut être vu comme l'essence de la matrice.
          C'est un nombre magique, en quelque sorte.
          Il témoigne à lui seul de la puissance du rayonnement conscientiel.
          En vérité, je vous le dis, tout peut être ramené à 42.
          Lorsque l'unité principielle de 42 se manifeste sous la forme d'autres valeurs numériques, poussées par des consciences en action, la matrice vit.
          En contemplant la matrice, on peut sentir ses vibrations, suivre son évolution et participer.

          Vive la matrice, vivent les ananas, vive l'Esprit.

          Signé : un chaud partisan de la démocratie authentique avec tirage au sort, un chaud partisan de la vérité, un non athée, un non agnostique, un non chrétien, un non juif, un non musulman, et même depuis quelques années, un non bouddhiste.

          • [^] # Re: Moi et mes commentaires

            Posté par . Évalué à -10.

            Depuis quelques années, j'ai appris à vivre dans la solitude de la contemplation.
            Je contemple le désastre qu'est notre monde et les solutions pour sa guérison.
            Alors je prends soin de moi : bon anniversaire, Paul (moi c'est Paul), 42 ans aujourd'hui.

            L'état intérieur que j'ai décrit dans le commentaire parent est assimilable à un coup d'état permanent.
            Cela vu à l'échelle de l'auto-libération des pensées, dans une succession de naissance, épanouissement et cessation pour chaque pensée.
            L'auto-libération des pensées est le processus naturel de l'esprit non névrosé.
            C'est une libération naturelle, une cessation naturelle, par soi-même (sa propre nature).
            Chacun peut l'expérimenter.
            Comme les vagues à la surface de l'océan, il est naturel que des pensées apparaissent dans l'esprit.
            De la même façon, il est naturel qu'elles disparaissent.
            L'absence de fixation névrotique est une mesure de la libération d'un être.
            Le coup d'état intérieur d'un être qui se libère est un processus répétitif, à l'échelle de chaque pensée.

            L'état intérieur que j'ai décrit dans le commentaire parent est assimilable à une absence de tout coup d'état.
            Cela vu à l'échelle du continuum de conscience qui déploie de façon renouvelée toutes ses vertus.
            La conscience qui se manifeste dans le silence intérieur est vaste et intégratrice.

            Intègre est l'être qui exprime l'amour et l'apprécie.
            Non intègre est celui qui n'accueille pas avec bienveillance la reconnaissance de ses faiblesses conscientisées, lorsqu'il n'exprime pas l'amour.
            Fou et non intègre est celui qui refuse de regarder ses faiblesses.

            Le gouvernement est fou et non intègre.
            Ainsi, il cessera bientôt d'être dans sa forme actuelle.
            Telle une pensée finissante, il laissera place à un nouveau monde.
            Un monde fait de nouvelles divisions, de nouvelles conquêtes.
            Un nouvel ordre mondial citoyen.
            Avec des citoyens en capacité d'être avisés, tendant vers l'intégrité, connectés à la mémoire du monde, liés par la compréhension de la fécondité de The Node dans un monde numérique vivifié par l'Esprit.

          • [^] # Re: Moi et mes commentaires

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

            Incarner le Christ, c'est se situer au-delà de toute religion au sens commun. C'est être religieux.
            Le religieux relie.
            Sa parole est féconde.
            C'est n'est pas le fruit d'un choix, c'est l'expression naturelle de notre essence qui est amour.

            Je vais expliciter cette dernière assertion (coquille au 1er mot : c'est le mot "Ce" qui convient).

            Le choix naît d'une évaluation (consciente) entre des alternatives. Chaque expérience de vie peut être l'occasion d'un choix. Qui choisit ? La question renvoie à :

            • d'un côté notre nature fondamentale : la compassion, l'amour, émanant dans un esprit clair (discernement) et vide (réceptivité) ;
            • de l'autre l'esprit étriqué, sous l'influence d'émotions perturbatrices, dans l'indifférence, ou dans la torpeur.

            Une attitude religieuse au sens profond (de relier, dans la compassion) n'est pas le fruit du choix d'un esprit étriqué mais d'un esprit ouvert, réceptif et clair. Dans un esprit ouvert, voici comment se produit un choix :

            • soit naturellement, sans que d'interrogation intellectuelle ait lieu
            • soit comme le fruit d'une interrogation / acquisition d'information / réflexion éventuelle / confrontation d'idée

            Dans les deux cas, un tel esprit ouvert n'est pas le lieu d'un frottement psychologique. C'est cette caractéristique qui est soulignée par l'expression "ce n'est pas le fruit d'un choix". Il peut y avoir choix, mais il importe de reconnaître l'état de l'esprit qui choisit. Un esprit véritablement ouvert est empli de compassion et ses choix sont guidés par le bien commun.

            Au moment où un frottement psychologique apparaît, c'est le reflet d'un désordre psycho-affectif né de traumatismes passés réactivés dans l'expérience (de façon consciente ou non), ou de traumatismes vécus au présent avec une cause extérieure active et dans le contexte d'un esprit non pleinement enraciné (établi) dans l'état de clarté-vacuité, l'état de compassion (d'amour) authentique.

            Finalement, ma formulation sujette à mauvaise interprétation était faible. Voici une formulation plus juste :

            « Ce n'est pas le fruit du choix d'un esprit étriqué, sous l'influence d'émotions perturbatrices, dans l'indifférence, ou dans la torpeur. C'est l'expression naturelle de notre essence qui est amour. »

            Le présent commentaire constitue un patch auto-documenté :o)

            • [^] # Re: Moi et mes commentaires

              Posté par (page perso) . É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 (page perso) . Évalué à 4.

                Do not feed the troll

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

              • [^] # Re: Moi et mes commentaires

                Posté par . Évalué à -10.

                C'est bien Zeroheure, tu as compris qu'il est naturel et sain de décider unilatéralement pour tous des sujets de réflexion. Tu es sympathisant de la "Ligue de Défense Juive" (quelle usurpation, ce nom !) peut-être ?

                • [^] # Re: Moi et mes commentaires

                  Posté par (page perso) . É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.

                  • [^] # Re: Moi et mes commentaires

                    Posté par . Évalué à -10.

                    Non, je ne suis pas en train de tester les limites.

                    Je ne vois pas ce qu'il y a d'illégal et de malsain à prendre en référence le groupement que j'ai cité (que je distingue largement de la communauté juive, si c'est ce qui vous gêne, il y a même des juifs qui sont victimes de la LDJ, par exemple Jacob Cohen, à deux reprises) comme exemple de prétendants à la censure, en l'occurrence par l'imposition de la peur et l'exercice d'une forme de terrorisme avéré et documenté. Certes, c'est une référence disproportionnée au regard du commentaire de ZeroHeure. Si l'usage d'une référence excessive pour marquer l'orientation de façon caricaturale est désormais interdit sur Linuxfr, il faudra l'expliquer à tous les contributeurs de façon très… pédagogique. Si le sujet du problème que ça soulève pour vous est un possible antisémitisme, je vous invite à consulter la liste des faits présentés dans la dépêche suivante, qui concernent des agissements criminels de membres de la LDJ (et du "Betar"), et nullement la communauté juive dans son ensemble, loin de là : http://egaliteetreconciliation.fr/Milices-juives-en-France-a-quand-la-dissolution-20147.html

                    • [^] # Re: Moi et mes commentaires

                      Posté par (page perso) . É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

                      • [^] # Re: Moi et mes commentaires

                        Posté par . Évalué à -10.

                        Je comprends que tu puisses être réticent à l'idée de lire un document de Robert Faurisson. Tu es probablement imbibé de présupposés à son égard. Personnellement, en tant qu'humain digne et responsable, je lui rends hommage. Observe qu'il y a deux documents dans cette page, c'est précisé dans le chapeau de l'article. Le deuxième est intitulé :

                        Liste des agressions de la Ligue de défense juive pour le cas où Manuel Valls et Christiane Taubira ne l’auraient pas

                        CAPJPO-EuroPalestine, 6 novembre 2012

                        Aperçu des agressions commises depuis 2000 par la Ligue de défense juive (LDJ) et portées à notre connaissance :

  • # 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 (page perso) . É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 (page perso) . É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 (page perso) . É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.

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

      Posté par . Évalué à -10.

      Impossible de commenter un contenu vieux de plus de 3 mois

      Je viens de me faire piéger ailleurs…

      En écho à ce commentaire, j'ajoute ici ceci [1] : on pourra considérer le cas d'une malveillance ne nécessitant pas de déchiffrer les signatures du Novena en réception côté FPGA principal, pour retrouver ce qui ne vient pas du code s'exécutant légitimement sur le Novena. Le principe est d'établir une malveillance concertée sur toute la chaine (Novena -> FPGA de contrôle -> FPGA principal) passant par des circuits non documentés malveillants enrobant chacun des circuits intégrés. Il conviendra de réfléchir aux implications. Jusqu'à quel raffinement fonctionnel pourrait aboutir une telle malveillance dans le contexte d'un FPGA principal reconfiguré dynamiquement ?

      Voici un schéma rapide figurant l'enrobage malveillant :

                                  ____[ordinateur sécurisé à base de FPGA]____
                                 [                                            ]
           ______________        [   ______________         _______________   ]
          [ couche       ]       [  [ couche       ]       [ couche        ]  ]
          [  ________    ]       [  [  __________  ]       [  ___________  ]  ]
          [ [ CPU    ]   ]       [  [ [ FPGA     ] ]       [ [ FPGA      ] ]  ]
          [ [        ]   ] (bus) [  [ [          ] ]       [ [           ] ]  ]
          [ [ NOVENA ]   ]----------[ [ Contrôle ] ]-------[ [ Principal ] ]  ]
          [ [________]   ]       [  [ [__________] ]       [ [___________] ]  ]
          [              ]       [  [              ]       [               ]  ]
          [ malveillante ]       [  [ malveillante ]       [ malveillante  ]  ]
          [______________]       [  [______________]       [_______________]  ]
                                 [                                            ]
                                 [____________________________________________]
      

      [1] je viens de chercher à le faire sur la page concernée mais j'ai dépassé de quelques heures la date limite pour ajouter un nouveau commentaire à cette dépêche désormais vieille de plus de 3 mois. J'aurai probablement l'occasion de référencer le présent commentaire plus tard, accompagné d'une réflexion.

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

        Posté par . Évalué à -10.

        J'en profite pour pour référencer l'option résistance aux EMP (Electro Magnetic Pulse) qui pourra intéresser dans le cadre d'un PC sécurisé par l'usage de FPGA. Note : on conçoit que le module d'alimentation doit être fermement arrimé au PC sécurisé pour un bon alignement des lasers.

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

        Posté par . Évalué à -10.

        Je décris rapidement un phénomène possible qui se comprend bien avec le simple schéma du commentaire parent.

        Par commodité, je note Cmal l'expression "couche malveillante".

        La Cmal du CPU Novena peut rajouter — au flux signé produit légitimement par le CPU Novena — un flux intercalé, spécifiquement reconnaissable (par sa signature propre). Le Cmal du FPGA de contrôle soustrait le flux malveillant avant de confier le flux épuré au FPGA de contrôle (qui fait son boulot sans voir l'entourloupe) et recolle le flux malveillant en sortie. Enfin, le Cmal du FPGA principal intercepte le flux malveillant, en fait ce qu'il veut, et présente uniquement le flux authentifié et légitime au FPGA principal.

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

          Posté par . Évalué à -10. Dernière modification le 05/01/14 à 20:51.

          Une telle malveillance peut s'observer avec un analyseur logique (observation des signaux qui transitent sur le bus) au moment où elle a lieu. L'opération est lourde :

          • elle nécessite d'être équipé d'un analyseur logique, des compétences pour le manipuler, et de temps ;
          • elle implique une parfaite maîtrise de ce qui doit légitimement transiter sur le bus ;
          • la mesure sur une période de temps limitée peut ne rien révéler, alors que la malveillance peut être activable à distance.

          Par ailleurs, je considère ici le bus de données, implicitement (c'est ce qui semble logique). Or un bus comporte typiquement des lignes d'adresses, de données, de contrôle… (cf les spécification du PCI, par ex.). Si la malveillance est programmée pour, de façon cohérente entre tous les circuits en série, la couche malveillante de chacun des circuits peut permettre de faire transiter de l'information par d'autres lignes que les lignes de données.

          Le fonctionnement d'un bus est le suivant, selon l'usage courant, documenté : la valeur d'une adresse est affichée sur les lignes d'adresse (niveau haut et bas, pour 1 et 0), et dans un délai normalisé les données sont affichées sur les lignes de données. C'est au périphérique qui écoute sur le bus de considérer que les données lui sont destinées, car l'adresse affichée est dans la plage d'adresse qui lui a été allouée.

          Prenons le cas d'une malveillance qui opérerait un échange d'information par le bus d'adresse uniquement. Dans la mesure ou le périphérique a une plage d'adresse qui lui est affectée, c'est à dire plus qu'une adresse unique, il est possible d'imaginer passer l'information en jouant sur l'adresse (de façon binaire si 2 adresses sont disponibles mais avec des mots de plusieurs bits si la plage est plus grande…), ce que seul le périphérique concerné verra (considérera). Si aucune donnée n'est affichée sur les lignes de données, on ne verra rien sur celles-ci alors que l'information illégitime transite via les lignes d'adresse.

          On comprend qu'il n'est probablement pas sain (du point de vue du concepteur de la malveillance) d'opérer de la sorte avec les lignes de contrôle et d'autres, pour ne pas perturber l'ensemble des périphériques susceptibles d'écouter sur le bus.

          Ainsi, il est possible de réaliser une malveillance permettant :

          • l'allocation d'une plage d'adresse au périphérique ;
          • le test de la présence de la couche malveillante du côté périphérique, via le bus d'adresse ;
          • le déclenchement à volonté d'un échange malveillant via le seul bus d'adresse.

          Note : je dois être inspiré par l'attitude absolument exécrable des penseurs et exécutants du nouvel ordre mondial.

          NdM: l'équipe de modération a modifié ce message pour en retirer un échange privé entre deux personnes.

          • [^] # Commentaire supprimé

            Posté par . Évalué à -10. Dernière modification le 05/01/14 à 20:49.

            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é à -10.

            Je précise que le déclenchement du mode malveillant "transmission de données via le bus d'adresses" peut être opéré ainsi : une trame d'adresses spécifiques (dans la plage d'adresse du périphérique) est affichée sur le bus.

            Dans le principe, deux adresses peuvent suffire, si tant est qu'il est compréhensible pour le périphérique malveillant qu'il s'agit d'un ordre de commutation, puisque rien n'apparaît sur le bus de données

            Ma réflexion vaut pour le sens hôte -> périphérique. Pour qu'une telle malveillance soit possible dans l'autre sens, il faut que l'hôte malveillant soit joignable sur plusieurs adresses.

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

              Posté par . Évalué à -10.

              Dans le principe, deux adresses peuvent suffire, si tant est qu'il est compréhensible pour le périphérique malveillant qu'il s'agit d'un ordre de commutation, puisque rien n'apparaît sur le bus de données

              Raté. "rien n'apparaît sur le bus de données" ne veut rien dire. Si toutes les lignes de données sont à l'état bas, c'est 0 partout, point.

              De mémoire et typiquement, l'adresse est présentée sur les lignes d'adresse, les données sur les lignes de données, puis une ligne de contrôle vient préciser qu'il est temps de lire ce qui vient d'être écrit.

              Bon, l'idée est de commander la commutation de la fonction des lignes d'adresses (pour passer des données) du point de vue des couches Cmal des deux circuits en regard.

              On conçoit qu'une succession d'adresses spécifiques combinée à une succession de données spécifiques aurait peu de chance d'être rencontrée légitimement. Ce pourrait être un signal déclencheur. Cependant le risque de collision avec une configuration légitime n'étant pas nul, la piste est risquée.

              Ainsi, l'idée de base est de jouer avec les signaux sur les lignes d'adresse à des fréquences (sur des timings) non documentées. Telle trame déclenche le mode de communication malveillant, puis les données illégitimes.

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

            Posté par . Évalué à -10.

            J'ai traité de l'idée d'enchaîner des adresses les unes après les autres, pour coder de l'information, sans présenter de données sur les lignes dédiées.

            Pour soustraire l'information à la vue d'un opérateur compétent mettant en oeuvre un analyseur logique (au moment opportun) — typiquement un ingénieur en train de réaliser un prototype de circuit — on peut imaginer que l'information soit encodée à des échelles de temps plus fines que l'échelle de temps usuelle, documentée.

            Si la fréquence officielle de commutation des transistors est telle à une époque donnée, on peut imaginer que des technologies plus avancées existent et soient mises en oeuvre pour couvrir le besoin d'encoder l'information dans des "micro-coupures" des adresses présentées sur les lignes d'adresses. J'entends par micro-coupure le phénomène du morse avec un phare, pour faire simple, ici comme une remise a zéro du 1 affiché légitimement sur telle ligne, le temps d'une femto-seconde ou un ordre de grandeur encore en-dessous.

            Ce jeu du chat et de la souris est sans fin. Il reprendra peut-être même de la vigueur à l'occasion de mes modestes publications sur le sujet.

            Ce dont nous avons besoin, c'est de confiance dans le matériel, donc de fabrication relocalisée à l'échelle d'une entité politique de confiance (typiquement la nation), donc de confiance dans la nation, donc de démocratie authentique : contrôle citoyen sur la constitution, définition de l'assemblée constituante par tirage au sort pour éliminer les risques d'influence d'un groupe malveillant, etc. Cf ce commentaire pour comprendre l'influence très négative du principe même des partis politiques (dans le contexte de l'élection) dans la perpétuation des divisions et des manipulations.

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

              Posté par . Évalué à -10.

              Au potentiel d'encodage malveillant de l'information à une échelle de temps très petite, on pourra opposer le principe d'un filtre passe-bas (qui ne laisse passer les fréquences qu'en-dessous d'un seuil défini) en série sur le bus, avant même le FPGA de contrôle.

              Ce principe est probablement difficile à mettre en oeuvre correctement.

              Pour rappel, un filtre passe-bas coupe les fréquences supérieures au seuil dit fréquence de coupure (Fc).

              Dans l'hypothèse d'un filtre analogique, il faut savoir qu'il ne coupe pas abruptement : autour de Fc, il y a atténuation puis coupure (la pente de la courbe {gain / fréquence} est plus ou moins raide selon l'architecture du filtre). Est-il possible d'obtenir un filtre analogique (non malveillant…) ayant une fréquence Fc convenable ? Je me pose la question sans disposer de la réponse pour l'instant. L'ordre de grandeur de la fréquence d'un bus moderne est de quelques centaines de MHz voire de l'ordre du GHz. Si on établit Fc légèrement au dessus de la fréquence maximale (Fmax) du bus, l'atténuation sera-t-elle suffisamment importante pour empêcher la transmission d'un signal illégitime de fréquence légèrement supérieure à Fmax ? Si le bus est commutable à différentes fréquences, que la fréquence nominale programmée est inférieure à Fmax (donc à Fc), on peut imaginer que par malveillance, des informations soient transmises à des fréquences intermédiaires entre la fréquence nominale et Fmax (dans la mesure où ces variations des niveaux logiques sur les lignes concernées ne viennent pas perturber les circuits, mais on les suppose conçus pour s'en accommoder). A ces fréquences, un analyseur logique enregistrera les artéfacts liés à la malveillance, s'il est utilisé au moment où ces derniers s'expriment.

              Dans l'hypothèse d'un filtre numérique, il doit travailler à une fréquence bien supérieure à la fréquence maximale du bus, pour échantillonner le signal et opérer toutes les étapes d'un algorithme de type passe-bas.

              Dans les deux cas, analogique ou numérique, la maitrise de la fabrication reste un atout pour établir la confiance dans la conformité du circuit de filtrage à ses spécifications. Par exemple, en supposant un filtrage numérique par un FPGA assez rapide pour échantillonner (disons à la fréquence Fmax * 2) et filtrer les signaux du bus, la question d'une possible couche malveillante se pose. Elle aurait pour rôle de dupliquer le signal d'entrée en sortie, en laissant s'opérer les étapes légitimes de l'échantillonnage et du filtrage au sein des circuits documentés, mais en bloquant la sortie des signaux légitimes. Comme on l'a vu pour le "FPGA de contrôle" malveillant transmettant des signaux illégitimes à l'insu du processus légitime de filtrage des paquets numériquement signés, un FPGA utilisé pour échantillonner / filtrer en passe-bas pourrait également se comporter comme un réplicateur fidèle des signaux qu'il reçoit. Si l'encodage est à une échelle de temps inaccessible à l'analyseur logique commun, personne ne le verra. Si le filtrage est réalisé par un circuit analogique, on peut également imaginer que son comportement soit malveillant, c'est à dire qu'il semble couper le signal au-dessus de Fc mais laisse passer des fréquences bien plus élevées, non visible à l'oscilloscope commun.

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

                Posté par . Évalué à -10. Dernière modification le 03/11/13 à 19:23.

                Voici un mode opératoire qui me semble valide dans le contexte de la malveillance décrite ci-avant.

                Soit un circuit imprimé aux spécifications libres comme la carte Novena, embarquant un CPU avec sa couche malveillante non documentée, ainsi qu'un circuit (malveillant) éventuel dédié au contrôle du bus (malveillances non désirées par le concepteur de la carte, mais insérées par le(s) fondeur(s) des composants, de façon concertée s'il y en plus d'un). Supposons l'existence d'une importante puissance de calcul déportée pouvant communiquer avec le Novena via le réseau.

                Sur commande, à distance, se déclenche le processus de malveillance, par l'envoi d'une trame dédiée, interceptée par la couche malveillante du Novena observant tout ce qui arrive. La trame dédiée est signée numériquement. Elle peut être distinguée du reste du flux (pour éviter une confusion avec le flux légitime en réception) par l'injection d'un accusé/réception spécifique par la couche malveillante et l'attente d'une confirmation.

                Désormais, la Cmal du Novena s'active.
                Progressivement, il va s'agir de pénétrer l'architecture de la carte d'extension à base de FPGA, et pragmatiquement de passer d'un FPGA à l'autre, pour atteindre le FPGA principal. On pourrait parler d'une propagation de l'intrusion.

                La Cmal du Novena tente d'établir une communication illégitime, par exemple via des artéfacts sur les lignes d'adresse, avec la Cmal du premier circuit en série sur le bus. Supposons que ce premier FPGA soit dédié au filtrage passe-bas des différentes lignes du bus, comme décrit plus haut (la question est de la même nature avec le FPGA "de contrôle", tel que je l'ai défini en amont). Sa couche malveillante intercepte les artéfacts sur les lignes d'adresse, une communication s'établit. L'objectif va être de renvoyer à l'attaquant la configuration du FPGA, pour permettre une identification de sa fonction. Les données vont être envoyées par la Cmal du FPGA à la Cmal du Novena qui va se charger de les injecter dans le flux légitime du Novena à destination du gros calculateur déporté.

                On suppose que la Cmal du FPGA dispose de la capacité de lire la configuration des portes logiques du FPGA. Si l'architecture du FPGA est stable, le processus peut prendre son temps, voire comporter une intervention humaine d'un opérateur analysant l'architecture du FPGA. Ceci dit, l'analyse doit pouvoir très largement s'automatiser : il s'agit d'identifier des schémas typiques de fonctions basiques et d'analyser leur enchaînement. Une fois que la fonction du FPGA a été identifiée par le gros calculateur déporté, l'usage des ports du FPGA est connu. Le blocage des données légitimes en sortie du FPGA et la stricte réplication malveillante des lignes du bus peuvent être opéré. Le premier FPGA est contourné.

                La communication malveillante peut maintenant s'établir avec le FPGA de contrôle, pour réaliser le même processus : identifier sa fonction de façon déportée, par la prise de connaissance de son architecture, puis contourner sa fonction de soustraction des trames illégitimes sur les ports à destination du FPGA principal.

                Si le FPGA de contrôle est programmé pour, il peut ajouter sa propre signature dans le flux de données qu'il émet vers le FPGA principal (qui doit s'attendre à voir systématiquement la bonne signature pour valider les données reçues), rendant inopérante la simple réplication des signaux de part et d'autre de ce FPGA. Quelle que soit la forme d'intervention du FPGA de contrôle sur les données qu'il relaie, on comprend qu'il reste envisageable pour la Cmal locale de générer des artéfacts adéquats sur les lignes d'adresses pour communiquer avec le FPGA principal (les lignes d'adresse pour mieux cacher l'information illégitime, mais ce pourrait être les lignes de données, on est d'accord). Le tout est d'identifier quels sont les ports utilisés par le FPGA de contrôle pour communiquer avec le circuit suivant.

                Une fois au niveau du FPGA principal, la difficulté est d'un autre ordre si son architecture n'est pas stable mais dynamique…
                L'enjeu est alors de rendre possible la remontée de la configuration du FPGA avec un débit suffisant.
                Si la malveillance peut se propager aux mémoires de masse (intégrant donc une couche Cmal normalisée) accessibles localement par le FPGA principal, les informations récupérées peuvent permettre à l'attaquant de définir avec une précision accrue la prochaine configuration du FPGA. On comprend que la configuration dynamique du FPGA principal dépendra des actions de l'utilisateur (lancement de tel logiciel, etc), mais une fois une configuration donnée connue et en suivant l'enchaînement des commandes de l'utilisateur parvenant au FPGA, il est envisageable d'obtenir une connaissance prédictive de la prochaine configuration. Ainsi, nul besoin d'envoyer l'évolution de la configuration de chaque porte logique. Seuls des aspects spécifiques comme les entrées de l'utilisateur et le branchement de nouvelles mémoires de masse sont alors des informations clé.

                Restons confiant dans la détermination des acteurs malveillants pour chercher à voler/contrôler/modifier des informations à distance.

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

                  Posté par (page perso) . É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.

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

                    Posté par . Évalué à -10.

                    C'est bon Benoît, détends-toi, je ferme le compte.

                    Tu as parfaitement réussi ta mission et je comprends que c'était pénible. Lorsque j'ai rendu hommage à Faurisson sur /board il y a 1 an ou deux (sans reprendre à mon compte sa thèse, il y a une putain de loi anti-démocratique qui me l'interdit), tu as bien servi ta mission en tachant de restreindre mon accès au site. Quelques réactions de moules plus dignes que les autres t'en auront un peu dissuadé. C'était finalement mon seul écart majeur par rapport à la pensée unique, ou presque (oui, je critique aussi le sionisme, d'ailleurs c'est lié).

                    Tu t'es retrouvé à prêcher la défense de la dignité juive en combattant une prétendue dérive antisémite. Je suppose que j'étais encore dans la cible. Finalement, je suis l'objet d'une cabale dont même la plupart des molusques qui fréquentent /board se sont réjouit.

                    Mon comportement est simplement le fruit de ma réaction naturelle à l'état d'esprit étriqué, mensonger, vulgaire, qui règne trop ici.

                    Je comprends tout cela. Je sais que Faurisson est "sale" pour le vulgus pecum. J'ai un frère plus âgé qui pense aussi ainsi, je n'ai plus de relation avec lui qu'administratives.

                    Le combat pour la défense de la dignité juive, Benoît, si tu veux le faire tien véritablement, regarde la responsabilité d'élites (prétendument) juives (j'ai un doute) comme les Rothschild, qui ont financé le régime Nazi, comme d'autres banques américaines (prétendument) dirigées par des juifs (des juifs antisémites ? Tiens c'est subtil). Regarde aussi la responsabilité de juifs français durant la seconde guerre, dans la délation de juifs immigrés d'Europe de l'est, pour satisfaire les désirs du gouvernement allemand de l'époque. Enfin, regarde toute la matière historique rassemblée par Faurisson et ses pairs, ça devrait relativiser les 9 heures du film "Shoah" de Claude Lanzmann. Mon frère, imbibé de ce film et de la conviction qu'il s'est forgé sur la base d'une centaine de témoignages convergeant qu'il y a vu, n'est pas capable de revenir sur la question rationnellement. Je suppose qu'il en est ainsi de nombreux naïfs.

                    Vive le révisionnisme historique, la condition même du progrès en matière historique. La condition même de la défense des modestes juifs qui ne sont pas membres de l'olligarchie.
                    A bas la pression intra-communautaire y compris par la violence.

                    Et Salut à tous.

      • [^] # 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 à ceux qui les ont postés. Nous n'en sommes pas responsables.