Discussion :

[Michael Guilloux]

Espaces vs tabulations : qu’est-ce que les développeurs utilisent pour indenter leurs programmes ?
Une analyse de 400 000 dépôts GitHub

Espace ou tabulation, qu’est-ce que les développeurs utilisent pour indenter leurs programmes ? Voici un vieux débat, mais qui reste encore d’actualité. On peut simplement définir l’indentation comme l'ajout de tabulations ou d'espaces dans un fichier texte. Cette pratique permet entre autres de faire ressortir un bloc de code.

Pour une raison ou une autre ou en fonction des langages de programmation, les développeurs ont une préférence pour les espaces ou pour la tabulation, comme on peut le voir dans ce sondage sur developpez.com datant de l’année 2003.

Plus d’une décennie après ce sondage, on peut se permettre de se reposer la question, surtout après l’analyse faite par un développeur de Google sur un échantillon de 400 000 dépôts de codes hébergés sur GitHub. Cela représente 1 milliard de fichiers et 14 téraoctets de codes.

Ce sont les dépôts les plus importants (sur la base du nombre d’étoiles sur GitHub) sur la période allant de janvier à mai 2016 qui sont analysés. Les fichiers doivent également avoir au moins dix lignes qui commencent par un espace ou une tabulation. Le développeur dénombre ensuite le nombre de fichiers dans lesquels les espaces sont plus utilisés que les tabulations et vice-versa.

Pour ne considérer que les langages les plus importants, il s’est concentré sur les fichiers avec les extensions .java, .h, .js, .c, .php, .html, .cs, .json, .py, .cpp, .xml, .rb,. cc et .go. Les résultats de son analyse montrent que, avec sa méthodologie, les espaces sont largement préférés aux tabulations, sauf pour les fichiers avec les extensions .c (langage C) et .go (langage Go). Les résultats sont donnés par le graphique et le tableau suivants.

Source : Felipe Hoffa

Et vous ?

Que pensez-vous des résultats de l'analyse des dépôts GitHub ?
Qu’est-ce que vous préférez utiliser pour indenter vos programmes ? Pourquoi ?

[bisthebis]

Pour ma part (hobbyiste C++ principalement), ça dépend de mon IDE, mais j'utilise toujours la touche Tab. Mais avec QtCreator, les tabulations sont automatiquement transformées en espaces, et au final c'est pas plus mal. C'est beaucoup plus "portable", et je pense que l'espace devrait être standardisé. Le seul inconvénient dans mon cas, c'est que pour supprimer un degré d'indentation, il faut retirer 4 espaces, mais bon, on s'en remet.
Par contre, à l'échelle d'un vaste projet, je me demande si l'impact des espaces en terme de stockage est perceptible.

[Logan Mauzaize]

C'est beaucoup plus "portable", et je pense que l'espace devrait être standardisé.

Hélàs non c'est la tabulation qui est la plus portable. Tout bon IDE permet de régler la largeur d'affichage d'une tabulation. Ainsi chacun peut régler l'espacement qui lui convient

Par contre, à l'échelle d'un vaste projet, je me demande si l'impact des espaces en terme de stockage est perceptible.

Tous les SCMs compressent leurs données donc ca ne doit pas représenter beaucoup.

Que pensez-vous des résultats de l'analyse des dépôts GitHub ?

Je trouve plusieurs choses remarquables :

• Les fichiers rb et py ont des stats similaires. Peu étonnant quand on sait que bcp de dev Ruby viennent de Python. Ca confirme son statut de "fils spirituel".
• C'est un peu la même idée entre Go et C.
• Je suis tout de même surpris que les fichiers Go soient jamais (ou en tout cas que la quantité soit négligeable) indentés avec des espaces. Quelqu'un aurait des explications ?
• Pour Java la grande majorité des conventions de style préconisent l'espace, il n'y a donc rien de surprenant.

Qu’est-ce que vous préférez utiliser pour indenter vos programmes ? Pourquoi ?

Pour ma part je m'adapte au convention en place. Néanmoins je suis pas très friand de l'indentation >=4 espaces, surtout pour les langages ayant rapidement "beaucoup" de niveaux d'indentations (callback hell/well, inner class, etc.)

[Pyramidev]

De mon côté, je préfère les tabulations pour les raisons suivantes :

• Les développeurs ont des préférences visuelles différentes. Sur les projets sur lesquels je travaille, entre deux niveaux d'indentation successifs, j'aime bien voir un écart qui a la taille de 3 ou 4 espaces. Mais d'autres développeurs préfèrent 2 espaces, d'autres 6 espaces.
  Si un bout de code est indenté correctement avec des tabulations, chacun pourra le lire avec ses propres préférences.
• Les tabulations sont plus faciles à supprimer. Pour supprimer une tabulation, il suffit de taper une seule fois sur une des touches "supprimer" ou "retour arrière". Pour supprimer 4 espaces, il faut taper 4 fois sur une de ces touches, à moins de sélectionner plusieurs espaces pour les supprimer d'un coup.
• Le choix des tabulations est réversible : Si, un jour, on veut remplacer toutes les tabulations par, par exemple, 4 espaces, il suffit de faire un rechercher-remplacer. Le contraire n'est pas possible.
• Les tabulations prennent moins de place en mémoire.

Je reconnais cependant un inconvénient intrinsèque aux tabulations :
Admettons qu'un code indenté avec des tabulations soit maintenu par deux développeurs, dont un qui affiche les tabulations avec une taille de 2 espaces et l'autre avec une taille de 6 espaces.
Le premier aura moins tendance à revenir à la ligne que le deuxième. Du coup, quand le deuxième lira du code écrit par le premier, il aura plus tendance à faire du défilement horizontal avec son éditeur de texte.
Ou alors, il faut que celui qui affiche les tabulations avec une taille de 6 espaces travaille avec un écran plus large.

Il y a un autre inconvénient, que je vis beaucoup au quotidien, mais qui n'est pas intrinsèquement la faute des tabulations :
Beaucoup d'éditeurs de texte ne savent pas gérer correctement les tabulations ! En fait, je n'en ai toujours pas trouvé un qui sait les gérer correctement ! Ou alors, je n'ai pas trouvé les bonnes options.
Je prends un exemple illustratif : admettons que j'ai le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
		uneFonction(parametre1, // avant la fonction  : 2 tabulations
		            parametre2, // avant le paramètre : 2 tabulations puis 12 espaces

Ensuite, je fais un retour à la ligne. Mon curseur se trouve alors juste en dessous du début de "parametre2". C'est bien.
Sauf que, à gauche du curseur, au lieu d'avoir 2 tabulations puis 12 espaces, j'ai, par exemple, 5 tabulations et 0 espace (si j'affiche chaque tabulation avec une taille de 4 espaces) !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
		uneFonction(parametre1, // avant la fonction  : 2 tabulations
		            parametre2, // avant le paramètre : 2 tabulations puis 10 espaces
					parametre3); // avant le paramètre : 5 tabulations puis 0 espace !!!!!

Du coup, quand on affiche le code avec une taille différente pour les tabulations, "parametre2" est toujours affiché sous "parametre1", mais "parametre3" est décalé !

[Jarodd]

[*]Le choix des tabulations est réversible : Si, un jour, on veut remplacer toutes les tabulations par, par exemple, 4 espaces, il suffit de faire un rechercher-remplacer. Le contraire n'est pas possible.

Quel est ton IDE ? Je n'en ai jamais rencontré qui n'arrivait pas à remplacer des espaces en autre chose... Même un simple éditeur de texte sait le faire.

[Pyramidev]

Beaucoup d'éditeurs de texte ne savent pas gérer correctement les tabulations ! En fait, je n'en ai toujours pas trouvé un qui sait les gérer correctement ! Ou alors, je n'ai pas trouvé les bonnes options.
Je prends un exemple illustratif : admettons que j'ai le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
		uneFonction(parametre1, // avant la fonction  : 2 tabulations
		            parametre2, // avant le paramètre : 2 tabulations puis 12 espaces

Ensuite, je fais un retour à la ligne. Mon curseur se trouve alors juste en dessous du début de "parametre2". C'est bien.
Sauf que, à gauche du curseur, au lieu d'avoir 2 tabulations puis 12 espaces, j'ai, par exemple, 5 tabulations et 0 espace (si j'affiche chaque tabulation avec une taille de 4 espaces) !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
		uneFonction(parametre1, // avant la fonction  : 2 tabulations
		            parametre2, // avant le paramètre : 2 tabulations puis 10 espaces
					parametre3); // avant le paramètre : 5 tabulations puis 0 espace !!!!!

Du coup, quand on affiche le code avec une taille différente pour les tabulations, "parametre2" est toujours affiché sous "parametre1", mais "parametre3" est décalé !

De mon point de vue, paramètre1 devrait être sur une nouvelle ligne et donc indenté. C'est le seul moyen d'aligner correctement.

Pyramidev > le problème que tu rencontre est que tu utilise à la fois des tabulations et des espaces pour un même rôle (indenter) et qu'il n'existe pas de paramétrage d'indentation mixte (4 tab + 12 esp) tu doit alors n'utiliser que des tabulation pour résoudre ton problème, ansi tu doit insérer une tabulation devant ton premier paramètre, juste après "("

Quand ma fonction a un nom très long et beaucoup de paramètres, je mets le premier paramètre sur une nouvelle ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
		uneFonctionAvecUnNomLongMaisAlorsVraimentTresLong(
			idUtilisateur,      config,           actionRanger,  chambre,       
			tiroirAChaussettes, paireChaussettes, dureeMaximale, log
		);

C'est dans le but d'éviter de tout concentrer à droite :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
		uneFonctionAvecUnNomLongMaisAlorsVraimentTresLong(idUtilisateur,      config,
		                                                  actionRanger,       chambre,
		                                                  tiroirAChaussettes, paireChaussettes,
		                                                  dureeMaximale,      log);

Par contre, quand ma fonction a un nom court, je préfère éviter de passer à la ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
		uneFonction(idUtilisateur,      config,           actionRanger,  chambre,       
		            tiroirAChaussettes, paireChaussettes, dureeMaximale, log);

Si je mettais le premier paramètre sur une nouvelle ligne, le code ferait plus de lignes sans que je ne le trouve plus lisible :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
		uneFonction(
			idUtilisateur,      config,           actionRanger,  chambre,       
			tiroirAChaussettes, paireChaussettes, dureeMaximale, log
		);

Or, plus un code fait de lignes, plus il y a besoin de faire du défilement vertical.

[Loceka]

Pour Java la grande majorité des conventions de style préconisent l'espace, il n'y a donc rien de surprenant.

Ah bon ?

Pour l'instant je suis toujours tombé sur des projets où le formatteur était réglé sur les tabulations (et heureusement parce que je suis maniaque ^^).

[mlgd]

Je suis tout de même surpris que les fichiers Go soient jamais (ou en tout cas que la quantité soit négligeable) indentés avec des espaces. Quelqu'un aurait des explications ?

Les devs Go utilisent GoFmt pour mettre en forme le code, ce qui permet de standardiser et de faciliter la lecture du code par autrui.
La plupart des IDE pour Go exécutent GoFmt lors de l'enregistrement des fichiers sources et toute l'indentation est alors générée automatiquement avec des TABs.
C'est très pratique pour ne pas perdre de temps sur la mise en forme et j'en viens même à regretter que ça n'existe pas sur les IDE de d'autres langages.

[Logan Mauzaize]

Pour l'instant je suis toujours tombé sur des projets où le formatteur était réglé sur les tabulations (et heureusement parce que je suis maniaque ^^).

Mea Culpa, je pensais que les conventions Eclipse utilisaient l'espace. Néanmoins dans toutes mes expériences c'est toujours l'espace qui a été utilisé comme les recommendations Sun ;-)

Ce n'est donc qu'un point de vue, donc subjectif.
Et l'autre moyen d'aligner correctement, c'est d'utiliser les espaces.

Oui, c'est pour ça que j'ai bien précisé. C'est une solution que j'ai trouvé pour ne pas avoir de cas spécial "indentation". Et puis j'ai toujours trouvé ça plus logique de considérer les premiers arguments au même titre que les suivants, j'aime bien quand c'est plus homogène ^^

Mais les goûts et les couleurs ...

En Go, la plupart des développeurs (presque tous à ma connaissance) utilisent les outils officiels fournis avec le langage pour formater le code. C'est très pratique pour garder la même norme de codage quelque soit les éditeurs / les gens / les habitudes. En gros tu fait ton code puis "go fmt *" et ton code sera normaliser comme il se doit.

Ok merci pour l'info !

le fait d'avoir opté pour les smart tabs n'a eu aucune incidence jusqu'ici

Pour info sous Eclipse, c'est "Mixed"

C'est très pratique pour ne pas perdre de temps sur la mise en forme et j'en viens même à regretter que ça n'existe pas sur les IDE de d'autres langages.

Nul doute que cela existe sous IntelliJ&co, VS, etc. mais sous Eclipse c'est "Save actions".

[TiranusKBX]

Nul doute que cela existe sous IntelliJ&co, VS, etc. mais sous Eclipse c'est "Save actions".

sur IntelliJ par défaut on à des espaces de 4, mais systématiquement je met les tabs ^^

[GilbertLatranche]

Mais avec QtCreator, [...] le seul inconvénient dans mon cas, c'est que pour supprimer un degré d'indentation, il faut retirer 4 espaces, mais bon, on s'en remet.

Options | Éditeur de texte | Comportement | Frappe | Indentation pour retour arrière > Désindente.

Sinon, espaces et puis c'est tout, il n'y a même pas besoin d'argumenter.

[Pyramidev]

A propos de la réindentation automatique :
J'utilise de temps en temps un beautifiler pour refaire l'indentation d'un bout de code indenté n'importe comment, pour éviter de perdre du temps à le réindenter à la main.
C'est très pratique, mais il y a des limitations :
L'indentation automatique produira un code comme celui-ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	bool trucConstruit = construire(truc, optionBidule, "super truc", log);
	bool choseConstruite = construire(chose, optionBidule, "super chose", log);

Mais je préfère un code comme celui-là :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
	bool trucConstruit   = construire(truc,  optionBidule, "super truc",  log);
	bool choseConstruite = construire(chose, optionBidule, "super chose", log);

Même un simple éditeur de texte sait le faire.

De quelle manière ? Parce qu'un simple rechercher 4 espaces >> remplacer par tabulation ne conviendra pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Code intenté avec des tabulations :
// Derrière param2, il y a une tabulation puis 12 espaces.
	uneFonction("    \t    ",
	            param2);

// Après un "chercher tabulation >> remplacer par 4 espaces" :
// Derrière param2, il y a 16 espaces.
    uneFonction("    \t    ",
                param2);

// Après un "chercher 4 espaces >> remplacer par tabulation" :
// Derrière param2, il y a 4 tabulations. En plus, le 1er paramètre a été modifié.
	uneFonction("	\t	",
				param2);

N'importe quel IDE correct désindente le code de la taille d'une tabulation avec Shift+Tab. J'espère que maintenant certaines personnes arrêterons de spammer leur clavier

C'est bon à savoir. Merci du tuyau.

[Uther]

Quel est ton IDE ? Je n'en ai jamais rencontré qui n'arrivait pas à remplacer des espaces en autre chose... Même un simple éditeur de texte sait le faire.

Oui et non. En effet, remplacer 4 espaces en une tabulation, il n'y a rien de plus facile.

Mais comme l'a expliqué Pyramidev, le problème c'est que pour faire un indentation avec les tab propre, il faut différencier indentation et alignement. On ajoute une tabulation quand on rentre dans un nouveau bloc, mais quand on veut juste aligner pour la lisibilité, on utilise des espaces en plus des tabulations liées au niveau d'imbrication. Or si on fait un remplacement sauvage des espaces par des tabulations, on perd cette distinction. Du coup les alignements deviennent faux quand la taille des tabulations change.

[yahiko]

Avec les IDE "modernes" qui formatent le code automatiquement, c'est un peu un débat dépassé je trouve. On peut passer d'une convention à une autre en une fraction de seconde et ça n'impacte pas le versioning, donc bon...

[jmi57]

Avec les IDE "modernes" qui formatent le code automatiquement, c'est un peu un débat dépassé je trouve. On peut passer d'une convention à une autre en une fraction de seconde et ça n'impacte pas le versioning, donc bon...

Quand on travaille sur des vieilles technos, si ça arrive . Même en 2016 !

CVS par exemple considère le même fichier sur 2 branches différentes comme différent si un contient des espaces et un autre des tabulations. Ça arrive souvent vu que certains développeurs activent l'option "remplacer les tabulations par des espaces" (et commitent tout sans vérifier ce qui a été modifié !).

Ca pose de gros problème d'intégration...
On va me dire qu'il existe une option sur CVS de type "ignore white spaces"... Alors oui, on ne verra plus les différences, mais ces fichiers sont quand même considérés comme différent, et il faut les comparer un par un afin de vérifier s'il faut les livrer ou pas... Alors quand on a 130 classes impactées dont 70 uniquement pour des histoires de tabulation, ça énerve !

C'est souvent compliqué lorsque le même projet CVS contient des sources JAVA (avec plein de tabulations) et des sources COBOL (uniquement des espaces) par exemple.

Edit : Dans le monde des Bisounours, on ne devrait pas avoir ce problème :

• le code sera bien formatté/indenté dès le départ
• les développeurs n'oublieraient pas de formatter leur modif
• On met en place un système de norme sur la façon de coder (espace vs tab par ex)
• Tous les IDE du même projet seraient configurés de façon identique
• Les développeurs ne commiteraient pas des fichiers non modifiés
• On ne travaillerait plus avec des vieux trucs style CVS

[hbomb]

De notre coté, on code beaucoup en PHP et on utilise les espaces, vu que ce sont les recommandations pour PHP.
Au moins, comme ça, tout le monde voit le même code (puisqu'en plus on utilise le même IDE).

[ac_wingless]

Pour un hobbyiste ou des professionnels intervenant seuls sur leur code, il n'y a aucun problème avec les tabs, il y a même des avantages (soulignés ici par plusieurs).

En revanche, en environnement professionnel, il est pénalisant d'utiliser autre chose qu'uniquement des espaces (pas de tabs du tout, pas de mix).
En effet, sur un programme d'envergure on n'est jamais seul, ou dans un seul langage, ou dans un seul IDE (ou la même version, cf. les nombreuses différences introduites dans VS2013 puis gardées dans 2015 sur la gestion des tabs par rapport à VS2012 qui avait besoin des Powertools). On est aussi toujours dans un environnement SCM. Cette combinaison fait que de nombreux faux positifs interviennent dans les suivis de gestion. Pour une simple modification locale de 50 lignes on a des nouveaux embauchés qui reformattent le fichier à leur gout (parfois sans le savoir, en utilisant l'IDE), et on se prend à rechercher les 50 parmi les 2000. Au delà des étapes de merge proprement dites, il est courant qu'une historique de fichier dépasse les 1000 états. Si quand on l'examine on est parsemé de faux positifs concernant la tabulation, c'est bien plus difficile à gérer.

Nous le voyons régulièrement à chaque nouvelle embauche, malgré la formation sur nos conventions de codage. Il faut quelques semaines voire mois pour arrêter les faux positifs sur les tabs/espaces. Nous exportons par exemple des paramètres de formattage globaux à la société (fonction bien pratique de VS, qu'on n'a pas dans d'autres IDEs plus frustes).

Ceci est général et concerne aussi les conventions de commentaires. Si quelqu'un s'amuse à reformater ce que quelqu'un d'autre a écrit, on a aussi de faux positifs. Les outils SCM ne sont pas tous cohérents sur le filtrage, et de nombreux cas passent nos filtres (nous utilisons Perforce/Helix).

Un cas récent concerne les lambdas en C++: le formattage par défaut de VS ne gère bien sûr pas tous les cas correctement, avec des indentations aberrantes. Nous ne savons pas encore comment gérer ceci correctement, mais au moins n'avoir que des espaces limite la casse.

[SylvainPV]

@ac_wingless: Il suffit de s'accorder sur une convention de style en début de projet et d'intégrer un style checker dans la phase de build. J'ai toujours utilisé les tabulations en environnement professionnel et ça se passe très bien D'autant que ce problème de faux positifs se pose aussi bien pour les tabulations que pour les espaces d'après tes dires. Bien sûr, si quelqu'un dans l'équipe configure n'importe comment son IDE et désactive le style checker, là on aura toujours un problème mais il sera davantage de nature humaine que technique.

[Logan Mauzaize]

Edit : Dans le monde des Bisounours, on ne devrait pas avoir ce problème :

• le code sera bien formatté/indenté dès le départ
• les développeurs n'oublieraient pas de formatter leur modif
• On met en place un système de norme sur la façon de coder (espace vs tab par ex)
• Tous les IDE du même projet seraient configurés de façon identique
• Les développeurs ne commiteraient pas des fichiers non modifiés
• On ne travaillerait plus avec des vieux trucs style CVS

Je pense que tu as également oublié :

• la convention ne change pas en cours de route
• le formatteur et le checker ont été bien configurés pour être cohérent

Pour le problème humain, à mon avis, c'est surtout lié au manque de "dev leader" / "responsable technique" attitré dans les projets. On pense souvent à placer un "chef de projet" pour fliquer le planning et les dépenses mais moins souvent à la personne qui va fliquer le code et le travail réalisé. Ce n'est pas un rôle très sympas (je sais ce que c'est, je l'ai fait) mais je pense nécessaire pour un projet sur le long terme et si on a une conscience professionnelle.

J'ai toujours travaillé dans un environnement avec des personnes volontaires, et les personnes ayant fait des erreurs ont toujours acceptés de se corriger. Si ce n'est pas le cas, je ne suis pas sûr que ce(s) personne(s) soi(en)t adapté(s) au projet et pour le travail en équipe de manière générale.

[gros_bidule]

Tout à fait.
Il aurait fallu faire un sondage sur ceux qui configurent les options de formatage de leur IDE :p
Et accessoirement combien d'équipes de dev autorisent plusieurs IDE ou en imposent un (souvent pour justement harmoniser le formatage auto, même si certaines règles sont à peu près exportables d'un IDE à l'autre).