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.

[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...

[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).

[codec_abc]

Personnellement je préfère les espaces, mais bon chacun ses préférences. Sinon pour toutes les personnes qui prétendent qu'il faut effacer les espaces 1 par 1 J(et que du coup c'est moins pénible d'utiliser les tabulations) c'est faux. 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

[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.

[SylvainPV]

Sortez les fourches

Tabulations pour indenter, espaces pour aligner, c'est ma paroisse. Ça correspond à l'option "Smart Tabs" dans la plupart des éditeurs. Un argument en faveur des espaces est qu'on a le même résultat visuel chez tout le monde, alors que je plaide justement pour permettre à chacun de lire le code de la façon qui lui plait en configurant sa largeur de tabulation. Ça permet également de mettre fin au second débat chez les whitespaces fans, à savoir combien d'espaces blancs faut-il utiliser par niveau. Le seul fait que ce second débat existe est une preuve qu'il s'agit d'un mauvais choix selon moi.

[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.

[NSKis]

Elle est pas belle la vie?

Quand on pense qu'il y a des mecs qui se lèvent le matin avec pour seul soucis de savoir si les développeurs utilisent le Tab ou plutôt l'espace, on ne peut pas dire qu'il y a de vrais problèmes sur la planète Terre...

[Songbird]

Salut,

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

Je préfère les espaces !

Pourquoi ?

Je trouve les tabulations tout simplement gênantes, quand tu fais des backspace tu reviens 15km en arrière... "Bref, c'est chiant", comme on dit dans le jargon.

(bien entendu ça reste une préférence perso, je ne voue pas un culte aux espaces)

[CoderInTheDark]

Ca me fait penser à un épisode de Silicon Valley
Après va t-on avoir Vim ou Emacs ?
Je préfère VIm et Notepad ++
C'est un sujet à lancer pour avoir une bataille rangé dans l'open space lol

Je préfère les tabulations, car elles sont plus facile à compter sans les yeux.
J'utilise surtout eclipse et son option d'indentation automatique.
Je fais pas trop attention pendant la rédaction, car ça se fait tout seul.
Je fais ctrl maj i de temps en temps et ça suffit

J'ai souffert avec Synfony et son fichier de config avec des espaces

[Darktib]

Je trouve les tabulations tout simplement gênantes, quand tu fais des backspace tu reviens 15km en arrière...

C'est justement un avantage pour moi, quand je veux revenir une indentation en arrière c'est un seul backspace. Au lieu de n appuis si c'était des espaces (sur visual studio, qui ne sait toujours pas gérer ça...).

Un énorme avantage des tabulations, c'est l'impossibilité d'avoir des demi-indentations (ou tout autre genre d'indentations incorrectes).

Sinon, la méthodologie est faussée: si un fichier utilise des tabs pour l'indentation + espaces pour l'alignement, le vote dépendra du caractère le plus utilisé... ce qui peut amener à des faux positifs.
Et sinon, est-ce qu'on sait si les différents forks sont comptés séparément ? Idéalement, seuls les dépôts originaux devraient être comptés.

[Invité]

C'est sûrement qu'ils savent pas ce qu'est la flèche bizarre en haut à gauche.

[Logan Mauzaize]

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é !

De mon point de vue, paramètre1 devrait être sur une nouvelle ligne et donc indenté. C'est le seul moyen d'aligner correctement. Même idée avec les "Fluent API" :

Code Java :

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

1
2
3
4
new StringBuilder()
   .append("...")
   .append(blabla)
;

Et dans ce cas le caractère de "fermeture" (ex: ')', '}', ';') est aligné sur la ligne d'ouverture. Exemples :

Code Java :

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

1
2
3
4
5
6
7
8
9
10
11
avecParenthèse(
   paramètre1,
   paramètre2
)
 
API.start()
   .open()
      .blabla()
      .autre()
   .close()
.end()

Ca me fait penser à un épisode de Silicon Valley

Une vidéo de l'épisode est d'ailleurs incrusté à la fin de l'article original

Un énorme avantage des tabulations, c'est l'impossibilité d'avoir des demi-indentations (ou tout autre genre d'indentations incorrectes).

Un avantage ou un inconvénient ? Certains utilisent justement parfois le concept de demi-indentation lors du découpage d'une expression / instruction sur plusieurs lignes.

Sinon, la méthodologie est faussée: si un fichier utilise des tabs pour l'indentation + espaces pour l'alignement, le vote dépendra du caractère le plus utilisé... ce qui peut amener à des faux positifs.
Et sinon, est-ce qu'on sait si les différents forks sont comptés séparément ? Idéalement, seuls les dépôts originaux devraient être comptés.

D'après moi seul le premier caractère de la ligne détermine l'indentation de la ligne :

Code :

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

SELECT LEFT(SPLIT(content, '\n'), 1) line

Concernant les forks, ils peuvent éventuellement être pris en compte mais les fichiers identiques ne sont comptés qu'une fois et seuls les 400 000 premiers dépôts par leur nombre d'étoiles sont pris en compte. On peut supposer qu'il y a peu de forks parmi ceux-ci.

[Zefling]

Personnellement, je déteste l'identification automatique, parce qu'il n'y a pas moyen de faire de l'adaptatif en fonction du contexte.

J'ai tendance à faire l'indentation de base avec tab, et tout le reste avec des espaces pour m'assurer que si la taille de tabulations change, visuellement ça ne change rien. Quelque exemple pris dans un projet perso :

Exemple 1 : alignement sur le ":"

Code PHP :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
switch ($format) {
	case   1 :
	case 201 :
		$role = [1 => lg('Role_Manga')];
		break;
	case   5 :
		$role = [2 => lg('Role_Manhwa')];
		break;
	case  10 :
		$role = [3 => lg('Role_Manhua')];
		break;
	case  15 :
	case  20 :
	case 300 :
		$role = [4 =>lg('Role_BD')];
		break;
	case  30 :
	case  35 :
		$role = [5 =>lg('Role_Comic')];

Exemple 2 : alignement sur le "=>"

Code PHP :

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

1
2
3
4
5
6
7
8
self::$select_action = [
	self::ACTION_AJOUTE   => lg('Action_Ajouté'),
	self::ACTION_VENDU    => lg('Action_Vendu'),
	self::ACTION_LU       => lg('Action_Lu'),
	self::ACTION_DEDICACE => lg('Action_Dédicacé'),
	self::ACTION_PRETE    => lg('Action_Prêté'),
	self::ACTION_RECUPERE => lg('Action_Récupéré')
];

Exemple 3 : alignement sur les opérateurs

Code PHP :

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

1
2
3
4
5
uasort($fichiers, function($a, $b) {
	return $a['Ordre'] == $b['Ordre'] 
	    ? ($a['Numero'] < $b['Numero'] ? -1 : 1 )
	    : ($a['Ordre']  < $b['Ordre']  ? -1 : 1 );
});

Exemple 4 : alignement sur le "="

Code PHP :

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

1
2
3
$this->select = new Form_SelectBox('recherche', 'News_Recherche_Ajax');
$this->select->page        = 'News/Recherche';
$this->select->placeholder = lg('Rechercher');

Mais je n'ai encore trouvé aucune idée qui le fait bien. Genre sur l'exemple 3, si je fais monter le code d'une tabulation, il me vire les espace avec le ? et : pour mettre des tabulations sur pour l'id le nombre d'espace correspond pour lui à une tabulation.

En tout cas, j'en viens de plus en plus à me demander si je ne vais pas virer les tabulations de tout mon code... c'est pratique et chiant à la fois.

[SylvainPV]

@Zefling: en fait, tous tes problèmes relèvent de l'alignement, pas de l'indentation.

Les IDE avec l'option Smart Tabs sont assez intelligents pour aligner ces variables comme tu le souhaites. Par exemple, pour Webstorm/PHPStorm, voilà les options possibles: