Sondage J'indente mon code source avec

Posté par .
Tags : aucun
11
20
oct.
2010
  • des tabulations :
    1095
    (48.0 %)
  • des espaces :
    761
    (33.4 %)
  • les deux :
    210
    (9.2 %)
  • je n'indente pas, c'est pour les mauviettes :
    160
    (7.0 %)
  • IOCCC forever ! :
    53
    (2.3 %)

Total : 2279 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.
  • # Proposition de sondage

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

    Ceci est un sondage qui nous a été proposé par Hervé. Merci à lui.
    Sachez que nous avons reçu pas mal de proposition ces derniers temps, donc si vous ne voyez pas la vôtre tout de suite, c'est normal, la file d'attente est assez remplie et si on s'en tient à http://linuxfr.org/poll/send,204.html il ne devrait changer que tous les 15 jours.

    Merci à tous pour vos propositions.
    • [^] # Re: Proposition de sondage

      Posté par . Évalué à 3.

      J'avais proposé le même sondage il y a quelques mois, avec comme choix supplémentaire la taille des indentaions (3 / 4 / 8 ...) Le refus implicite, c'est parce que c'est trop compliqué de proposer des choix avec des nombres à une moule?
      • [^] # Re: Proposition de sondage

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

        Il y a quelques mois, les messages envoyés à sondages@linuxfr.org n'étaient pas reçu. Ce point a été corrigé depuis quelques semaines seulement.
        Ce sondage a été proposé il y a une douzaine de jours et on l'a publié. On préfère juste procéder en deux fois. Le prochaine concernera donc la taille des indentations.
    • [^] # Re: Proposition de sondage

      Posté par . Évalué à 3.

      existe t il une liste quelque part des sondages en attentes ?

      Histoire de pas re-proposer des trucs qui ont déjà été proposé, vérifier que la proposition qu'on a fait a été reçu, voir dans combien de temps la proposition qu'on a fait sera en ligne...

      ca sert peut etre pas à grand chose mais bon .... ;)
      • [^] # Re: Proposition de sondage

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

        >> existe t il une liste quelque part des sondages en attentes ?

        Fais une demande sur le suivi.
        Ah, on me dit que trop tard, c'est déjà fait… [https://www.linuxfr.org/tracker/1025.html]
      • [^] # Re: Proposition de sondage

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

        Non, ca n'existe pas. Enfin si, dans la boite email des admins.

        Tout comme pour les dépêches, je ne suis pas sûr que la visibilité avant publication soit la meilleure des choses. Il y a du spam, des conneries, etc. et parmi les propositions, on peut souvent fusionner deux propositions intéressantes sur le même sujet pour un tirer un sondage plus sympa que si un seul des deux était proposé.
        Pour l'accusé de réception, j'essaye de répondre quand le msg a été reçu.
        Quant à savoir quand elle sera en ligne, c'est plus dur... la file d'attente est déjà pas mal remplie...
        • [^] # Re: Proposition de sondage

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

          « […] et parmi les propositions, on peut souvent fusionner deux propositions intéressantes sur le même sujet pour un tirer un sondage plus sympa […] »
          Justement, si les sondages proposés étaient ouverts aux commentaires, cela permettrait des améliorations en collaboration avec tous les contributeurs, plutôt que seulement celles des admins. Non ?
          • [^] # Re: Proposition de sondage

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

            On parle juste de sondage dont, je le rapelle, 76,78% des sondés estiment qu'ils sont ineptes ! L'équipe de modération du site a déjà pas mal à faire avec les autres contenus après leur soumission.

            L'effet pervers que je vois est qu'on arriverait à des contenus policés, tous issus d'un consensus mou si l'on devait ouvrir aux commentaires les contenus proposés avant publication. Pas très propice aux tro^W débats :)
            • [^] # Re: Proposition de sondage

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

              Ou pas : chacun viendrais mettre son grain de sel puis l'équipe qui publie les sondages prendrait sa décision. Probablement pas plus policée que ce qui se fait actuellement. Sauf qu'un peu plus de petites mains, affairées sur leurs claviers, auraient eu l'occasion d'abonder de leurs idées.
  • # Les deux…

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

    Non, je n'ai pas répondu « les deux » : c'est une pratique aberrante. Mais je trouve amusant que ce soit le réglage par défaut de Vim et d'Emacs, de faire un affreux mélange de tabulations et d'espaces. Ceux qui font ça devraient être, euh, condamnés à faire du Lisp tout leur vie.
    • [^] # Re: Les deux…

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

      Même quand on utilise des espaces, les tabulations restent indispensables pour les Makefile.
      • [^] # Re: Les deux…

        Posté par . Évalué à 4.

        > les tabulations restent indispensables pour les Makefile.

        Pas vrai. Tu peux utiliser la variable .RECIPEPREFIX pour changer le préfix des règles :
        http://www.gnu.org/software/make/manual/make.html#Special-Variables

        Et là, tu commences sérieux à rendre le Makefile pâteux. Déjà que c'est pas simple à lire...
        • [^] # Re: Les deux…

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

          On parlait de Makefile, pas de GNU Makefile. Ça m'a tout l'air d'être une extension GNU.
    • [^] # Re: Les deux…

      Posté par . Évalué à 4.

      Ceux qui font ça devraient être, euh, condamnés à faire du Lisp tout leur vie.

      Du elisp tu veux dire, avec ingestion de la référence.
    • [^] # Re: Les deux…

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

      J'ai mis les 2 parce que j'utilise des tabulations pour tout sauf python. J'avais p-ê mal compris la question :)
  • # une seule ligne

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

    Tout le code sans retour à la ligne. C'est ça, un vrai mec !
  • # lequel ?

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

    Si je mélange espace et tabulation mais en alignant sur la droite, je peux mettre IOCCC ?
    • [^] # Re: lequel ?

      Posté par . Évalué à 1.

      je mélange espace et tabulation mais en alignant sur la droite

      Comment tu peux aligner un mélange d'espace et de tabulation, dont tu ne contrôles pas la taille!

      Quand je vois du code comme ça (en tabsize=2, ça se voit tout de suite), je @#$%^ essaye de rester calme et poli, mais c'est dur.
  • # et pour le C ?

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

    Une liste des divers styles ici : http://en.wikipedia.org/wiki/Indent_style qui n'a pas de parti-pris. Ensuite c'est carrément la guerre de religion :)

    De mon coté, depuis mes débuts avec le Lattice C dans les années 80, j'ai réussi à m'en tenir au Whitesmiths, qui est de loin le plus visuellement parfait.

    Et vous ?

    * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

    • [^] # Re: et pour le C ?

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

      Allman. Le Whitesmiths est une aberration.
      • [^] # Re: et pour le C ?

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

        Le Whitesmiths est une aberration.

        Pourquoi ?

        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

        • [^] # Re: et pour le C ?

          Posté par . Évalué à 7.

          La réponse est dans ton premier message, juste après "Ensuite".
        • [^] # Re: et pour le C ?

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

          Parce l'indentation représente un nouveau contexte empilé, et que c'est l'intérieur des accolades qui a un contexte particulier. Les accolades elle-mêmes ne font que grouper les instructions qui sont dedans, en tant que telles elles sont juste une instruction normale.
      • [^] # Lisp vaincra (même si ce n'est que dans le style)

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

        Mais non voyons, seul le style lisp est raisonnable ! Comment peux-t-on imaginer en utiliser un autre ! Lisp RuLZ !

        Sérieusement, l'un des avantages du style lisp, c'est d'économiser la place. Et ça pour la mise en forme de sujets d'examen de programmation, c'est essentiel. Sinon, ça restreint aussi les nécessités de déplacements pour observer des morceaux de codes.
      • [^] # Re: et pour le C ?

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

        Je viens de découvrir que les coreutils sont codés en whitesmiths.
        Tous mes repères s'écroulent !
    • [^] # Re: et pour le C ?

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

      K&R Style.
    • [^] # Re: et pour le C ?

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

      Whitesmiths ? Mais quel horreur ! Du Allman en pire...
      KNF Style dans la place \o/
    • [^] # Re: et pour le C ?

      Posté par . Évalué à 3.

      Allman, avec quelques variantes (des espaces à l'intérieur des parenthèses et non à l'extérieur, par ex.)
    • [^] # Re: et pour le C ?

      Posté par . Évalué à 2.

      1TBS, pas de tabs, que des espaces.
      Et quelque soit le langage utilisé : shell, awk, C, C++
    • [^] # Re: et pour le C ?

      Posté par . Évalué à 3.

      Allman style. En fait ta question peut faire l'objet du prochain sondage.
      • [^] # Re: et pour le C ?

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

        En fait ta question peut faire l'objet du prochain sondage.

        Très bonne idée. Je vais essayer de rédiger l'AAV qui va bien.

        * Ils vendront Usenet^W les boites noires quand on aura fini de les remplir.

      • [^] # Re: et pour le C ?

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

        Sans le savoir je faisais du Contextual style ...
        j'ai donc involontairement copié Milan Adamovsky, Ou peut-être est-ce lui qui aurait copié sur moi ??
    • [^] # Re: et pour le C ?

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

      Allman aussi.
    • [^] # Re: et pour le C ?

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

      Kernel avec indentation par des tabs et alignement par des espaces. Par exemple:
      [tab]variable = très grosse expression
      [tab]           qui se continue
      
      Mathias
      • [^] # Re: et pour le C ?

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

        et il y a des éditeurs de texte qui gèrent ça où il faut le faire à la main ?

        Parce qu'effectivement, c'est le style idéal d'indentation je trouve. Mais très contraignant (car nécessite de changer le tabsize et ça bugge avec certains)
  • # Et les elastic tabstops ?

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

    Les tabulations et les espaces c'est mal, parce que dès que l'indentation et les aligements de commentaires d'un utilisateur A passent mal chez l'utilisateur B qui n'a pas configuré ses indentations pareil.

    Nick Gravgaard a inventé les « elastic tabstops », qui pourraient se traduire par « tabulations élastiques ». L'idée est que le même texte puisse apparaître correctement quel que soit les préférences d'indentation de chacun. C'est à dire qu'une tabulation sert vraiment à indenter, et que l'alignement des commentaires ou de code sont garanties d'une ligne sur l'autre, quel que soit le texte écrit avant.

    http://nickgravgaard.com/elastictabstops/
    • [^] # Re: Et les elastic tabstops ?

      Posté par . Évalué à 5.

      Avec un vrai éditeur, il est possible de définir la taille des indentations directement dans le fichier, comme ca c'est indépendant des réglages de l'utilisateur, donc le source est toujours formaté tel que l'a voulu d'auteur.

      par exemple, des commentaires à placer a la fin d'un fichier C++, pour emacs :

      // Local Variables:
      // mode: c++
      // tab-width: 8
      // End:


      Et la meme chose pour vim :


      // vim: set ts=8 sw=4 filetype=cpp


      Evidemment, on peut mettre les deux simultanément, comme ca tout le monde est content...
      • [^] # Re: Et les elastic tabstops ?

        Posté par . Évalué à 2.

        Un vrai éditeur devrait être capable de déterminer automatiquement le type d'indentation et de le reproduire, même si il n'est pas indiqué explicitement.

        Oui c'est assez compliqué, si on veut un résultat fiable et précis, sachant qu'il existe pas mal de variantes possible.

        Non, je ne connais aucun éditeur ou outil qui fasse cette reconnaissance... à part un bout de code dans mon home, qui ne marche pas très bien et sur lequel il faudrait que je passe plus de temps... c'est pas gagné.
        • [^] # Re: Et les elastic tabstops ?

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

          >> Un vrai éditeur devrait être capable de déterminer automatiquement le type d'indentation et de le reproduire, même si il n'est pas indiqué explicitement.

          Ça demande qu'on écrive un analyseur syntaxique pour chaque langage…
          C'est pas gagné…
          • [^] # Re: Et les elastic tabstops ?

            Posté par . Évalué à 2.

            N'exagérons rien... la taille des tabulations, l'utilisation d'espace uniquement, la taille des niveaux d'indentation peuvent être déterminées globalement. Ensuite, il y a effectivement des subtilités suivant les langages comme l'indentation Smart Tab en C, mais il n'y a pas besoin pour autant d'un analyseur syntaxique... à moins que tu penses à un exemple précis?
      • [^] # Re: Et les elastic tabstops ?

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

        Désolé, mais ce genre de choses me choque complètement... J'ai des collègues qui indentent avec des tabs à 2 espaces. Avec une indentation aussi "subtile", je ne vois strictement rien à la structure du code. Donc je règle mes tabs à 6 ou 8 charactères. Et je n'ai pas à leur imposer mes choix...

        Le boulot d'un bon éditeur n'est pas de m'imposer la façon dont je dois voir le code, mais de faire que l'indentation s'adapte à mon souhait, et que les alignements soient respectés. D'où mon choix d'indenter avec des tabs et d'aligner avec des espaces (la version "elastic tab stops" du pauvre).

        Mathias
    • [^] # Re: Et les elastic tabstops ?

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

      Les tabulations et les espaces c'est mal, parce que dès que l'indentation et les aligements de commentaires d'un utilisateur A passent mal chez l'utilisateur B qui n'a pas configuré ses indentations pareil.

      Oui et non. Cela dépend du style adopté pour l'alignement des paramètres d'une fonction par exemple. Si tu codes comme ceci, pas de problème:


      void ma_fonction (int param1, int param2, int param3)
      {
      }


      Mais dans de nombreux projets, on met les paramètres d'entrée et de sortie sur des lignes différentes pour voir plus facilement ce qui a changé lors d'un diff. Et là tu as des styles différents...

      1. ceux qui alignent les paramètres entre eux (chose que tu ne peux faire qu'avec des espaces)


      void
      ma_fonction (int param1,
                   int param2,
                   int param3)
      {
      }



      Ou bien
      2. tu décides que seuls les paramètres 2 à n seront alignés entre eux, et tu utilises un nombre fixe de tabulations (en général 2) pour les indenter.


      void
      ma_fonction (int param1,
              int param2,
              int param3)
      {
      }


      Le cas 1 est un exemple classique de où un utilisateur habituel de tabulations est obligé d'utiliser des espaces. Et le résultat fonctionne quelque soit la configuration. Pour faire du relatif -> tabulation, pour faire de l'absolu -> espaces.

      Perso, je préfère le cas 2. Il n'oblige pas à toucher à des lignes sans autre raison que changer l'indentation, comme par exemple quand on change le nom de la fonction et qu'il devient plus long ou plus court.
      • [^] # Re: Et les elastic tabstops ?

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

        Tu es absolument pertinentissime. Mais moi je prefere le cas 1, d'ailleurs emacs indente ainsi, preuve que c'est le bon choix.
      • [^] # Re: Et les elastic tabstops ?

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

        Je préfère écrire dans mon code personnel. Je n'aime pas mettre les , à la fin de mes phrases, je ne les vois pas.
        void
        ma_fonction
        ( int param1
        , int param2
        , int param3
        ) {
        /* ... */
        }
        • [^] # Re: Et les elastic tabstops ?

          Posté par . Évalué à 8.

          T'as appris à développer sur un écran de calculette?
          • [^] # Re: Et les elastic tabstops ?

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

            Mes premiers programmes furent un Othello et un Masterming sur TI-92. Et dernièrement, pour mes développement personnels, j'utilisaient un netbook.

            Ceci répond-il à ta question ? :D
      • [^] # Re: Et les elastic tabstops ?

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

        On peut faire le cas 1 avec des tabulations, et tout restera bien aligné.
        Il suffit de mettre une tabulation après la parenthèse ouvrante.

        void
        ma_fonction(  int param1,
                      int param2,
                      int param3)
        {
        }


        Cela dit, il m'arrive d'utiliser aussi des espaces, par exemple pour aligner sur plusieurs lignes une condition de test compliquée (avec plein de &&, de || et de parenthèses).
        • [^] # Re: Et les elastic tabstops ?

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

          On peut faire le cas 1 avec des tabulations, et tout restera bien aligné.

          Justement non, c'est bien pour cela que je dis que c'est le seul cas où on est obligé d'utiliser des espaces.

          Soit x la largeur d'une tabulation. En général x = 4 espaces. Dans ton exemple, "int param1" commence à 12 + x. 12 est le nombre de caractères de "ma_fonction(". Or si tu as quelques connaissances en algèbre, tu te rendras vite compte que cela ne fonctionne pas.

          La ligne suivante avec des espaces vaudra 14. Avec que des tabulations vaudra n*x où n est un entier. Tenter de faire 12 + x = 14 te fait déduire que x = 2, or chaque éditeur ou utilisateur peut régler la taille des tabulations. Un utilisateur qui utilise autre chose que la largeur de 2 espaces pour une tabulation ne verra plus les variables alignées.

          Le seul moyen c'est même nombre de tabulations et d'espaces sur chaque ligne avant les éléments à aligner...
  • # La seule vrai bonne façon de faire que j'ai raison et pas les autres

    Posté par . Évalué à 5.

    - J'indente avec des tabulations
    - J'aligne avec des espaces

    Vu que le sondage ne parle que d'indentation j'ai donc voté "des tabulations".
    • [^] # Re: La seule vrai bonne façon de faire que j'ai raison et pas les autre

      Posté par . Évalué à 3.

      Tout pareil ici !
      • [^] # Re: La seule vrai bonne façon de faire que j'ai raison et pas les autre

        Posté par . Évalué à 2.

        Je fais exactement pareil et voici comment s'en servir: la tabulation indique la "profondeur" du bloc d'instructions, et les espaces (situés après des caractères de tabulation) servent pour l'alignement à l'intérieur du bloc.
        Pourquoi ? c'est simple: l'alignement à l'intérieur du bloc doit se faire au caractère prêt, et la taille du caractère de tabulation peut changer d'un éditeur à l'autre. Résultat: quelque soit la configuration de l'éditeur utilisé, le code source est correctement visible peu importe les préférences de la taille de la tabulation.

        Et il semblerait d'après un commentaire plus haut que c'est la méthode d'indentation utilisée par le kernel linux (https://linuxfr.org/comments/1173156.html#1173156 qui montre aussi un exemple du concept )

        Les espaces sont généralement peu fréquent car ils servent pour les lignes trop longues ou autres cas rares.

        Par contre, ceux qui indentent qu'avec des espaces négligent totalement les préférences d'indentation des utilisateurs (j'ai déjà vu du 8 espaces qui est trop pour moi, ou 2 pas assez, chacun ses préférences ceci dit).
  • # Indentation par l'espace

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

    Personnellement je n'ai jamais compris l'intérêt d'indenter avec des espaces (d'ailleurs, je parle normalement de tabulation, ce n'est pas pour rien). Je trouve ça peu pratique au possible. Le pire ce sont ceux qui indentent du code avec un ou deux espaces.
    • [^] # Re: Indentation par l'espace

      Posté par . Évalué à 5.

      J'imagine qu'avec des espaces il aura toujours la même tronche (la longueur de la tabulation peut varier d'un environnement à un autre).

      Au fait, j'indente avec deux espaces maximum, parce que je déteste voir un ascenseur horizontal dans une page de code :)

      (Ou une césure de ligne avec Emacs, etc.)
      • [^] # Re: Indentation par l'espace

        Posté par . Évalué à 6.

        C'est marrant, car le kernel exige une indentation de 8, mais pour la même raison... car si il y a trop de niveau d'indentation, c'est que le code est mauvais et doit être réécrit.
        • [^] # Re: Indentation par l'espace

          Posté par . Évalué à 2.

          Comme quoi y a deux méthodes pour briser une dépendance, voici la classique :
          - Bon, y a plus de bouteilles ici, maintenant c'est de l'eau, compris ?

          Voici la méthode kernel :
          - Allez, bois de force ces verres. Si tu en bois un de plus, il te mettra raide KO et tu finiras en tutu sur Facebook.

          :D
      • [^] # Re: Indentation par l'espace

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

        « J'imagine qu'avec des espaces il aura toujours la même tronche (la longueur de la tabulation peut varier d'un environnement à un autre). »

        Justement, c'est tout l'intérêt ! Ainsi chacun peut lire le code avec ses propres préférences. Par exemple toi qui n'aime pas le code fortement indenté tu peux régler ta taille de tabulation à 2, tandis que ton voisin la mettra par exemple à 8.

        Je sens venir l'argument : « oui mais si on change la taille ça fait n'importe quoi ». Quand ça arrive ça veut dire que soit il y a un mélange de tabulations et d'espaces (beuargh), soit le programmeur a fait la connerie d'aligner avec des tabulations. Les tabulations c'est pour indenter, pas pour aligner.
        • [^] # Re: Indentation par l'espace

          Posté par . Évalué à 4.

          Sauf que un point habituel dans les règles de codage est la taille max de la ligne, souvent fixée à 80 caractères : si un type s'amuse à coder avec des tabs de 2 ou 4, il risque de dépasser cette limite sans s'en apercevoir.

          De plus, s'amuser à vouloir changer la taille des tabs, ça casse forcement l'indentation dans des cas précis :
          int.moule(void).{......//.cette.fonction
          ------->return.0;......//.renvoie.toujours.0
          }

          L'autre point, c'est que les éditeurs ne gère pas très bien cette fonctionnalité. À part Emacs, vous connaissez quel éditeur qui la gère?
          • [^] # Re: Indentation par l'espace

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

            La limitation à 80 caractères, ca vient surtout de la taille des cartes perforées ... et donc du FORTRAN (77 et antérieur). Même une vénérable VT100 peut afficher 132 colonnes.

            Je suis d'accord qu'il faut des lignes de taille raisonnable, mais j'ai tendance à mettre une limite floue, quelque part vers 120 colonnes, voire plus si le besoin s'en fait sentir.

            En tout cas, cumuler des tabulations à 8 espaces et une limitation à 80 caractères par ligne, c'est se tirer une balle dans le pied. Dès qu'on imbrique deux tests et un switch, hop, on est coinçé pour utiliser des noms de variable un peu explicites. Et les retours à la ligne automatiques sont à mon avis un remède bien pire que le mal, en terme de lisibilité.
            • [^] # Re: Indentation par l'espace

              Posté par . Évalué à 3.

              Un autre problème de dépassement de ligne survient avec les chaînes "longues". Il y a quelque chose que j'aime bien en C, c'est la possibilité de "découper" les chaines sans incidence sur le programme lui-même :

              char * string = "blablabla"
                              "bliblibli"; /*équivalent à "blablablabliblibli"*/


              Je ne sais pas si c'est le préprocesseur qui s'en occupait ou le compilateur, mais je trouvais cette fonctionnalité bien pratique, dommage qu'elle n'ait pas été conservée (sauf erreur de ma part) pour d'autres langages à la syntaxe proche.
              • [^] # Re: Indentation par l'espace

                Posté par . Évalué à 3.

                je trouvais cette fonctionnalité bien pratique,

                c'est quand même le truc super chiant quand tu cherche quel code fait ce #$%^^& de message d'erreur, vu que grep ne matche plus!
                char* error = "FATAL ERROR NUMBER 123"
                "456";


                mouais....
              • [^] # Re: Indentation par l'espace

                Posté par . Évalué à 1.

                Python et Ruby ont le même comportement, après savoir s'ils ont une syntaxe proche ou non relève d'un autre troll.
                • [^] # Re: Indentation par l'espace

                  Posté par . Évalué à 2.

                  Note que l'avantage pour un langage compilé est qu'une telle syntaxe, n'influe pas sur les performances à l'exécution (je sais, ça sert à rien, mais c'est une question de conscience :)).
    • [^] # Re: Indentation par l'espace

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

      Bah moi c'est le contraire, je n'utilise que des espaces (deux). Au moins c'est toujours la même largeur, quel que soit l'éditeur.

      J'utiliserai des tabulations lorsque leur largeur sera fixée à 2 (ou 3, à l'extrême rigueur) dans tous les éditeurs et que cette valeur ne sera pas modifiable par un utilisateur sadique.

      Et au fait en typographie c'est unE espace, pas un espace.
      • [^] # Re: Indentation par l'espace

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

        L'intérêt d'indenter, c'est de rendre le code lisible, et d'éviter les fonction avec trop de profondeur (genre 10 boucles imbriquées, ou des conditions qui n'en finissent plus).

        8 espaces, qui est la valeur d'origine de la tabulation, c'est effectivement trop. Je trouve personnellement que 4 c'est la taille idéale pour du code source. Au premier coup d'œil je repère l'indentation, et je n'ai pas à trop bouger la tête pour associer l'instruction d'introduction du bloc au bloc. Efficacité, fainéantise, etc.

        D'ailleurs, c'est l'efficacité qui me fait haïr l'indentation par les espaces. Je ne vois pas la différence entre 3 espaces et 4 espaces.

        En dehors du boulot, le seul endroit où j'utilises des indentations avec des espace c'est dans des fichiers de données (XML, JSON, etc).

        Et au boulot, mon source est truffé d'indentation à 4×n+3 parce que entre 7 et 8 tabulations, je ne vois pas la différence. Et Vim (malgré >>) ne m'aide pas beaucoup sur ça. Et l'indentation, en Python, c'est assez important.
        • [^] # Re: Indentation par l'espace

          Posté par . Évalué à 3.

          « Et au boulot, mon source est truffé d'indentation à 4×n+3 »
          Il ne suffirait pas de configurer ton éditeur pour qu'il insère/supprime autant d'espaces que nécessaire à chaque tab/backspace? laisse moi deviner... ton éditeur n'en est pas un, c'est juste un étron modelée en forme d'éditeur, mais tu n'as pas le choix? Dans ce cas, toutes mes condoléances.

          J'avoue préférer de loin l'indentation uniquement à base d'espace, car ça limite les grands n'importe quoi, lorsque pleins de personnes touchent au code, chacune avec leur éditeur configuré différemment... mais il existe un cas tordu, relevé dans un commentaire ci dessus, celui des makefiles qui veulent à tout prix des vraies tabulations.
          • [^] # Re: Indentation par l'espace

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

            Le soucis c'est que je ne veux pas que mon Vi fasse ça. Quand je demande à Vi de supprimer un caractère, je veux qu'il en supprime un, pas plus. Sinon ça devient rapidement la fête du slip. Mais oui, il faudrait que je modifie le fichier de syntaxe python pour qu'il rougeoie à la vue d'une indentation malformée.
  • # [×] Je fais du Python

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

    Moi, je code en Python. Pas d'accolades, pas d'ambiguïté, pas de guerre d'indentation possible : l'indentation est obligatoire et se suffit à elle-même.
  • # Astyle ou cindent

    Posté par . Évalué à 2.

    Je reformate mon code avec des outils en ligne. Plus simple pour homogéniser le code
    • [^] # Re: Astyle ou cindent

      Posté par . Évalué à 5.

      Des outils en ligne ? Comme Google Indent ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # Le FALSE, il n'y a que ça de vrais!

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

    https://secure.wikimedia.org/wikipedia/en/wiki/FALSE

    Comme quoi, l'indentation de sert à rien ;-)
  • # [ctrl]+k, [ctrl]+d

    Posté par . Évalué à 2.

    Beaucoup plus simple, CTRL+K, CTRL+D :)
  • # Commentaire supprimé

    Posté par . Évalué à 2.

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

Suivre le flux des commentaires

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