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

Posté par xoddark le 29 novembre 2021 à 23:35. Licence CC By‑SA.

Étiquettes :

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 rycks le 29 novembre 2021 à 23:43. É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 xoddark le 30 novembre 2021 à 00:09. É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 jihele le 29 novembre 2021 à 23:43. É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 xoddark le 30 novembre 2021 à 00:04. É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 pulkomandy (site web personnel, Mastodon) le 30 novembre 2021 à 15:27. É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 liberforce (site web personnel) le 01 décembre 2021 à 15:42. Évalué à 3.
    
    Idem, chez moi (sous Vim) ça reformate quand je sauve le fichier.
    - [^] # Re: Python black
      
      Posté par jihele le 02 décembre 2021 à 10:01. Évalué à 3.
      
      Bonne idée, j'ai pas pensé à le faire à l'enregistrement, mais c'est encore mieux.
      - [^] # Re: Python black
        
        Posté par liberforce (site web personnel) le 02 décembre 2021 à 10:28. É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 jihele le 02 décembre 2021 à 14:23. É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 liberforce (site web personnel) le 02 décembre 2021 à 16:28. É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 Yth (Mastodon) le 30 novembre 2021 à 07:52. É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 jihele le 30 novembre 2021 à 17:43. É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 Gil Cot ✔ (site web personnel, Mastodon) le 30 novembre 2021 à 08:03. É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 Michaël (site web personnel) le 30 novembre 2021 à 00:39. É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 jigso le 04 décembre 2021 à 08:46. É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 Gil Cot ✔ (site web personnel, Mastodon) le 30 novembre 2021 à 02:07. É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 _kaos_ le 30 novembre 2021 à 05:04. Évalué à 10. Dernière modification le 30 novembre 2021 à 05:05.

Une petite image valant mieux qu'un long discours…

Matricule 23415
- [^] # Re: De quoi réconcilier (presque) tout le monde
  
  Posté par Dring le 30 novembre 2021 à 09:48. É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 liberforce (site web personnel) le 01 décembre 2021 à 15:44. É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 gUI (Mastodon) le 30 novembre 2021 à 08:20. É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 flagos le 30 novembre 2021 à 09:00. É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 gUI (Mastodon) le 30 novembre 2021 à 09:10. É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 Michaël (site web personnel) le 30 novembre 2021 à 09:20. É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 Dring le 30 novembre 2021 à 09:54. É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 flagos le 30 novembre 2021 à 10:40. Évalué à 1.
        
        Tu as ca:
        
        https://www.git-scm.com/docs/gitattributes#_generating_diff_text
        
        Apres comme dit ailleurs, le formatting est aussi la pour éviter d'avoir des conflits dans git (le coup de mettre une virgule même au dernier élément d'une liste ou de sorter les imports).
  - [^] # Re: Pas con
    
    Posté par fearan le 30 novembre 2021 à 09:26. É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 flagos le 30 novembre 2021 à 10:48. É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 fearan le 30 novembre 2021 à 13:24. É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 Gil Cot ✔ (site web personnel, Mastodon) le 30 novembre 2021 à 09:20. É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 gUI (Mastodon) le 30 novembre 2021 à 09:28. É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 Ysabeau 🧶 (site web personnel, Mastodon) le 30 novembre 2021 à 09:31. É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 gUI (Mastodon) le 30 novembre 2021 à 09:34. É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 alkino le 30 novembre 2021 à 10:33. É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 gUI (Mastodon) le 30 novembre 2021 à 11:08. É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 xoddark le 30 novembre 2021 à 14:05. É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 Thomas Douillard le 30 novembre 2021 à 16:42. É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 fearan le 30 novembre 2021 à 10:16. É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 rewind (Mastodon) le 30 novembre 2021 à 15:15. É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 Grobide le 30 novembre 2021 à 08:54. É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 xoddark le 30 novembre 2021 à 13:04. É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 Fabien PRORIOL le 30 novembre 2021 à 15:42. É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 raphj le 30 novembre 2021 à 09:23. É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 devnewton 🍺 (site web personnel) le 30 novembre 2021 à 09:41. É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 ff9097 le 30 novembre 2021 à 09:56. É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 Benoît Laurent (site web personnel) le 30 novembre 2021 à 12:13. É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 Francois G. (site web personnel) le 30 novembre 2021 à 12:19. É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.
- [^] # Re: Si y a modo dans le coin...
  
  Posté par xoddark le 30 novembre 2021 à 13:01. Évalué à 1.
  
  Oups, désolé, effectivement si quelqu’un peut corriger.
  
  Merci
  - [^] # Re: Si y a modo dans le coin...
    
    Posté par Ysabeau 🧶 (site web personnel, Mastodon) le 30 novembre 2021 à 13:03. Évalué à 4.
    
    C'est fait.
    
    « Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# format automatique

Posté par pulkomandy (site web personnel, Mastodon) le 30 novembre 2021 à 14:02. É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 Lutin le 30 novembre 2021 à 15:50. É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 xoddark le 30 novembre 2021 à 16:56. É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 jihele le 02 décembre 2021 à 14:27. É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 xoddark le 08 décembre 2021 à 11:26. É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 ondex2 le 30 novembre 2021 à 17:29. É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
    - [^] # Re: format automatique
      
      Posté par Lutin le 30 novembre 2021 à 17:50. Évalué à 3.
      
      Intéressant ça, merci.
# Elastic tabstops

Posté par wismerhill le 30 novembre 2021 à 18:21. É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 Romuald Delavergne le 05 décembre 2021 à 12:59. É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
- [^] # Re: Les tabulations pour l'indentation et les espaces pour l'alignement
  
  Posté par Colin Pitrat (site web personnel) le 15 décembre 2021 à 14:10. Évalué à 2.
  
  Les tabulations ont un inconvenient si on impose des limites en nombre de caractères par ligne, ce qui est utile entre autre pour certains outils de revue de code.
  
  Je sais c'est pas énorme, mais c'est le seul inconvénient que je connais aux tabs.

Suivre le flux des commentaires

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