> Ah ouais super... il faut utiliser sed pour contrôler l'effet pervers des tabulations. Super quoi.
En même temps, il s'agit ici d'un cas spécial vraiment rare. Tu imprimes tous les jours des codes sources toi ? Je vois pas où est le problème d'utiliser sed pour ça, c'est pas comme si c'était une tache quotidienne. D'autant plus que j'aurais tendance à d'abord passer par highlight pour ça, soit dit en passant.
> C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
Le rapport est que même sans tabulations, si tu présentes ton code au caractère près tu risques (fotement) d'avoir des soucis à l'impression. C'est normal. Un code source n'est pas fait pour être imprimé.
> Car le mode "wrap" est souvent pénible à utiliser.
Pourquoi donc ?
> Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible [...] . Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Là, je suis d'accord, mais ça n'a rien à voir avec la choucroute (tu dis que normalement ce problème ne se pose pas vu qu'on ne devrait pas faire une ligne de plus de 80 caractères, "wrap" manuel ou pas. Si le problème se pose as, aucune raison d'en discuter :D)
> En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define)
Oui, enfin, il y a une utilité pratique indéniable aux retours à la ligne: ça marche mieux avec diff et patch, au delà de toute considération esthétique :)
> Prend ton exemple et modifie la taille des tabulations (1, 4, 8, 20 espaces). Tu ne vois rien qui cloche ? L'indentation est brisée.
Ben justement... non, elle reste la même.
Ce qui est un peu le but, quand même. Je suis pas stupide à ce point, si changer la taille des tabulations brisait la présentation, ça ferait longtemps que je n'utiliserais plus les tabulations :p
> Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
C'est un cas VRAIMENT spécial ou ni les espaces ni les tabulations ni le mélange des deux ne brisent la présentation. Le généraliser pour dire "les tabulations, sainul", ça manque un peu de rigueur mathématique ;)
> C'est pourtant exactement pour cette situation (pourtant très courante)
Heu... non, pas courante du tout. C'est la seule fois ou j'ai besoin de mélanger, et comme je l'ai dit, ça passe comme un charme (et oui, j'ai essayé dans différentes configurations)...
> Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN
Mais NON, NON et re-re-NON !!! (j'insiste)
le but est JUSTEMENT que quelle que soit la configuration de l'éditeur, le code source reste autant lisible en s'accordant aux gouts du lecteur ! Le but est justement de ne RIEN imposer comme style (taille de l'indentation, wrap ou pas wrap, wrap en début de ligne ou au même niveau que la ligne précédent ou à un niveau supérieur...). Avec la solution espace, ça passe effectivement partout, mais tu impose ton style au lecteur/contributeur. TOUS mes codes sources passent très bien partout (et je vais me répéter, mais j'ai essayé). Éventuellement, il arrive parfois que la configuration de l'éditeur m'insupporte (genre 8 espaces pour une tabulation, je déteste ça) quand je suis pas chez moi, mais c'est le pire qui puisse arriver.
Toutes, TOUTES les critiques "valides" que j'ai lues concernant les tabulations jusqu'ici proviennent d'éditeurs foireux (genre "oui, mais mon éditeur change les tabulations par 4 espaces en dur et du coup ça pollue les patchs"). Moi aussi je peux faire pareil: j'ai vu certains codes sources indentés à 3 espaces (parce que son auteur aime les espaces) où 8 espaces étaient remplacés par une tabulation (configuration foireuse), ce qui donnait un truc hideux du genre
SSSSSSif(foo)
TSbar();
(d'ailleurs, si mes souvenirs sont bons c'et le cas dans GNUstep - mais pas à 3 espaces - ce qui a été une raison suffisante pour que je m'arrête de plonger dans le code de GNUstep)
conclusion: les espaces, c'est de la merde en sac, si l'auteur avait utilisé des tabulations dès le début ça aurait fait chier personne
Mais comme j'aime pas être de mauvaise foi, je n'utiliserai pas ça comme un argument :p
[^] # Re: Grillay...
Posté par Moonz . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 3.
En même temps, il s'agit ici d'un cas spécial vraiment rare. Tu imprimes tous les jours des codes sources toi ? Je vois pas où est le problème d'utiliser sed pour ça, c'est pas comme si c'était une tache quotidienne. D'autant plus que j'aurais tendance à d'abord passer par highlight pour ça, soit dit en passant.
> C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
Le rapport est que même sans tabulations, si tu présentes ton code au caractère près tu risques (fotement) d'avoir des soucis à l'impression. C'est normal. Un code source n'est pas fait pour être imprimé.
> Car le mode "wrap" est souvent pénible à utiliser.
Pourquoi donc ?
> Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible [...] . Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Là, je suis d'accord, mais ça n'a rien à voir avec la choucroute (tu dis que normalement ce problème ne se pose pas vu qu'on ne devrait pas faire une ligne de plus de 80 caractères, "wrap" manuel ou pas. Si le problème se pose as, aucune raison d'en discuter :D)
> En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define)
Oui, enfin, il y a une utilité pratique indéniable aux retours à la ligne: ça marche mieux avec diff et patch, au delà de toute considération esthétique :)
> Prend ton exemple et modifie la taille des tabulations (1, 4, 8, 20 espaces). Tu ne vois rien qui cloche ? L'indentation est brisée.
Ben justement... non, elle reste la même.
Ce qui est un peu le but, quand même. Je suis pas stupide à ce point, si changer la taille des tabulations brisait la présentation, ça ferait longtemps que je n'utiliserais plus les tabulations :p
> Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
C'est un cas VRAIMENT spécial ou ni les espaces ni les tabulations ni le mélange des deux ne brisent la présentation. Le généraliser pour dire "les tabulations, sainul", ça manque un peu de rigueur mathématique ;)
> C'est pourtant exactement pour cette situation (pourtant très courante)
Heu... non, pas courante du tout. C'est la seule fois ou j'ai besoin de mélanger, et comme je l'ai dit, ça passe comme un charme (et oui, j'ai essayé dans différentes configurations)...
> Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN
Mais NON, NON et re-re-NON !!! (j'insiste)
le but est JUSTEMENT que quelle que soit la configuration de l'éditeur, le code source reste autant lisible en s'accordant aux gouts du lecteur ! Le but est justement de ne RIEN imposer comme style (taille de l'indentation, wrap ou pas wrap, wrap en début de ligne ou au même niveau que la ligne précédent ou à un niveau supérieur...). Avec la solution espace, ça passe effectivement partout, mais tu impose ton style au lecteur/contributeur. TOUS mes codes sources passent très bien partout (et je vais me répéter, mais j'ai essayé). Éventuellement, il arrive parfois que la configuration de l'éditeur m'insupporte (genre 8 espaces pour une tabulation, je déteste ça) quand je suis pas chez moi, mais c'est le pire qui puisse arriver.
Toutes, TOUTES les critiques "valides" que j'ai lues concernant les tabulations jusqu'ici proviennent d'éditeurs foireux (genre "oui, mais mon éditeur change les tabulations par 4 espaces en dur et du coup ça pollue les patchs"). Moi aussi je peux faire pareil: j'ai vu certains codes sources indentés à 3 espaces (parce que son auteur aime les espaces) où 8 espaces étaient remplacés par une tabulation (configuration foireuse), ce qui donnait un truc hideux du genre
SSSSSSif(foo)
TSbar();
(d'ailleurs, si mes souvenirs sont bons c'et le cas dans GNUstep - mais pas à 3 espaces - ce qui a été une raison suffisante pour que je m'arrête de plonger dans le code de GNUstep)
conclusion: les espaces, c'est de la merde en sac, si l'auteur avait utilisé des tabulations dès le début ça aurait fait chier personne
Mais comme j'aime pas être de mauvaise foi, je n'utiliserai pas ça comme un argument :p