Objectivement, aujourd'hui, les éditeurs de code font le travail. Reformater à 4 ou 8 (ou 5 c'est pas compliqué) espaces, c'est les doigts dans le nez.
Et ça dépend tellement du langage… Je comprends l'argument des tabulations (c'est au choix de l'utilisateur, c'est pratique), mais dans les faits, c'est l'espace qui a gagné.
Reformater a toujours permis de foutre le boxon les doigts dans le nez.
Faut vraiment avoir un formateur codé avec le cul pour que ça arrive. Prendre une source, en extraire l'AST et générer des fichiers avec des règles de formatage souhaiter est une compilation comme une autre. Rien dans ce processus ne devrait avoir la moindre chance de modifier la sémantique du programme.
J'ai dû chercher ce que veut dire AST, alors voila, pour résumer :
Un arbre de la syntaxe abstraite est […] comme la représentation intermédiaire interne d'un programme informatique pendant qu'il est optimisé et à partir duquel la génération de code est effectuée.
Je pense que tout formateur de code n’opère que sur des familles de syntaxe précises et ne touche pas aux autres sources. Je pense aussi qu’il y a peu de chance que la sémantique du programme soit modifiée par ces outils…
Pour donner un exemple de boxon auquel j’ai été confronté, j’ai eu à travailler sur un code Python en ayant utilisé des outils de formatage automatique selon les bonnes pratiques. Sauf, que je le faisais automatiquement avant de faire un commit (du coup, je ne voyais pas que pour avoir juste modifié une ligne tout le fichier a été modifié avec de la mise en forme.) En face, un des fichiers était souvent modifié par un autre dev qui avait une configuration qui indentait avec six espaces (c’était plus lisible pour lui.) Le jour où je suis allé voir sur le Gitlab c’était un bordel sans nom avec ce fichier.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
C'est impossible s'il travaille au niveau de l'AST. Ce n'est pas une probabilité ou comme si ça marche hors des cas complexes.
C'est tout le principe de clang-format, il réutilise les premières pass du compilateur pour avoir la sémantique et ne pas la modifie, (pareil pour go fmt). Black, le formatteur python qui avait beaucoup fait parler, fonctionne aussi comme ça.
Un formatteur qui n'aurait pas ces garanties me ferait plutôt peur et j'éviterais de m'en servir à fortiori sans revu du code qu'il produit.
Pour moi ce que tu décris est un problème d'outil pas très bien fait et pas un problème de processus.
Du coup je vois pae vers quoi il réindente si c'est pas ça.
En gros l'idée est d'avoir un formatage auto avant commit avec une indentation déterminé par le projet (4,8, 42…)
Ce qui fait que chacun travail avec son indentation favorite, mais en gestion de conf c'est le fruit de l'AST formaté avec indentation de 4, on a donc que les modification significatives d'enregistrées.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Bon vu qu'on peut dire ce que l'on veut en étant de mauvaise foi et sans chercher à évaluer les avantages et les inconvénients de chaque choix, juste pour faire une entrée de blog, je propose de n'utiliser ni espace ni tab pour l'indentation : ça économise plein de caractères (et d'octets), c'est encore mieux pour les tablettes braille, les langages qui ont besoin d'espaces ou de tab pour l'indentation sont nuls. Prochaineétapetouslesblancs!
En fait, en étant tout à fait sérieux, je dirais que l'idéal serais effectivement de ne pas avoir d'indentation dans les fichiers de code et que l'indentation devrais se limiter à l'affichage.
Non seulement comme ça plus de bataille entre les adeptes des espaces et ceux des tabulations.
Mais surtout ça ferais des diff plus petit, donc plus facile à lire.
Je ne suis pas sur que l'économie de caractères soit significative surtout avec la compression (dans git ou dans les systèmes de fichier, par exemple), mais je serais curieux de test chiffrés 😉.
Le seul problème que je vois, c'est qu'il y aurait beaucoup d'outils à adapter pour qu'ils mettent en forme le code pour l'afficher à l'utilisateur.
Et un peu d'habitude à faire évoluer.
Beaucoup d'outils de diff sont capables d'ignorer les caractères d'espacement.
Mais par contre ce serait génial que pour les malvoyants (et les autres mais ça me paraît une nécessité pour les malvoyants) qu'ils ne lisent pas des fichiers textes mais des AST. C'est pas complètement trivial car c'est pas un AST complètement fini, mais pas mal d'outils savent déjà faire ce travail pour indiquer des erreurs ou colorer les mots en fonction de leur type
Ce sont les langages colonnés.
Un exemple connu (au moins de ceux qui émargent dans l'info de gestion) est la série GAP (RPG en anglais) d'IBM sur leur série AS/400.
À partir de GAP IV, cependant, ils sont passé en « free format ».
Alors dans les faits, si tu importes/exportes un source RPG, il va se retrouver indenté dans ton éditeur de texte. Mais dans l'éditeur de l'AS/400 , tu passes d'un champs à l'autre.
Peut-être le futur de l'informatique ? ( ->[] )
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
J'ai peut être pas bien compris son problème, mais j'ai configuré mon éditeur avec ce truc, et les niveaux d'indentation apparaissent clairement. A vrai dire, je tape et visualiser des tabs mais sur le fichier c'est des espaces.
Son problème est qu’il veut justement taper et visualiser des tabs.
Mais bon, le réglage marche aussi quand le langage est connu est que l‘on ne fait pas trop de trucs tordus (de sorte que l’éditeur redevine les indentations faites avec des espaces.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Objectif 1992
Posté par jmiven . Évalué à 10.
Vivement l'épisode 3 de la série, "Microkernels are objectively superior to monolithic kernels". :-P
[^] # Re: Objectif 1992
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5.
Et c’est quel épisode "Linux is objectively superior to Windows" ? q-:
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Objectif 1992
Posté par ted (site web personnel) . Évalué à 5.
Il faut attendre la saison 2 avec l'arrivée de Slackware en 93
Un LUG en Lorraine : https://enunclic-cappel.fr
# L'IDE fait le travail
Posté par Glandos . Évalué à 4.
Objectivement, aujourd'hui, les éditeurs de code font le travail. Reformater à 4 ou 8 (ou 5 c'est pas compliqué) espaces, c'est les doigts dans le nez.
Et ça dépend tellement du langage… Je comprends l'argument des tabulations (c'est au choix de l'utilisateur, c'est pratique), mais dans les faits, c'est l'espace qui a gagné.
[^] # Re: L'IDE fait le travail
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Hier aussi les éditeurs de code faisaient le travail. Reformater a toujours permis de foutre le boxon les doigts dans le nez.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: L'IDE fait le travail
Posté par barmic 🦦 . Évalué à 2.
Faut vraiment avoir un formateur codé avec le cul pour que ça arrive. Prendre une source, en extraire l'AST et générer des fichiers avec des règles de formatage souhaiter est une compilation comme une autre. Rien dans ce processus ne devrait avoir la moindre chance de modifier la sémantique du programme.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'IDE fait le travail
Posté par cg . Évalué à 4.
J'ai dû chercher ce que veut dire AST, alors voila, pour résumer :
Un arbre de la syntaxe abstraite est […] comme la représentation intermédiaire interne d'un programme informatique pendant qu'il est optimisé et à partir duquel la génération de code est effectuée.
[^] # Re: L'IDE fait le travail
Posté par barmic 🦦 . Évalué à 3.
Désolé je ne pensais pas que c'était un acronyme à définir dans une discussion sur du code
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'IDE fait le travail
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Je pense que tout formateur de code n’opère que sur des familles de syntaxe précises et ne touche pas aux autres sources. Je pense aussi qu’il y a peu de chance que la sémantique du programme soit modifiée par ces outils…
Pour donner un exemple de boxon auquel j’ai été confronté, j’ai eu à travailler sur un code Python en ayant utilisé des outils de formatage automatique selon les bonnes pratiques. Sauf, que je le faisais automatiquement avant de faire un
commit(du coup, je ne voyais pas que pour avoir juste modifié une ligne tout le fichier a été modifié avec de la mise en forme.) En face, un des fichiers était souvent modifié par un autre dev qui avait une configuration qui indentait avec six espaces (c’était plus lisible pour lui.) Le jour où je suis allé voir sur le Gitlab c’était un bordel sans nom avec ce fichier.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: L'IDE fait le travail
Posté par barmic 🦦 . Évalué à 3.
C'est impossible s'il travaille au niveau de l'AST. Ce n'est pas une probabilité ou comme si ça marche hors des cas complexes.
C'est tout le principe de clang-format, il réutilise les premières pass du compilateur pour avoir la sémantique et ne pas la modifie, (pareil pour go fmt). Black, le formatteur python qui avait beaucoup fait parler, fonctionne aussi comme ça.
Un formatteur qui n'aurait pas ces garanties me ferait plutôt peur et j'éviterais de m'en servir à fortiori sans revu du code qu'il produit.
Pour moi ce que tu décris est un problème d'outil pas très bien fait et pas un problème de processus.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'IDE fait le travail
Posté par fearan . Évalué à 6.
je pense qu'il parle d'un bordel sans nom car aux yeux du diff toutes les lignes changent à chaque fois ;)
Un outils de diff correctement configuré va ignorer les espace sauf que sur du python c'est de la sémantique donc c'est plus chiant.
Par contre l'erreur a été de ne pas avoir un pré-commit hook qui ré-indente le tout au niveau redéfini par le projet ce qui évite ce genre de soucis.
En même temps python a fait un choix de merde sur la gestion des blocs
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: L'IDE fait le travail
Posté par barmic 🦦 . Évalué à 2.
Ah oui je n'avais pas du tout compris ça.
Du coup je vois pae vers quoi il réindente si c'est pas ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: L'IDE fait le travail
Posté par fearan . Évalué à 6.
En gros l'idée est d'avoir un formatage auto avant commit avec une indentation déterminé par le projet (4,8, 42…)
Ce qui fait que chacun travail avec son indentation favorite, mais en gestion de conf c'est le fruit de l'AST formaté avec indentation de 4, on a donc que les modification significatives d'enregistrées.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Nothing is objectively better than spaces and tabs
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Bon vu qu'on peut dire ce que l'on veut en étant de mauvaise foi et sans chercher à évaluer les avantages et les inconvénients de chaque choix, juste pour faire une entrée de blog, je propose de n'utiliser ni espace ni tab pour l'indentation : ça économise plein de caractères (et d'octets), c'est encore mieux pour les tablettes braille, les langages qui ont besoin d'espaces ou de tab pour l'indentation sont nuls. Prochaineétapetouslesblancs!
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Ah la minification js…
Les fans de Python vont te tomber dessus…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par GwenLg . Évalué à 2.
En fait, en étant tout à fait sérieux, je dirais que l'idéal serais effectivement de ne pas avoir d'indentation dans les fichiers de code et que l'indentation devrais se limiter à l'affichage.
Non seulement comme ça plus de bataille entre les adeptes des espaces et ceux des tabulations.
Mais surtout ça ferais des diff plus petit, donc plus facile à lire.
Je ne suis pas sur que l'économie de caractères soit significative surtout avec la compression (dans git ou dans les systèmes de fichier, par exemple), mais je serais curieux de test chiffrés 😉.
Le seul problème que je vois, c'est qu'il y aurait beaucoup d'outils à adapter pour qu'ils mettent en forme le code pour l'afficher à l'utilisateur.
Et un peu d'habitude à faire évoluer.
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par barmic 🦦 . Évalué à 2.
Beaucoup d'outils de diff sont capables d'ignorer les caractères d'espacement.
Mais par contre ce serait génial que pour les malvoyants (et les autres mais ça me paraît une nécessité pour les malvoyants) qu'ils ne lisent pas des fichiers textes mais des AST. C'est pas complètement trivial car c'est pas un AST complètement fini, mais pas mal d'outils savent déjà faire ce travail pour indiquer des erreurs ou colorer les mots en fonction de leur type
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par cg . Évalué à 2.
Oui, mais comment faire si tu es en thème sombre ? Retirer le blanc revient à supprimer certaines lettres.
Alors, tabulations et thème sombre, ou espaces et thème clair ? Slip ou caleçon ?
Au final, le must n'est-il pas de programmer du Whitespace, nu·e et sur un terminal Braille ?
Perso je suis plus tongs-chaussettes pour programmer en Shakespeare, mais chacun fait bien ce qu'il veut.
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par jseb . Évalué à 3.
Ça existe les langages sans espace ou tab.
Ce sont les langages colonnés.
Un exemple connu (au moins de ceux qui émargent dans l'info de gestion) est la série GAP (RPG en anglais) d'IBM sur leur série AS/400.
À partir de GAP IV, cependant, ils sont passé en « free format ».
Alors dans les faits, si tu importes/exportes un source RPG, il va se retrouver indenté dans ton éditeur de texte. Mais dans l'éditeur de l'AS/400 , tu passes d'un champs à l'autre.
Peut-être le futur de l'informatique ? ( ->[] )
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par barmic 🦦 . Évalué à 4.
Ça rend bien plus simple tous les programmes écris en whitespace
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par shbrol . Évalué à 5.
Proposition acceptée… reste la question fondamentale, combien de point-virgules: 4, 8, autre ?
#include <stdio.h>
int main() {
;;;;char* s = "Hello, world";
;;;;printf("%s\n", s);
}
Bien entendu, je --> []
[^] # Re: Nothing is objectively better than spaces and tabs
Posté par Tonton Th (Mastodon) . Évalué à 4.
char* souchar *s?# Les onglets je vois ce que c’est mais …
Posté par Thomas Douillard . Évalué à 3.
Clairement les tabs il y en a dans le navigateurs, mais les "spaces", c’est une nouvelle mode d’interface graphique comme les "google space" ?
[^] # Re: Les onglets je vois ce que c’est mais …
Posté par Benoît Sibaud (site web personnel) . Évalué à 4. Dernière modification le 23 septembre 2023 à 17:05.
Myspace est plus connu que Mytab (y a Mygale aussi).
[^] # Re: Les onglets je vois ce que c’est mais …
Posté par symp . Évalué à 2.
Mycose ?
# highligh indentation
Posté par flagos . Évalué à 2.
J'ai peut être pas bien compris son problème, mais j'ai configuré mon éditeur avec ce truc, et les niveaux d'indentation apparaissent clairement. A vrai dire, je tape et visualiser des tabs mais sur le fichier c'est des espaces.
https://www.emacswiki.org/emacs/HighlightIndentation
Bon ça n'a rien d'extraordinaire, c'est un réglage assez standard.
[^] # Re: highligh indentation
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Son problème est qu’il veut justement taper et visualiser des tabs.
Mais bon, le réglage marche aussi quand le langage est connu est que l‘on ne fait pas trop de trucs tordus (de sorte que l’éditeur redevine les indentations faites avec des espaces.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Sujet de discorde même au sein de couple
Posté par woffer 🐧 . Évalué à 0.
https://duckduckgo.com/?q=silicon+valley+spaces+vs+tabs&t=fpas&iar=videos&iax=videos&ia=videos&iai=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DSsoOG6ZeyUI
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.