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

  • # Tabstop=2

    Posté par . Évalué à 2.

    Dans vim, éditeur convivial, léger et qui est parfaitement en accord avec la philosophie UNIX (faire un truc mais bien ;)), le tabstop vaut deux :). 4 est encore tolérable mais les puissances de 2 au dessus ça ne le fait plus...

    • [^] # Re: Tabstop=2

      Posté par . Évalué à 1.

      Tabstop=4 c'est bien aussi !

      Enfin j'ai voté \pi parce que quand même j'indente suivant l'indentation du programme où je me trouve et le codeur original passe de 7 à 1 caractère suivant la routine !

      • [^] # Re: Tabstop=2

        Posté par . Évalué à 1.

        J'ai voté \pi car si on écrit \pi en base 26 le premier mots de 5 lettres de \pi est sexués.

    • [^] # Re: Tabstop=2

      Posté par . Évalué à 3.

      Deux, c'est parfait. C'est plus que 1 donc on peut différentier avec un espace, et ça facilite le respect de la largeur du texte à 80 colonnes.

      • [^] # Re: Tabstop=2

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

        Pour paraphraser les conventions de codage d'un projet qui a un peu de poids, si avec des indentations de 8 caractères tu tapes trop rapidement dans la marge de droite, alors tu as d'autres problèmes que de savoir si tabstop=2 ou tabstop=4.

    • [^] # Re: Tabstop=2

      Posté par . Évalué à 1.

      En accord avec la philosophie UNIX? Tu as dû te tromper de monde parallèle... dans le monde actuel, toutes les philosophies, sauf une, s'accorde à dire qu'un tab, ça équivaut à 8 caractères. Il est cependant vrai que la philosophie qui diffère des autres, que l'on appelera je-chie-sur-la-compatibilité-en-modifiant-les-standards-pour-des-raisons-de-goût-personnel est une philosophie qui rencontre beaucoup de succès en informatique, mais pas trop dans le monde UNIX.

      Et sinon, est ce que la philosophie UNIX de ton monde parallèle utilise des '\' au lieu de '/' comme séparateur de chemin?

      Si tu comptes rester plus de temps ici, je peux te proposer de configurer les valeurs softtabstop et expendtab de ton éditeur, afin de ne pas casser ce qui reste de nos standards, tout en respectant tes goûts personnel.

      • [^] # Re: Tabstop=2

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

        Et pourquoi tu n'as pas parlé de softtabstop dans le précédent sondage, quand je me plaignait de devoir appuyer ×ばつ une touche pour supprimer l'indentation.

        Scrogneugneu!

        En tout cas merci, je suis toujours passé à côté de ce tweak.

  • # La suite

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

    Ce sondage est la suite naturelle du précédent concernant le type d'indentation utilisé : http://linuxfr.org/poll/send,205.html où, pour rappel, nous avions eu les résultats suivants :
    * des tabulations : 1095 (48%)
    * des espaces : 761 (33.4%)
    * les deux : 210 (9.2%)
    * je n'indente pas, c'est pour les mauviettes : 160 (7%)
    * IOCCC forever ! : 53 (2.3%)

    • [^] # Re: La suite

      Posté par . Évalué à 10.

      D'ailleurs je propose que le sondage suivant soit sur le fait de mettre ou non les accolades à la ligne.
      Captivant...

      • [^] # Re: La suite

        Posté par . Évalué à 2.

        Tu ne critiques pas ma proposition.

        • [^] # Re: La suite

          Posté par . Évalué à 2.

          Ah loupé, c'était pas celle-là. Mais tu ne critiques pas quand même. :)

      • [^] # Re: La suite

        Posté par . Évalué à 3.

        Dans ce cas il faut pouvoir répondre "y'a pas d'accolades dans le langage que j'utilise ; les accolades c'est pour les n00b"

  • # Choix manquant...

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

    ... un caractère (une seule tabulation, quelque soit le rendu dans l'éditeur).

    • [^] # Re: Choix manquant...

      Posté par . Évalué à 5.

      La question justement comme tu configures l'affichage des tabulations.

      « 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

  • # quatre est le bon compromis

    Posté par . Évalué à 2.

    a deux on remarque plus difficilement les bloc, a 8 on ne vois plus la condition du test (trop éloigné du bloc) et pour peu qu'il y ait des des noms un poil long, on atteint rapidement la largeur permettant d'avoir deux morceaux de code cote à cote ^^

    π serait une taille intéressante, mais pas gérée par eclipse ou emacs (une évolution à faire?)

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: quatre est le bon compromis

      Posté par . Évalué à 4.

      a deux on remarque plus difficilement les bloc

      c'est une blague ? même à 1 on les reconnaît.

      π serait une taille intéressante, mais pas gérée par eclipse ou emacs (une évolution à faire?)

      l'optimum, c'est e.

    • [^] # Re: quatre est le bon compromis

      Posté par (Mastodon) . Évalué à 2.

      Moi j'ai voté π parce que c'est ce qui se rapproche le plus de ce que j'utilise : 3.

      Me demandez pas pourquoi 3...

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # C'est pas la taille qui compte

    Posté par . Évalué à 10.

    ---> []

  • # A la tronches des sondages dernièrement sur linuxfr,

    Posté par . Évalué à 10.

    on voit bien que linux n'est pas prêt pour le desktop !!

  • # Problème de la taille des tabulations avec une limite de 80 colonnes

    Posté par . Évalué à 1.

    Je ne comprends pas pourquoi certaines personnes tiennent à coder dans la limite conventionnelle de 80 colonnes et configurent leur éditeur pour que les tabulations s'affichent sur moins de 8 caractères. Conventionnellement, une tabulation est affichée avec une taille de 8 caractères et la plupart des éditeurs cont configurés comme ça par défaut. Du coup, le même code sur un éditeur non configuré dépasse les 80 colonnes… Il faut savoir si on veut que notre code s'affiche sur 80 colonnes max partout ou pas.

    Vaut-il donc mieux être conventionnel jusqu'au bout et coder sur 80 colonnes max avec des tabulations faisant la taille de 8 caractères ou alors la limite conventionnelle des 80 colonnes est devenue défénitivement obsolète avec nos grands écrans ?

    Personnellement, j'essaie de suivre les conventions du langage. J'utilise des tabulations (de taille 8 caractères) en C et 2 espaces en Ruby.

    • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

      Posté par . Évalué à 2.

      Pour mémoire, l'idée de garder les tabulations à 8 (et le texte à 80 colonnes) c'est de forcer à limiter la "profondeur" du code (le nombre d'imbrications). Les analyseurs de code (comme PMD et Checkstyle pour Java) signalent par exemple quand on dépasse 5 ou 6 niveaux d'indentation, car c'est probablement un signe de mauvais découpage de son code, et qu'il faut créer des (sous-)fonctions plus fines. Il me semble que pour le code de Linux on a la même recommandation.

      • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

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

        quand on dépasse 5 ou 6 niveaux d'indentation (...) c'est probablement un signe de mauvais découpage de son code, et qu'il faut créer des (sous-)fonctions plus fines. Il me semble que pour le code de Linux on a la même recommandation.

        Moins que ça même ; voir le fichier 'CodingStyle' présent dans les sources du noyau, chapitre un à ce propos :

        "The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

        • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

          Posté par . Évalué à 4.

          Ouais, enfin y'a toujours les if (x < 0) { ... } else if (x == 0) { ... } else { ...} qui formellement sont des imbrications gigognes, mais qui sont parfois difficilement évitables.

          C'est pas toujours une bonne idée de dire "jamais", c'est un peu comme les goto. Parfois le remède est pire que le mal; il faut juste être sûr que les gens savent ce qu'ils font quand ils contournent la recommandation:

          • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

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

            Avec un if/elseif/else tu ne rajoute qu'un niveau d'indentation.
            Donc quel est le problème ? Ca n'empêche pas de le limiter, non ?

            (pour ma part je suis plutôt avec des indentations de 2 caractères, 4 je supporte, 8 j'ai vraiment du mal, une impression de vide horrible. Un peu comme les hérétiques qui placent les accolades à la ligne)

            • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

              Posté par (Mastodon) . Évalué à 3.

              Ca te fait le même effet hein, les accolades à la ligne ?
              La première chose que je fais quand j'intègre un code extérieur à un de mes projets, c'est de refaire l'indentation comme il faut, et de virer ces sauts de lignes inutiles, le pire étant l'indescriptible accolade à la ligne...

              Yth.

        • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

          Posté par . Évalué à 4.

          Je trouve que ce genre de recommandation prend les programmeurs pour des abrutis.

          Les algos en O(n^6) existent, je les ai rencontrés. Hé bin ça fait 6 niveaux d'indentation, et même 7 puisque c'est forcément exécuté dans une fonction.

          Et même avec 3 niveaux d'indentation, avec des tabs de 8 caractères, ça ne laisse que 56 caractères de large, c'est vraiment pas beaucoup, notamment si on utilise des noms de fonctions et de variables un peu explicites.

          Et les 80 caractères, ça permet d'éviter de bouffer tout l'écran avec son code, c'est pas plus mal, surtout quand on a 3 shells ouverts à côté, une page de doc, et autre. Je suis très efficace quand je travaille comme ça.

          • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

            Posté par . Évalué à 1.

            Rien ne t'empêche de décomposer ton algo en sous-fonctions...

            • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

              Posté par . Évalué à 6.

              Mais quel est l'intérêt quand cela rend l'algo moins lisible ?

              Exemple tout simple, une opération sur deux tenseurs à 5 dimensions peut s'écrire très simplement avec 5 boucle for imbriquées et juste une opération toute simple au bout sur une ligne. Si les indices de tes boucle sont les mêmes que ceux que tu utilise dans la formule mathématique, tu obtiens la forme la plus lisible possible.
              Dans un cas comme celui-la, toutes les dimension sont égales et il n'y a pas de raison d'en mettre certaines dans une sous fonction.

              Et je peux te garantir que ce genre de cas est loin d'être rare et que ces bien souvent la meilleure façon de coder l'algo, c'est parfaitement lisible, on comprend tout de suite la relation avec les formules et le compilateur fait très bien sont boulot avec ce genre de code simple et explicite.

              Il faut arrêter d'être dogmatique et savoir enlever ses œillère de temps en temps. Ce genre de règles c'est bien de les avoirs en tête comme principe de base, mais c'est encore mieux de savoir les oublier quand c'est nécessaire.

              • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

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

                >> Exemple tout simple, une opération sur deux tenseurs à 5 dimensions peut s'écrire très simplement avec 5 boucle for imbriquées et juste une opération toute simple au bout sur une ligne.

                Ou avec une macro récursive, genre

                (define-macro (tensor-prod body . loops)
                (if (null? loops)
                `,body
                `(for ,(car loops)
                (tensor-prod ,body ,@(cdr loops)))))

                Que tu appelles ensuite

                (tensor-prod (foo a (bar b c))
                (a from 1 to 2)
                (b from 3 to 42)
                (c from 5 to 2 step -1))


                et qui te donne:

                (for (a from 1 to 2)
                (for (b from 3 to 42)
                (for (c from 5 to 2 step -1)
                (foo a (bar b c)))))


                Soit une profondeur d'indentation quelconque au prix d'une indentation constante de taille 1 (lors de l'appel, et 3 lors de la définition).

                • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

                  Posté par . Évalué à 2.

                  Mais tu n'as pas toujours le choix de programmer ta boucle en lisp, et dans mon cas ce n'est même pas une question de choix mais d'envie.

                  C'est surement une question d'habitude, mais autant je trouve que ton troisième extrait de code (le résultat de l'expansion de la macro) est lisible et que l'on comprend biens ce qui ce passe. Autant le deuxième est beaucoup moins clair pour moi et ce n'est pas la définition de la macro qui m'aide à comprendre.

                  Ma pratique du lisp remonte à un peu trop d'années pour que je puisse encore m'émerveiller devant ce genre de code et j'ai maintenant tendance à préférer le code parfaitement explicite ou l'on voit bien toutes les boucles sans avoir à réfléchir une heure pour savoir le nombre d'imbrications.

                  • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

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

                    >> Autant le deuxième est beaucoup moins clair pour moi et ce n'est pas la définition de la macro qui m'aide à comprendre.

                    Nan, mais c'est du one shot bourrin pour dire « l'indentation réelle peut être facilement retirée. »
                    En vrai, tu fais un truc joli, clair et réutilisable :

                    (nested-fors
                    ((a from 1 to 2)
                    (b from 3 to 42)
                    (c from 5 to 2 step -1))
                    (foo a (bar b c)))

                    que je trouve clair, net et concis.

                    Il m'arrive de coder en Scheme/Lisp pour générer du code C, car c'est super chiant de coder du C à la main dans certains cas !
                    Je ne vois pas d'inconvénients à coder dans un langage, si ça permet de faciliter l'écriture de programmes (pourquoi pas dans un autre langage, comme C).

                    Bon, après, les libertés au boulot et les goûts, je sais. Je vais pas te dire de changer de boite ou autre chose du même acabit, hein.

                    Mais si tu trouves normal et élégant tes 5 boucles FOR imbriquées (ce à quoi je me m'oppose pas), je dis (à d'autres moules qui liraient ce commentaire) qu'on peut faire encore plus élégant et tout aussi naturel, tout en gardant le même code C au final ! \o/

            • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

              Posté par . Évalué à 2.

              Dans certains cas, des considérations de performance encouragent à ne pas découper en sous-fonctions.

              Je suis d'accord que c'est assez spécifique, mais sur des algo de DSP ou de calcul haute performance (HPC), [et non, on ne fait pas/plus que de l'assembleur et du FORTRAN dans ces cas-là !] on peut manipuler beaucoup de boucles imbriquées autour d'un bout de calcul très simple.
              Le coût d'un appel de sous-fonction peut alors ne pas être négligeable : empilage des paramètres, branchement + delay slot, et au retour dépilage des valeurs de retour et second branchement + delay slot => ca fait plus d'une dizaine de cycles.
              Autour d'un papillon de FFT qui fait moins de 10 cycles, ca peut doubler le temps de calcul !

              Par ailleurs on veut souvent laisser le plus de sémantique possible au compilateur, pour qu'il puisse détecter du parallélisme, réordonner les boucles pour optimiser le remplissage des caches, ou bien rendre la fonction inline ... Les trucs à éviter pour que ca marche c'est la linéarisation des tableaux multi-dimensionnels, et l'arithmétique de pointeurs.
              Un exemple d'optimisations de ce genre : la librairie Graphite http://gcc.gnu.org/wiki/Graphite , intégrée dans GCC 4.4 http://linuxfr.org/2009/04/21/24809.html

              < radote >
              La limitation à 80 colonnes, c'était à cause des cartes perforées.
              Il n'y a que ceux qui codent encore en FORTRAN 77 (les pauvres) qui subissent encore cette limitation.
              < /radote >

    • [^] # Re: Problème de la taille des tabulations avec une limite de 80 colonne

      Posté par . Évalué à 2.

      avoir un format (colonnes, indentation, ...) standard, a tendance a rendre le code plus lisible.

      les conventions a un moment t sont compatible avec celle de t-1, et pouf recursion j'usqu'a 80 colonnes.

      et puis 80 colonne c'est trés bien sur les grand ecrans : on peut afficher 2 ou 3 code en parallele.

      Pour finir la limite de niveau d'indentation est en général a suivre, en particulier pas toujours ( une bonne tripoté de parametre, une bonne tripoté de comportement pas combinaison, pas de solution universel pour rendre ca lisible.)

  • # 3

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

    Je code en Ada sous emacs avec ada-mode, et je prends l'indentation par défaut soit 3 caractères (le plus proche dans le sondage c'est π).

  • # Oneliner !

    Posté par . Évalué à 0.

    Exemple d'un code à moi, où je savais pas quoi faire:

    char*s[]={"ga ","bu ","zo ","meu "};void main(int x, char**n){
    int v=x>1?atoi(n[1]):0;char t[32];char*m=t;while(v){*m++=v&3;v>>=2;}
    while(m-t){write(1,*(s+*m),3+*--m/3);}write(1,"\n",1);}


    Je me soigne, je le jure !

Suivre le flux des commentaires

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