Tabulations vs. espaces

Euh ben si, avec des espaces tu dois configurer ton éditeur pour qu'il remplace une tabulation par 2/4/8 espaces. :troll:

Et malgré ton WTF sur Code::Blocks, tu peux utiliser plusieurs profils de formattage de code dans cet IDE, donc le "j'ai juste autre chose à foutre que perdre du temps a changer de config pour un oui ou pour un non" se règle par un simple clic.

Après les autres IDE je sais pas, mais dans Code::Blocks ça nous a pris allez, 2 minutes pour le config correctement après une installation toute fraîche. Et pour vim c'est juste une ou deux lignes de config dans le .vimrc.

Je rejoint talus sur ce point. Effectivement c'est pas compliqué de switcher. Mais quand tu travail sur plusieurs projets en parallèle, parfois édité en même temps, ça devient pénible de tout configurer systématiquement à chaque fois. Et encore une fois, le gros problème des tabulations avec espace c'est qu'il faut que tout le monde ai tout de bien configurer. Perso ça ne me générai pas sur un projet ou je suis seul. À partir du moment où d'autres personnes interviennent c'est la galère assuré. À un moment donné il y aura forcément une édition mal configuré et ça va tout bousiller.

Ça reste que mon avis. Le mixte est théoriquement le mieux mais en pratique sur du dev à plusieurs c'est vite galère

Si personne n'indente les sources sur le repo(tout est ramené à la colonne zéro) et chaque dev indente comme il le souhaite en local. Avec 2 hooks, c'est plié et tout le monde est content.

Effectivement, si un mec dans une équipe configure mal son éditeur, ça fait tout foirer. Mais c'est la faute à qui ? Au mec qui a mal configuré son éditeur ou au mec qui a décidé d'utiliser un mix tab/espace ?

Ce que je veux dire par là, c'est que oui je suis entièrement d'accord avec toi Kje, mais c'est pas une raison de ne pas utiliser un mix tab/espace. Selon moi, c'est au mec qui a foutu le bordel de voir et corriger son erreur, pas aux autres de s'adapter à une taille d'indentation prédéfinie. Surtout qu'un truc de ce genre, avec un système de versionning ça se repère et se règle plutôt facilement.

Sinon pour le problème d'éditer plusieurs fichiers en parallèle, plusieurs instances de ton IDE ça marche pas ? Enfin à condition qu'elles ne partagent pas la config, je sais pas si c'est possible ça par contre, je sais qu'avec vim ça l'est, par contre avec d'autres éditeurs/IDE je n'en ai aucune idée. Mais de toute manière c'est un problème qui existera tant qu'il y aura plusieurs manières d'indenter, donc ça risque pas de changer de sitôt. :')

Je crois qu'Eclipse gère ses configs en fonction du workspace.

@gnidmoo : Non mais je suis totalement d'accord que c'est le mec qui a mal configuré son éditeur qui est en tord. Toujours est il que ça fout la merde. Si les autres devs ont déjà récupérer le dépot pendant ce temps, et si il n'est pas trop tard, il vont avoir le choix entre attendre que le mec corrige et continuer au risque de se payer des conflits aux merges.

Qu'on se comprenne bien, je comprend votre point de vue. Je fais juste le constat de ce que je vois dans ma boite en particulier. Toutes les équipes où la question se pose (ie toute sauf la mienne car nous on fait très majoritairement du Python), ils ont imposés de l'espace seulement pour ne pas perdre de temps là dessus et éviter des soucis.

Après y'a une solution pour éviter ça, c'est d'afficher les espaces et les tabs, comme ça même avec un éditeur mal configuré tu vois tout de suite qu'il y a un souci. Mais je comprends bien que dans la plupart des boîtes ils imposent les espaces pour éviter des soucis, j'ai envie de dire que c'est normal d'ailleurs.

Mais du coup en dehors de ce genre de cadre, utiliser tabs+espaces c'est le top ! :troll:

Après y'a une solution pour éviter ça, c'est d'afficher les espaces et les tabs, comme ça même avec un éditeur mal configuré tu vois tout de suite qu'il y a un souci.

Tout a fait, je les affiche systématiquement. Mais tu conviendra que si le dev a mal configuré son IDE pour la gestion des tabulations, il est peu probable qu'il ai coché la case d'affichage des caractères blanc.

Bonjour,

ON dirait que ja'rrive un peu après la guerre, mais j'ai quand même deux questions.

1 - Pourquoi par exemple pour python, le standard dicte les espaces plutôt que les tabs ? Il y a une explication rationnelle derrière ce choix ou bien c'est juste les préférences du concepteur du langage ?

2 - ON comprend bien que chacun a ses préférences personnelles en terme de présentation. Pourquoi alors les utilitaires de reformatage automatique comme par exemple astyle, ou la fonction qui va bien dans eclipse, ne sont pas plus souvent utilisées ? Avec des scripts qui s'exécuteraient à l'ouverture et l'enregistrement dans son éditeur préféré, ou alternativement après pull et avant push, chacun aurait le code formaté comme il le souhaite sans gêner personne d'autre. Aucun risque de mettre le boxon puisque l'indentation et les espaces n'ont en soi aucune valeur sémantique dans le code. Fin de tous les trolls.

D'accord, ma réflexion ne marche pas pour python; mais les autres langages qui ont tous du { } ou du begin/end ? Pourquoi ?

1 - Pourquoi par exemple pour python, le standard dicte les espaces plutôt que les tabs ? Il y a une explication rationnelle derrière ce choix ou bien c'est juste les préférences du concepteur du langage ?

Le PEP-8 donne un élément de réponse :

The most popular way of indenting Python is with spaces only.

C'est donc plus parce que la majorité des dev préfèrent ça. Il faut aussi bien penser que les points qu'on a put citer au dessus sont encore plus problématique en Python. Dans la majorité des langages, un code qui mixe mal les deux rend le code moche. En python ça génère des erreurs de syntaxes. Il est donc primordiale en python de s'y tenir rigoureusement. Or comme dit avant, le mix est beaucoup plus sujet aux erreurs que l'espace seulement.

2 - ON comprend bien que chacun a ses préférences personnelles en terme de présentation. Pourquoi alors les utilitaires de reformatage automatique comme par exemple astyle, ou la fonction qui va bien dans eclipse, ne sont pas plus souvent utilisées ? Avec des scripts qui s'exécuteraient à l'ouverture et l'enregistrement dans son éditeur préféré, ou alternativement après pull et avant push, chacun aurait le code formaté comme il le souhaite sans gêner personne d'autre. Aucun risque de mettre le boxon puisque l'indentation et les espaces n'ont en soi aucune valeur sémantique dans le code. Fin de tous les trolls.

Certains dev le font. Le soucis est généralement qu'un outil automatique peut forcément faire des erreurs parfois et qu'une écriture a la main est parfois plus facile.

Apres je ne fais que du python où il existe aussi ce genre d'outils. Mais quand on prend l'habitude, comme moi, de se conforter à une coding style (pep8 me concernant) on va au final directement écrire du code qui respecte le standard. Donc pas besoin de faire passer un outils derrière

A noter également que http://caml.inria.fr/resources/doc/guides/guidelines.fr.html préconise aussi l'espace pour indenter.

Utilisation des taquets de tabulation On décourage absolument l'utilisation du caractère de tabulation (caractère ASCII 9).

Pour ma part, depuis PSR-2, j'utilise les espaces, avec un éditeur configuré pour remplacer les tabulations à la frappe, parce que je les utilise encore quand je code du HTML ou du CSS notamment. Pourquoi encore des tabulations pour ces langages ? me demandera-t-on. Pour moi, c'est une relative question de cohérence : si on minimise le JavaScript pour gagner en temps de chargement et d'analyse, pourquoi ne le ferait-on pas pour du HTML qui, lui, est très rarement minimisé ? Et il me paraît clair qu'avoir un seul caractère là où d'autres langages préconisent d'en mettre plusieurs est une forme d'allègement.
Du coup, si je travaille sur un projet où je sais que minimiser le JavaScript n'apportera pas énormément, j'utilise aussi les tabulations.

Un argument que je rencontre fréquemment : on peut paramétrer son éditeur pour qu'il remplace les tabulations par des espaces. Oui, mais ces mêmes éditeurs permettent aussi de régler la largeur des tabulations.

Autre argument que je vois souvent pour l'utilisation des espaces, c'est « on peut ainsi en mettre moins certaines fois pour des niveaux intermédiaires ». Force m'est de constater qu'en tout cas en PHP, ces niveaux intermédiaires ne sont pas (encore ?) utilisés, et ne font pas (encore¹ ?) partie d'un PSR-X.

Si quelqu'un pouvait me montrer un exemple l'utilisation d'indentation "fine", que cet exemple soit dans un langage relativement courant, et que l'exemple suive aussi une norme, j'apprécierais.

LE HTML c'est même mieux que ça, en général il n'est pas indenté du tout et même tout est sur la même ligne.

En même temps je ne vois pas trop l'intérêt de le faire quand on le génère via php ou autre langage. IL n'a pas pour objectif d'être édité ou lu par quelqu'un d'autre.

Dans mes templates, j'indente quand-même le HTML et même les instructions PHP (ou autre langage dynamique) qui s'y trouvent, donc automatiquement, le résultat possède une indentation. Après, c'est certain que c'est plus pour un confort visuel de développement, et que de toute manière, les navigateurs corrigent eux-même l'indentation quand on utilise leurs outils de développement, donc c'est juste une habitude qui, incidemment, ne sert pas à grand-chose dans les langages "purement web" (JS, CSS, HTML).

Ce que je veux dire en fait, c'est que si on ne minimise pas le HTML pour le faire tenir sur une ligne, ce qui serait effectivement possible tant qu'on fait suffisamment attention aux types de balises, alors j'estime que c'est à moi de faire au mieux.
Par rapport au type de balise, j'entends principalement les deux types inline et block, liées donc à leur manière d'être affichées. Mais le problème est que cet affichage peut être inféré par du CSS, et du coup, je pense que ça peut poser problème.

En principe les parseurs HTML et/ou XML sont censé ignorer les espaces et les tabs en début de ligne. Ils ne le font pas toujours, pour s'en rendre compte il suffit d'observer les différences entre le DOM généré par firefox et celui généré par IE pour une même page: IE ignore les espaces, pas firefox, qui insère des noeuds texte remplis d'espaces et/ou tabs uniquement et c'est complètement inutiles.

Mais ça pose rarement problème à l'affichage. IL y a toutefois des cas connus où ça pose effectivement problème, notamment dans l'enchaînement de plusieurs éléments inline où tout à coup on constate des espaces parasites. Tout le monde est déjà tombé au moins une fois sur un espace gênant de quelqeus pixels qui ne voulait pas partir…

J'utilise des tabulations quand on ne me donne pas l'ordre inverse (e.g. dans les guidelines du projet en question).

Pour la bonne et simple raison que je préfère des tabs "larges" pour y voir plus clair, alors que beaucoup de gens préfèrent une taille équivalente à 2 ou 3 espaces.

Comme c'est configurable dans tous les éditeurs de la planète, ça ne pose pas de soucis, et on ne se tape pas de diffs monstrueux (et impossibles à review) parce que toutes les lignes ont été reformatées de 3 à 2 espaces par Jacques ou Paul.

Après, en effet, certains (beaucoup) de projets imposent d'utiliser N espaces. Dans ces cas là ça m'ennuie, puisque la plupart du temps je dois switcher de config. Mais de toute façon, à partir du moment où ils imposent autre chose que des tabs, c'est généralement 2 ou 3 espaces, si j'utilisais les espaces j'en mettrais certainement 4, donc je serais tout autant obligé de changer de configuration…