Je vois que la guerre de l'indentation n'est pas morte et c'est bien pour ça que Python 3000 ne change rien. Perso, je serai pour interdir les mélanges tabulations / espaces dans le même fichier. Chacun a ses raisons (qu'il trouve très bonne) pour utiliser l'un ou l'autre. Par contre, c'est vraiment le bordel quand on mélange les deux dans le même fichier ! Voir les exemples de Matthieu Moy pour celà.
--
Maintenant pour contribuer au troll, les arguments de Moonz ne sont pas recevables.
> Si tu règle ta tabulation à 2, essayes par exemple
> $ cat ton-fichier.py
> $ a2ps ton-fichier.py
> ...
1. man sed
Ah ouais super... il faut utiliser sed pour contrôler l'effet pervers des tabulations. Super quoi.
2. Le rendu dépend aussi de la police utilisée
C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
À tout hasard, dépasser les 80 colonnes (ce n'est plus que rarement respecté de toutes manières) ?
Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible. Car le mode "wrap" est souvent pénible à utiliser. Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Le propos des tabulations est justement de coder sans se préocupper de la présentation visuelle
C'est bien naïf ça. L'aspect visuel du code apporte des informations sur l'organisation du code. En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define). Voir le concours IOCCC pour voir ce que donne les cas extrêmes. http://www.ioccc.org/
Mais en aparté, c'est tout de même la seule situation ou je m'autorise le mix tab/espaces en Objective-C:
C'est bien là que le bas blaisse. Tu avoues toi même avoir besoin de mélanger espace et tabulation. Or c'est exactement là que les tabulations foutent la merdent car elles perdent tout leur intérêt ! Voir l'expemple ci-dessous :
Alors tu expliques dans tes longs commentaires que les tabulations c'est la solution au problème de mise en forme pour la simple et bonne raison que l'utilisateur peut choisir la largeur des tabulations. Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
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.
Que mon code sera lisible dans tout éditeur sachant gérer les tabulations correctement.
Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN » et c'est là qu'on retrouve les horribles pied de page qui indiquent la configuration vim/emacs.
Mais à part cette situation,
C'est pourtant exactement pour cette situation (pourtant très courante) que les tabulations c'est de la merde en sac.
[^] # Re: Grillay...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Sortie de la version 3.0a1 du langage Python. Évalué à 2.
--
Maintenant pour contribuer au troll, les arguments de Moonz ne sont pas recevables.
> Si tu règle ta tabulation à 2, essayes par exemple
> $ cat ton-fichier.py
> $ a2ps ton-fichier.py
> ...
1. man sed
Ah ouais super... il faut utiliser sed pour contrôler l'effet pervers des tabulations. Super quoi.
2. Le rendu dépend aussi de la police utilisée
C'est hors-sujet ça. Rien à voir avec le conflit espace/tabulation.
> Et au passage, dis-moi comment tu tu rends compte quand ton code dépasse 80 colonnes.
À tout hasard, dépasser les 80 colonnes (ce n'est plus que rarement respecté de toutes manières) ?
Respecter une limitation à 80 caractères est une bonne pratique pour garder un code lisible. Car le mode "wrap" est souvent pénible à utiliser. Et puis, quand on dépasse 80 caractères, c'est parfois que le code pourrait être reformulé plus simplement.
Le propos des tabulations est justement de coder sans se préocupper de la présentation visuelle
C'est bien naïf ça. L'aspect visuel du code apporte des informations sur l'organisation du code. En C, on peut écrire un programme sans aucun retour à la ligne (mis à part les #include et #define). Voir le concours IOCCC pour voir ce que donne les cas extrêmes.
http://www.ioccc.org/
Mais en aparté, c'est tout de même la seule situation ou je m'autorise le mix tab/espaces en Objective-C:
C'est bien là que le bas blaisse. Tu avoues toi même avoir besoin de mélanger espace et tabulation. Or c'est exactement là que les tabulations foutent la merdent car elles perdent tout leur intérêt ! Voir l'expemple ci-dessous :
T[sendSomeLongMessage: arg1
TSSSwithManyArguments: arg2
TSSandAnotherArgument: arg3
TSSSSSSSSmoreArgument: arg4
TSSScontinueArguments: arg5]
Alors tu expliques dans tes longs commentaires que les tabulations c'est la solution au problème de mise en forme pour la simple et bonne raison que l'utilisateur peut choisir la largeur des tabulations. Or tu démontres que tu VEUX que le code soit bien indenté au caractère près et utiliser pour cela des espaces.
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.
Que mon code sera lisible dans tout éditeur sachant gérer les tabulations correctement.
Il fallait lire : « mon code sera lisible dans tout éditeur ÉTANT CONFIGURE EXACTEMENT COMME LE MIEN » et c'est là qu'on retrouve les horribles pied de page qui indiquent la configuration vim/emacs.
Mais à part cette situation,
C'est pourtant exactement pour cette situation (pourtant très courante) que les tabulations c'est de la merde en sac.