Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Michael Guilloux

269PARTAGES

14  1 
Qu’est-ce que vous préférez utiliser pour indenter vos programmes ? Pourquoi ?
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 02/09/2016 à 22:56
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
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
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é !
13  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 03/09/2016 à 14:08
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.

11  1 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 03/09/2016 à 11:57
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...
7  0 
Avatar de CoderInTheDark
Membre chevronné https://www.developpez.com
Le 03/09/2016 à 17:45
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
4  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 05/09/2016 à 14:03
Citation Envoyé par ac_wingless Voir le message
"Il suffit de s'accorder sur une convention de style en début de projet". C'est un peu ce que dit jmi57 dans sa liste. Ta phrase n'existe tout simplement pas dans les programmes un peu gros.
En fait c'est précisément sur les gros projets qu'on s'accorde sur une convention de style, puisque c'est eux qui occasionnent le plus de maintenance et le plus grand nombre de développeurs différents. Pour les petits projets, on est moins regardants et la chaîne d'intégration est plus "légère".

Il y a parfois des débats internes sur telle ou telle règle de style, mais généralement on clôt le débat assez vite sur l'argument que peu importe la convention choisie, le plus important est que tout le monde suive la même.
4  0 
Avatar de oodini
Membre émérite https://www.developpez.com
Le 10/09/2016 à 0:41
Contrairement à ce que déclaraient certains contributeur au début de ce sujet, le débat est semble-t-il loin d'être éculé, et il devrait encore être présent dans 10 ans.
4  0 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 02/09/2016 à 20:52
Citation Envoyé par bisthebis Voir le message
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

Citation Envoyé par bisthebis Voir le message
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.

Citation Envoyé par Michael Guilloux Voir le message
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.


Citation Envoyé par Michael Guilloux Voir le message
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.)
6  3 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 04/09/2016 à 21:32
@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:

3  0 
Avatar de d3v10
Nouveau membre du Club https://www.developpez.com
Le 05/09/2016 à 13:35
Dans un monde parfait, le SCM stockerait le code en brut ou dans un format pré-défini et la conversion se ferait à la volée côté client selon le paramétrage du format défini dans les préférences de l'IDE. Fini les débats sur le formatage, les conventions de style, les comparaisons de code foireuses suite à un reformatage en masse, etc. A chacun ses préférences sans que ça crée d'impact en équipe. On vit encore à l'âge de pierre sur ce sujet-là, les outils doivent évoluer.
3  0 
Avatar de jmi57
Membre régulier https://www.developpez.com
Le 05/09/2016 à 21:26
Citation Envoyé par ac_wingless Voir le message
Je parle de choses très concrètes: un stagiaire/sous traitant/consultant/nouvel embauché installe VS2015, check-out un fichier, fait sa modif, fait son Ctrl-K+D Ctrl-S et submit vers une branche de dev. Son collègue fait une autre modif, et submit en respectant la fameuse "convention de style". Ou bien l'un travaille sur C++ Builder et l'autre sur VS. Ou bien l'un est indiscipliné et n'en a rien à foutre de ce boulot de merde alors que l'autre est tout juste promu et fayote. Dire que ces cas n'arrivent pas est assez utopique (jmi57 parle même de "bisounours", d'autant plus que le nombre de programmeurs est grand, la durée longue (décennies), les langages et outils différents, et le déploiement complexe. Or les conséquences sont définitives (c'est comme la compta: on ne peut plus enlever!) et peuvent "percoler" jusqu'à rendre l'historique des versions inutilisable.
Oui j'aime bien le terme "monde des bisounours". Dans la théorie la MOA fait des docs fonctionnelles toutes propres, les développeurs font du code tout beau et bien commenté, les tests sont réalisés correctement et les chefs de projets encadrent très bien leur équipe et tous les plannings sont respectés... ALors on peut mettre en place tout plein de conventions et documentation en place. Dont les fameuses "convention de styles".

En vrai, la MOA ne sait pas ce qu'elle veut et se contredit, les chefs de projets sont débordés, les développeurs font tout dans l'urgence et ne sont pas toujours très rigoureux, et il y a un réel turn-over au sein de l'équipe (en tout cas sur des projets gérés par des prestataires...) Aors respecter une "convention de style" est loin d'être une priorité sur un projet.
Ca a comme effet de rendre du code illisible et non documenté. Et comme dit ac_wingless l'historique des versions devient inutilisable.
Alors au bout de quelques années, un développement sera beaucoup plus long à faire, et on prendra encore plus de retard...

Bien enendu, il y a les adeptes des outils homogènes.
Je suis tout à fait pour d'ailleurs mettre en place (dans le monde Java) une plate-forme d'intégration continue, et des IDE identiques et configurés de manière identique pour tous les développeurs.
Mais il y a aura toujours un développeur qui aura une config différente soit par choix, soit par mégarde.
Et même au bout de 2 ou 3 ans , il faudra bien mettre à jour les outils. Et là paf, on oublie une config sur la nouvelle version de l'IDE et hop le code change de format...

Ou alors on travaille en mode ultra-sécurisé. Avec des verrous de partout, des relectures de codes ultra-poussés entre collègues, des outils ultraprefectionnés qui ne laissent rien passer... Mais dans ce cas le projet n'avance plus... On commence tellement à réfléchir sur la forme du code qu'on ne réfléchit plus vraiment sur l'algorithme lui-même...
3  0