Journal Quelles seraient les meilleures règles de formatage de code ?

Posté par  . Licence CC By‑SA.
10
29
nov.
2021

En programmation on a l’habitude, depuis quelque temps, de formater le code et notamment l’indenter.

L’objectif de ce formatage est généralement de faciliter la coopération, et de rendre le code le plus lisible possible.
Mais la lisibilité de code est forcément un critère avec de la suggestivité.

C’est notamment sur le sujet de l’indentation que j’ai vue passé le plus de désaccord plus ou moins cordiaux.

En ce qui me concerne j’ai toujours préféré indenter avec des tabulations plutôt que les espaces.
Déjà par habitude, j’ai beaucoup plus travaillé dans des bases de code où la règle c’est la tabulation.
Ensuite c’est un seul caractère à taper, stocker et supprimer contre généralement quatre espaces (rarement moins de deux).
Enfin la tabulation permet à chacun de choisir le nombre d’espaces équivalent en fonction de ses propres préférences, voir besoin.

Mais je suis conscient que ce n’est pas parfais, la tabulation à aussi des inconvénients.
Par exemple l’alignement d’un début de ligne avec un “milieu” d’une autre ligne n’est pas compatible avec le choix de la largeur des tabulations. (Bon je pense que c’est une fausse bonne idée pour d’autres raisons).

le formatage “parfait” ?

Du coup je me suis posé la question : si c’était à moi de choisir le formatage d’un projet, quel serais le meilleur ?

Aujourd’hui il y a des outils qui aident bien à conserver et unifier le formatage du code d’un projet. Mais il faut y penser si ce n’est pas automatisé, les assistants dans les éditeurs fonctionnent pas mal quand on écrit le code, souvent moins bien quand on en supprime.

Objectifs

Avant de pouvoir choisir le meilleur formatage, il faut déjà définir les objectifs.

En plus de la lisibilité intrinsèque du code, je souhaite que le formatage génère le moins de diff possible. En effet minimiser les diffs de code facilite les review de code pre et post commmit.
J’ai horreur des changements qui mélange des changements de code (logique) et des lignes avec seulement des changements “cosmétique”.
J’estime que la lisibilité du code a un instant t ne doit pas se faire au détriment de la lisibilité de l’historique.

ça m’est arrivé de travailler avec des personnes qui en C++ alignait le début du nom des variables d’un même groupe.
ça peut aider à la lisibilité du code à un instant t, mais ça demande un effort au programmeur et surtout ça demande de la maintenance quand le code évolue, du coup je classe ça en fausse bonne idée.
De la même manière aligner le début d’une ligne sur le contenu (milieu) d’une autre ligne, demande de la maintenance, cré des modifications de ligne “parasite” dans les diffs. => Fausse bonne idée.

Solution

Du coup, est-ce que le meilleur formatage ne serait pas un formatage “vide” : Aucune indentation, le strict minimum d’espaces ?

Et la lisibilité me direz-vous ?
Pourquoi ça ne serait pas à l’éditeur de code de s’en occuper ?

Avantages :
* plus besoin de taper, stoker et supprimer des caractères (tabulation ou espace) pour une question de formatage.
* la disposition pourrait être mise à jour de façon dynamique au fur et à mesure de la frappe, y compris quand l’utilisateur supprime du code.
* l’affichage pourrait être personnalisé par chaque utilisateur indépendamment vu que c’est l’IDE qui s’en occuperait.

L’inconvénient c’est que ça nécessiterait l’adaptation de nombreux outils ainsi que des changements d’habitudes important. Sans compter que basculer une code-base existante serais très délicat.

J’ai parlé principalement de l’indentation, mais on peut aussi réfléchir à la problématique de la longueur max des lignes de la même façon.

Et vous ?

Est-ce que vous avez déjà réfléchi à votre formatage parfais ? Que serait-il ?
Qui est chaud pour tester d’implémenter ça dans un formateur de code ?

  • # au fond, la forme

    Posté par  . Évalué à 2.

    Bref, fond et forme, la forme devrait être l’apanage du bidule de visualisation qui ferait le boulot en fonction des contraintes de l'humain qui est derrière la machine (non voyant, voyant, lecteur, pas lecteur etc.) … et le fond reste au fond.

    Il se fait tard pour épiloguer sur le sujet mais maintenant d'une manière plus pragmatique, on s'en fout c'est le bordel c'est déjà trop tard (on arrive à avoir des caractères "espaces" "invisibles" qui provoquent des failles de sécu alors bon l'humain est cuit s'il essaye de réfléchir aux espaces).

    My 2¢

    eric.linuxfr@sud-ouest.org

    • [^] # Re: au fond, la forme

      Posté par  . Évalué à 1.

      Ah oui, je m’étais dit que je parle de séparation fond et forme.
      C’est reconnu comme une bonne pratique pour les programmes, pourquoi ça ne le serait pas pour le code ?
      Mais j’ai oublié quand j'ai écrit le journal.

      Du coup ça me fait penser à l'expression :
      “Les cordonniers sont toujours les plus mal chaussés.”
      😀

  • # Python black

    Posté par  . Évalué à 6.

    En Python, on a black. Je l'utilise avec pre-commit pour formater le code avant de commiter.

    Au début, j'étais un peu gêné par certains choix, mais à l'usage, je trouve que le bénéfice en vaut la peine.

    Je n'ai plus besoin de fignoler le formatage pendant que je code, je laisse les choses vaguement propres et au commit black met tout au carré.

    Je l'ai utilisé trois jours et quand je l'ai plus, ça me gêne.

    • [^] # Re: Python black

      Posté par  . Évalué à 1.

      Oui ce genre d’outils est une évolution pratique.
      Mais ça ne serait pas encore mieux si c’était actualisé en temps réel dans l’éditeur ?

      • [^] # Re: Python black

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

        C'est possible aussi, ça se fait par exemple pour python avec PyDev dans Eclipse. Il le fait pas en temps réel, mais lors de la sauvegarde des fichiers.

      • [^] # Re: Python black

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

        Idem, chez moi (sous Vim) ça reformate quand je sauve le fichier.

        • [^] # Re: Python black

          Posté par  . Évalué à 3.

          Bonne idée, j'ai pas pensé à le faire à l'enregistrement, mais c'est encore mieux.

          • [^] # Re: Python black

            Posté par  (site web personnel) . Évalué à 4. Dernière modification le 02 décembre 2021 à 10:30.

            Oui, je trouve ça moins intrusif. Je fais pareil pour tout ce qui est analyse statique (pylint, mypy, flake8) avec ale, ça se lance à la sauvegarde. Pour ceux que ça intéresse: https://github.com/liberforce/vimrc

            • [^] # Re: Python black

              Posté par  . Évalué à 3.

              L'inconvénient c'est si tu l'as dans ta config globale et tu dois bosser sur un projet qui black pas, tu te retrouves à modifier plein de lignes de code sur lesquelles tu interviens pas à chaque fois que tu commites. Je sais pas comment ça se gère.

              • [^] # Re: Python black

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

                Il y a moyen d'avoir de la configuration conditionnelle par projet sous Vim, mais j'avoue que je ne me suis jamais trop pris la tête. Les rares fois où ça m'arrive j'adapte les linters et formatteur utiles au projet en question dans ma config globale. Au pire les checks se mappent sur une combinaison de touches et là tu fais ce que tu veux, mais c'est déjà moins automatique.

    • [^] # Re: Python black

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

      Bah déjà, le simple fait de coder en python te résout pas mal de problèmes d'indentation.
      Il y a plein de questions qui ne se posent simplement plus.

      Ensuite, un bon emacs avec elpy, du flake8, etc, et la majorité des autres soucis liés au formatage du code sont bien visibles directement dans ton éditeur-pas-forcément-préféré.
      Sans pour autant te forcer à quoi que ce soit.

      Pour le reste, j'ai pris l'habitude de laisser la virgule à la fin du dernier élément d'une liste, quand il y a un élément par ligne, pour que si on en rajoute un par la suite le diff de code soit uniquement sur la ligne ajoutée, et pas sur la précédente avec ne virgule de plus.
      Ça vient de la lecture de Black cette idée, et je l'ai adoptée très vite.

      Et pour finir, une configuration d'un fichier editorconfig, c'est franchement pas mal, il y a plein d'options très bien, surtout sur un projet où certains collaborateurs bossent sous Windows :
      indent_style = [space|tab]
      indent_size = 4 # si ident_style = space, combien d'espaces
      end_of_line = lf
      charset = utf-8
      trim_trailing_whitespace = true
      insert_final_newline = true

      Et ça se défini très bien par type de fichier, pour par exemple mettre des règles différentes avec le yaml, ou le markdown (trim_trailing_whitespace = false est indispensable par exemple).

      Comme ce fichier peut être inclus directement dans le projet, ça aide beaucoup à avoir une cohérence entre les développeurs, et quel que soit le langage.

      • Yth.
      • [^] # Re: Python black

        Posté par  . Évalué à 4.

        J'ai aussi flake8/pylint qui s'exécutent dans mon éditeur (et chez moi, c'est mieux, c'est vim) et ce depuis longtemps, donc je code propre "naturellement" par habitude. Mais avec black, je m'emmerde même plus à corriger certains trucs parce que je sais que ça se fera tout seul.

    • [^] # Re: Python black

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

      On a eu une dépêche dédiée aux formateurs de code Python ; ça fait un état des lieux de ce qui existe (hors trucs de niche dont peu sont au courant.)

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Celui qui marche

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

    Est-ce que vous avez déjà réfléchi à votre formatage parfais ? Que serait-il ?

    Le formatage parfait c'est celui que toute mon équipe arrive à:

    • Configurer dans l'éditeur, pourque celui-ci sauve le fichier dans le bon format.

    • Configurer dans l'outil de pre-commit et la chaîne d'intégration pour être sûr que le code soit conforme.

    • Configurer dans l'outil de reformatage qu'on utilise pour corriger les non-conformités en masse.

    Après à moins d'avoir des règles complètement farfelues (genre deux lignes vide avant ->) on s'habitue.

    Ce qui augmente la lisibilité mais plus que l'indentation c'est le nommage des variables et la possibilité de définir des fonctions locales.

    L'indentation j'ai toujours trouvé ça très secondaire, il faut juste avoir des règles pas trop malsaines et surtout les moyens de les appliquer sans y consacrer du temps et de l'attention.

    • [^] # Re: Celui qui marche

      Posté par  . Évalué à 3.

      Au boulot on est en java, et on utilise google-java-format. C'est un outil de formatage qui applique les règles google (je ne suis pas chez google). Le truc c'est que cet outil n'est pas configurable. Il applique un formatage et c'est tout, et c'est pas négotiable. Du coup pas de discussion.

  • # y a pas de parfait

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

    Ça va dépendre du langage… Certains imposent un formatage précis (cas des premières versions de : CoBOL, ForTran —77, BASIC —avec numérotation de lignes, etc.) ou ont des recommandations et règles associées (cas de : Go –pour lequel il y a un reformateur, PHP —avec PSR-2, Python –avec PEP-8, etc.) Pour le reste, on peut chipoter mais dans tous les cas les règles utilisées sont discutées et gravées par la communauté du projet (en particulier pour le C et le C++ il y a des styles selon qu'on contribue à un projet GNU/GNOME/BSD/etc.)
    Là où il y a la liberté de choisir (second et troisième cas donc), ça va dépendre des diverses contraintes et des outils (essaye par exemple la tabulation quand tu dois éditer du code depuis un navigateur web et on en reparle) ; et pour chaque choix il y a des avantages et des inconvénients mais jamais une réponse parfaite…

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # De quoi réconcilier (presque) tout le monde

    Posté par  . Évalué à 10. Dernière modification le 30 novembre 2021 à 05:05.

    Une petite image valant mieux qu'un long discours…

    Spaces vs Tabs vs Mix

    Matricule 23415

    • [^] # Re: De quoi réconcilier (presque) tout le monde

      Posté par  . Évalué à 9.

      Perso je "mixe":

      • tabulation en début de ligne
      • espaces pour tout alignement fait après le premier caractère significatif

      Surtout pour du SQL en fait. Un p'tit exemple :

      -- Table Name    Content
      -- invoice       Invoices with an unlimited historical depth
      -- people        Individuals that are expected to pay the invoices
      SELECT p.first_name, p.last_name, sum(i.total_eur)
      FROM
          invoice i
          INNER JOIN people p ON p.uid = i.uid
      WHERE
          i.creation_date >= '20210101'
          AND i.status = 'P'

      Dans ce cas, l'alignement dans le commentaire est fait avec des espaces, ainsi même si le lecteur utilise des tabulations de taille 2, 5 ou 42, ça sera encore aligné. Par contre, le contenu de la clause "FROM" est bien basé sur des tabulations, permettant au lecteur d'avoir le décalage qu'il souhaite, et pas celui que l'auteur préfère.

      Le défaut, c'est que c'est plus compliqué à faire rentrer dans la tête des gens, donc comme beaucoup ici, je m'adapte à ce qui est fait sur un projet sans essayer d'imposer ma vue.

    • [^] # Re: De quoi réconcilier (presque) tout le monde

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

      Le mix n'est pas mauvais, c'est juste que ça demande à comprendre ce qu'on fait, et il y a plein de gens qui ne pigeront pas et pourriront le code donc…

  • # Pas con

    Posté par  (Mastodon) . Évalué à 6. Dernière modification le 30 novembre 2021 à 08:23.

    C'est vrai que le formatage du texte en soi on s'en cogne, c'est le compilo qui va le manger, et commencer par supprimer tous les caractères inutiles. Le formatage est là juste pour la visualisation.

    Du coup, l'idée de ne sauver que le code pur (une version minifiée), et laisser tout un chacun d'afficher de jolies tabulations sur 2 espace ⅓ si ça le chante, oui j'aime bien.

    Un peu comme si la coloration syntaxique faisait partie du texte du code source…

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

    • [^] # Re: Pas con

      Posté par  . Évalué à 2.

      Le truc, c'est que le code serait imbitable au niveau des git diff. Il faudrait que ce soit plutot un truc gere par git qui formatte le code sur 80 ou 90 colonnes selon les maniaqueries des uns et des autres.

      • [^] # Re: Pas con

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

        Encore une fois, c'est l'outil de visualisation (git diff) qui pourrait également faire le travail de te présenter une version lisible.

        Mais ça touche tout l'éco-système de la programmation (les IDE, les outils de gestion de version comme tu dis, même grep devient inutilisable si tu as tout sur une ligne), c'est pas évident…

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

      • [^] # Re: Pas con

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

        Le truc, c'est que le code serait imbitable au niveau des git diff

        Git diff est capable d'ignorer les différences d'espaces.

        • [^] # Re: Pas con

          Posté par  . Évalué à 3.

          Je crois que c'est pas le problème relevé ici. Le git diff serait encore plus efficace sans formatage.

          Mais quand tu fais un git diff depuis la ligne de commande, sur du code "minifié", tu imagines la gueule de l'affichage, et la facilité pour comprendre ce qui s'est passé ? Donc c'est une bonne solution, mais qui implique que tous les outils soient capables de faire le reformatage.

          Donc git diff devrait avoir un formatteur pour tous les langages de la terre, alors que dans l'idéal il devrait s'en foutre. Mais je me demande si git n'a pas déjà ce type de truc, soit en natif, soit sous forme de greffon/paramétrage ?

      • [^] # Re: Pas con

        Posté par  . Évalué à 4.

        code sur 80 ou 90 colonnes selon les maniaqueries des uns et des autres.

        ou comment transformer un problème horizontal en problème vertical!
        On est plus limité à un taille de console, on est plus limité à une taille de 8 caractères, on veut des noms long qui décrivent ce que fait une variable ou une fonction, pas a ou b; le code react devient rapidement illisible sur 80 avec indentation 4

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

        • [^] # Re: Pas con

          Posté par  . Évalué à 4.

          Certains aiment les 80 colonnes, notamment pour afficher 3 buffers en meme temps. Personnellement c'est pas un layout que j'aime mais ca se tient pas trop mal je trouve.

          Apres je vois pas trop en quoi le code react est different des autres, le fait d'avoir des callback definis pour un peu chaque variable peut etre ?

          • [^] # Re: Pas con

            Posté par  . Évalué à 3.

            C'est principalement lié au fait de faire du html, et que pour pas mal de truc 'simple' on se retrouve à devoir avoir plusieurs niveau pour un composant.

            Alors on peut faire une fonction pour la partie interne, mais on transforme un problème vertical à un problème de scroll… Typiquement rien que pour un truc de base on est déjà a plusieurs niveau d'indentation par exemple

            https://codesandbox.io/s/2ju94?file=/demo.js

            c'est un exemple de table pour materialUI, pour avoir ta table tu vas avoir
            1 => composant
            2 => fonction
            3 => table
            4 => tbody
            5 => map sur les ligne
            … et ainsi de suite
            au final on commence colonne 16 avec une indentation de 2; pour une indentation à je te laisse imaginer 4…

            pour peu que tu ajoutes des paramètres tu top très vite la limite à 80;

            Alors oui ils auraient pu faire des fonction intermédiaire; mais on paye le nommage des paramètres, avec des truc qui de base s'imbriquent.

            <BoutonMachin variant={'outlined'} size={'small'} onClick={() => handleBidule()}>
              {intl.formatMessage({id:'labelDuBouton}
            </BoutonMachin>

            rien que pour cet exemple de base on est à 81 caractères sans indentation… le formateur auto, lorsque ça dépasse va te mettre un paramètre par ligne.

            <BoutonMachin 
                        variant={'outlined'} 
                        onClick={() => handleBidule()}
                        size={'small'}
            >
              {intl.formatMessage({id:'labelDuBouton}
            </BoutonMachin

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

    • [^] # Re: Pas con

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

      Il ne faut pas oublier que le code source est écrit et lu et pensé pour les humains…
      Ce que tu proposes ressemble à lire du binaire (coucou od, hexdump, xxd, etc.) ou du désassemblage…

      “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Pas con

        Posté par  (Mastodon) . Évalué à 4. Dernière modification le 30 novembre 2021 à 09:30.

        Non, ce que je propose (enfin, que le journal propose) c'est de ne pas mettre le formatage dans le fichier sauvegardé. Ça ne sert à rien.

        Si je sauve void main(void){printf("Hello world\n");} dans un fichier, ça ne m'empêchera en rien de voir :

        void main(void)
        {
          printf("Hello world\n");
        }

        dans mon éditeur, pendant que toi, avec des préférences différentes tu vois :

        void main(void) {
        
          printf("Hello world\n");
        
        }

        Exactement comme la coloration syntaxique, où chacun a la sienne.

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

        • [^] # Re: Pas con

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

          En gros, ce que tu proposes c'est une feuille de styles à part, tiens ça me rappelle quelque chose :-) Blague à part, il se pourrait que ça soit une solution efficace.

          « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.

          • [^] # Re: Pas con

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

            Exactement. Ensuite toute la difficulté c'est de la mettre en place. Concrètement c'est compliqué.

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

            • [^] # Re: Pas con

              Posté par  . Évalué à 8.

              En fait cela revient à demander à un tas d'outil (éditeur de code, less, diff, etc.) d'arrêter de traiter du texte, mais de comprendre du code.

              • [^] # Re: Pas con

                Posté par  (Mastodon) . Évalué à 3. Dernière modification le 30 novembre 2021 à 11:10.

                Oui en effet… pas une grande idée.

                Pour limiter on pourrait imaginer des outils minify/deminify qui permettraient d'utiliser les outils standard au milieu d'un pipe. Mais bon, tôt ou tard tu serais emmerdé.

                EDIT : ou alors tu fais un vrai truc de Geek, style un UserFS qui déformate/reformate à la volée, les outils n'y voient que du feu.

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

                • [^] # Re: Pas con

                  Posté par  . Évalué à 1.

                  Oui, je pencherais pour un outil dédié qui comprendrais le code et serais capable de le mettre en forme seulement pour affichage et/ou avant traitement pour les outils qui en aurais besoin.

                  Mais j’aurais gardé les retours à la ligne dans les versions minifiées. La majorité des outils (ex: git/diff/patch) ont leur traitement basé sur les lignes.
                  Faire évoluer ça, serais encore une étape supplémentaire, et nécessiterait de nouvelles idées.

              • [^] # Re: Pas con

                Posté par  . Évalué à 1. Dernière modification le 30 novembre 2021 à 16:43.

                d'arrêter de traiter du texte, mais de comprendre du code.

                Surtout de savoir traîter une structure arborescente en fait. Si tu stockes un arbre tu peux stocker n’importe quel AST, comme un fichier JSON ou XML. Tous les langages ou presque ont ces structures.

                Après il y a besoin du minimum de grammaire du langage pour extraire cet arbre, comme on a besoin du minimum du langage pour faire de la coloration syntaxique.

                EDIT: j’avais pas lu le commentaire https://linuxfr.org/nodes/126104/comments/1873875 au dessous qui semble parler d’un tel projet, ça m’apprendra /o\

        • [^] # Re: Pas con

          Posté par  . Évalué à 1.

          j'aime bien l'idée, mais va falloir déterminer les règles pour avoir des diffs significatifs; comme une instruction par ligne par exemple.

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

    • [^] # Re: Pas con

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

      Du coup, l'idée de ne sauver que le code pur (une version minifiée), et laisser tout un chacun d'afficher de jolies tabulations sur 2 espace ⅓ si ça le chante, oui j'aime bien.

      Si c'est vraiment minifié, tu retrouves tout ton fichier sur une seule ligne et du coup.

      Error line 1: bla bla

      Ça devient beaucoup moins simple d'identifier où se trouve l'erreur. Le format texte a ça de bien qu'on peut en faire ce qu'on veut et on peut même faire des dessins avec les caractères. Il est tellement simple que tout logiciel ou tout langage peut le manger tel quel et faire ce qu'il veut avec. C'est sa force. Et donc, supprimer sa force et devoir passer par des outils tiers (complexe) pour modifier ou lire un code source, bof bof comme idée. Actuellement, je peux lire un code source avec more (et oui, ça m'arrive très souvent), si tout est sur une seule ligne, je fais comment ?

  • # EditorConfig

    Posté par  . Évalué à 2.

    Pour définir et suivre les règles de formatage, on peut utiliser https://editorconfig.org.
    Pour corriger, il y a https://eslint.org, la commande go fmt ./…
    Quels autres outils existent ?

    • [^] # Re: EditorConfig

      Posté par  . Évalué à 1.

      j'avais du voir passer des fichier .editorconfig dans des projets, mais sans avoir pris le temps de regarder et sans connaître le site. Je note merci

    • [^] # Re: EditorConfig

      Posté par  . Évalué à 3.

      clang-format que j'ai découvert récemment est un très bon outils, surtout que le choix des règles se fait dans le projet lui même (dans un fichier .clang-format), que je crois que certain IDE en tiennent compte automatiquement s'il est présent (Qt Creator par exemple il me semble).
      De plus, il peut être couplé a Git (avec git-clang-format) pour ne corriger que les lignes concerné par un changement lors d'un commit, pour éviter de modifier dans le même commit les lignes d'un autre dév qui aurait été mal indenté…
      Bref, a tester, mais l’outil me semble prometteur pour du C/C++ en tout cas.

  • # Alignement quand on indente avec des tabulations

    Posté par  . Évalué à 3. Dernière modification le 30 novembre 2021 à 09:25.

    Par exemple l’alignement d’un début de ligne avec un “milieu” d’une autre ligne n’est pas compatible avec le choix de la largeur des tabulations

    C'est possible en faisant l'indentation avec les tabulations et l'alignement avec des espaces, non ? Bon de toute façon même si je le fais de temps en temps je crois que c'est rarement une bonne idée pour un tas de raisons.

    Sinon, sur le formatage parfait… j'ai tendance à préférer le style recommandé par le langage. C'est souvent 4 espaces (Python, Java, Rust…). En Javascript c'est souvent 2 espaces, je trouve ça trop peu pour bien distinguer les blocs et je me retrouve souvent à jouer avec le curseur pour savoir si des blocs sont effectivement alignés, c'est loin d'être idéal. Donc dans mes codes perso, c'est 4 espaces aussi, c'est d'ailleurs plus cohérent avec les autres langages et je me demande si ce n'était pas la norme quand j'ai commencé à faire du Javascript. J'aimais bien 3 espaces à un moment mais quasi personne le fait et ça fait des alignement foireux, par exemple la ligne en dessous du "if (" se retrouve alignée avec la parenthèse ouvrante. Je trouve ça un peu moche. 4 c'est un peu le minimum confortable pour moi, et largement suffisant aussi donc c'est mon optimal. Finalement il y a des raisons objectives derrières mes préférences, mais je comprends qu'elles sont personnelles.

    En théorie je n'ai rien contre l'indentation avec les tabulations, bien au contraire. Pourvu que le code ne se retrouve pas parfois indenté avec des tabulations, parfois avec des espaces. Je crois avoir lu un aveugle qui disait que l'indentation avec tabulations lui simplifiait la vie.

    Globalement ma préférence va à des styles qui réduisent les erreurs de lecture et d'écriture au détriment de la place prise par le code, et c'est ça le plus important pour moi. Je préfère par exemple avoir systématiquement des accolades pour délimiter les blocs même quand elles sont optionnelles, en général. J'ai aussi tendance à passer des lignes vides assez largement dans mon code pour le faire « respirer », mais j'ai conscience que mes choix sont très arbitraires de ce côté là.

  • # Celui par défaut du langage?

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

    https://go.dev/blog/gofmt par exemple ?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Celui par défaut du langage?

      Posté par  . Évalué à 2.

      Pour moi le langage doit décider des règles sur le nombre de tabulations et autres formatage de manière à ce que ça soit le plus homogène possible partout. Avec possibilité simple d'activer ou désactiver des règles si l'on veut

  • # Why text only.

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

    Cette discussion me fait penser à une autre sur r/ProgrammingLanguages (par ailleurs très intéressant) Why text only.

    Un projet qui a pour objectif de définir un nouveau format de fichier pour pouvoir aller plus loin avec les outils, Dion, y est mentionné.

    Côté outillage, sans changer de format, Tree-sitter et son intégration aux éditeurs, notamment de façon native+plugins dans neovim, me semble prometteurs. Il est capable de transformer en arbre syntaxique de nombreux langage de programmation, cet arbre peut ensuite être requêté de façon (plus ou moins) générique par les plugins pour par exemple proposer une vue sur le contenu du buffer aerial.nvim donner l'info dans quel scope on se trouve nvim-gps, et plein d'autres choses encore.

  • # Si y a modo dans le coin...

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

    Quelles seraient les meilleures règles…

    3 fautes dans un titre, ça n'empêche pas de lire la suite mais ça pique les yeux 2/3 s.

  • # format automatique

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

    Peu importe les règles, l'important c'est d'avoir un outil de formatage automatique (ici il est configuré dans gitlab et dans nos scripts de build ("make format") et on ne peut pas merger un changement s'il n'est pas formaté).

    On gagne énormément de temps sur les relectures de code (on peut se concentrer sur le fond puisqu'un robot a déjà pris en charge la forme) et aussi sur l'écriture (puisqu'on peut tout faire n'importe comment et ça sera reformaté à la fin).

    • [^] # Re: format automatique

      Posté par  . Évalué à 2.

      Et c'est génial quand on a ça dès le début du projet. Sur une base de code où sont passés des dizaines de prestataires chacun faisant comme ça lui plaisait il faut faire le choix entre garder l'historique ou unifier tout ça (et c'est super pénible à lire en plus).

      • [^] # Re: format automatique

        Posté par  . Évalué à 2.

        Avec git tu peux réécrire chaque commit de l’historique pour repartir sur une base propre. Mais par contre ça va modifier chaque hash de commit, etc. Donc si tu as des données externe qui référence ses hash, ba tu perds le lien.
        Donc ça peut se faire une fois pour repartir “propre” à un moment clé. Mais c’est pas sans impact.

        • [^] # Re: format automatique

          Posté par  . Évalué à 4.

          Si tu reformatte un vieux commit, bon courage pour le rebase, tu vas avoir un conflit imbitable à chaque commit.

          • [^] # Re: format automatique

            Posté par  . Évalué à 1.

            Euh, justement git à une fonctionnalité qui permet de réécrire l'historique d'un dépôt sans avoir à gérer ce genre de problématique à la main :
            filter-branch
            Bon du coup, à priori maintenant l'outil git-filter-repo est conseillé à la place.

            Mais bien sur, ça va compliquer les choses pour des personnes qui auraient des commits externe au dépôt. Mais c'est pas insurmontable, si c'est fait une fois pour repartir sur des bases plus propre c'est une possibilité qui existe.

            PS: et si c'est juste pour un ancien commit, rebase -i est bien pratique aussi.
            Avec les mêmes problématiques de changement de hash, qui peuvent poser problème dans certain cas, et pas dans d'autres, Si l'on sait ce qu'on fait ça peut-être très pratique.

      • [^] # Re: format automatique

        Posté par  . Évalué à 5.

        $ cat .git-blame-ignore-revs
        # Author: ....
        # Date:   Wed May 22 12:00:14 2019 +0200
        #
        #     Use black as Python code formater
        dfb77a7865b2e746aeb6b172583fa011374d970c
        
        
        
        $ git config blame.ignoreRevsFile .git-blame-ignore-revs
        

        Tu peux en mettre plusieurs dans le fichier (si tu change d'avis sur le soft de formatage par exemple ;))

        La doc : https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt

  • # Elastic tabstops

    Posté par  . Évalué à 4.

    Pour l'aspect alignement, j'aime bien cette idée:
    https://nickgravgaard.com/elastic-tabstops/

    mais malheureusement elle semble être restée un peu confidentielle.

  • # Les tabulations pour l'indentation et les espaces pour l'alignement

    Posté par  . Évalué à 2.

    Ne pas utiliser les tabulations, c'est imposer ses préférences d'aération du code aux autres.
    Les tabulations ne posent pas de problème si elles ne sont utilisées que pour l'indentation.
    Aligner un mot par rapport à un autre mot de la ligne du dessus lorsque que celui-ci n'est pas en début de ligne, ce n'est plus de l'indentation. Il faut alors utiliser un espace constant et donc une suite d'espaces.

    int
    add(int a,
        int b)
    {
    →→return a+b;
    }

    Indent with tabs Align with spaces

Suivre le flux des commentaires

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