Tabs vs Spaces : la guerre sainte que personne ne gagnera jamais (mais tout le monde a raison, sauf ceux qui ont tort)
Bienvenue dans le monde merveilleux du développement logiciel, où l’on bâtit des systèmes complexes, on manipule des milliards de données… et on se crie dessus à cause d’un caractère invisible.

Oui, mesdames et messieurs, je vous parle du conflit ancestral, plus clivant que chocolatine vs pain au chocolat, plus toxique que la section commentaires d’un article politique : les tabs contre les spaces.
Les Tabs : parce qu’un caractère = un caractère
Les partisans du tab sont de nobles chevaliers de la performance. Leur crédo : un caractère pour l’indentation, c’est suffisant. Pourquoi utiliser 4 espaces quand une touche fait le job ?
Ils parlent optimisation, accessibilité, personnalisation. Ils vivent dans des mondes où chaque octet compte et où on configure son éditeur comme un avion de chasse.
"Avec un tab, chacun choisit la largeur qu’il préfère. C’est l’indentation DÉMOCRATIQUE." — Jean-Kévin, 34 ans, code depuis 1998, ne parle plus à sa famille depuis qu’ils utilisent VSCode.
Les Spaces : parce que le chaos doit être aligné parfaitement
Les évangélistes de l’espace (non, pas la NASA) ont un autre dieu : la consistance visuelle absolue. Ce sont les artisans du pixel-perfect, les ayatollahs du linter.
Pour eux, les tabs sont le diable déguisé en caractère d’échappement. Trop de variables, trop de surprises, pas de place pour l’imprévu dans un commit sacré.
"Un tab peut être interprété de 2 à 8 caractères ? Non merci. Chez moi, l’indentation est aussi fixe qu’un backend en COBOL." — Bernard, 29 ans, fan de Python et de pain au levain, a mis son IDE en mode dictature.
Et si on utilisait les deux ?
Ha. Ha. Ha. NON.
Utiliser tabs et spaces dans le même fichier, c’est comme mélanger du lait avec du jus d’orange : techniquement possible, mais moralement inacceptable. Tu vas créer des conflits de merge, des bugs d’indentation, et probablement une alerte de la CIA.
Le vrai problème ? Personne ne voit ce qu’on écrit
Parce que oui : toute cette guerre repose sur des trucs qu’on NE VOIT PAS. Et pourtant, on se bat à mort sur GitHub, Stack Overflow, et dans les toilettes des meetups. On écrit des règles dans .editorconfig
, on installe des pre-commit hooks, on débat dans les code reviews.
Pendant ce temps, ton script ne compile toujours pas. Mais bon, au moins il est indenté selon les standards de ta secte.
Mais alors, qui a gagné ?
Personne. Tout le monde. On ne sait pas. En fait, si on vous pose la question, la seule vraie bonne réponse, c’est :
"Demande à Go."
Parce que Go, ce langage conçu par des gens fatigués de voir le monde brûler à cause d’un tab mal placé, a tranché. Fini les débats, les configs .editorconfig
, les guerres de PR où l’indentation occupe 98 % du diff. Go a gofmt
.
Tu veux coder en Go ? Tu sauvegardes ton fichier, il est automatiquement formaté. Avec des tabs. Pas de négociation.
Tu préfères les espaces ? Tant pis. Go s’en fiche. C’est lui le patron.
"Tabs. C’est tout. Circulez. Y’a pas de débat ici." – gofmt, probablement.
Et devinez quoi ? ça marche. Les développeurs Go ne s’insultent pas sur Reddit à propos de l’indentation. Ils font des outils, des API performantes, des microservices trop petits pour échouer. Bref, ils codent.
Si tu veux la paix, choisis Go. Sinon, continue de te battre. L’important, c’est de ne jamais rien régler, mais de savoir pourquoi ton indentation est supérieure à celle du voisin.
Et rappelle-toi : peu importe ce que tu choisis…
Ton collègue a une règle Prettier différente.
A votre avis, je préfère les Tabs ou les Spaces ?