Onglets contre espaces - quel est le caractère d'indentation approprié pour tout, dans chaque situation, jamais?
Les normes de codage pour le code hébergé dans drupal.org suggèrent d'utiliser deux espaces pour indenter le code; d'autres sites suggèrent d'utiliser des onglets pour indenter le code.
Quel est le caractère d'indentation approprié pour tout et dans toutes les situations? Veuillez expliquer la réponse que vous donnez.
Espaces
Un onglet peut être un nombre différent de colonnes selon votre environnement, mais un espace est toujours une colonne.
En termes de nombre d'espaces (ou de tabulations) constituant une indentation, il est plus important d'être cohérent tout au long de votre code que d'utiliser une valeur de tabulation spécifique.
onglets
Maintenant, bien sûr, la cohérence importe plus que l'un et l'autre et un bon IDE rend les différences négligeables. Cela dit, le but de ce fil est d'être une guerre sainte, donc:
Je préfère les onglets:
- Ils sont un personnage spécifiquement destiné à l'indentation
- Ils permettent aux développeurs ayant des préférences différentes en termes de taille d'indentation de changer l'apparence du code sans changer le code (séparation des données et présentation pour la victoire proverbiale!)
- Il est impossible de mettre en retrait quelque chose avec des onglets. Ainsi, lorsque vous copiez du code à partir d'un site Web qui a utilisé 3 espaces dans votre fichier en retrait de 4 espaces, vous n'avez pas à faire face à un désalignement.
Utilisez des tabulations pour mettre en retrait le début de la ligne, ne tabulation par niveau de retrait, et laissez tout le monde choisir la largeur souhaitée.
Utilisez des espaces si vous alignez des caractères dans une ligne, afin qu'ils s'alignent toujours quelle que soit la taille de l'onglet.
Et trouvez et frappez tous les premiers auteurs de logiciels qui ont laissé cette chose stupide devenir un problème en premier lieu.
(Sérieusement, pourquoi est-ce même quelque chose qui est discuté? Ensuite, vous me direz que vous souhaitez également utiliser plusieurs caractères pour les sauts de ligne!)
Onglets
- permet aux erreurs d'être plus perceptibles , c'est gênant de micro gérer les espaces.
- sont cohérents , ils ne sont utilisés que pour l'indentation, sauf si vous commentez mal.
- sont personnalisables , vous pouvez spécifier dans les options de l'éditeur leur largeur.
- sont plus productifs , pourquoi taper 4 espaces quand vous pouvez frapper 1 tab.
- prend moins de taille que plusieurs espaces.
- prend plus d'espace qu'un espace.
- prend moins de temps à parcourir .
- ont tendance à mieux fonctionner dans les IDE.
Les espaces doivent être utilisés là où les tabulations sont complètement inutiles.
Même pour aligner les paramètres et les commentaires, les onglets fonctionnent toujours mieux .
Tous les arguments pour les onglets sont excellents en théorie. Mais...
En théorie, la pratique et la théorie sont identiques. En pratique, ils ne le sont pas.
Oui, avec des onglets, vous pouvez décider de votre niveau d'indentation. Et oui, vous pouvez utiliser une combinaison d'onglets et d'espaces pour aligner les choses. Et dans un monde idéal, ce serait
En réalité, vous ne pouvez pas voir la différence entre les espaces et les tabulations, ils semblent toujours se mélanger lorsque vous déplacez du code, et afficher le code dans un autre programme dont les tabulations sont définies sur 8 colonnes est une nuisance.
J'avais l'habitude d'utiliser des onglets. Ensuite, j'ai commencé à travailler en équipe et à partager du code. Je suis rapidement devenu un partisan des espaces. Donc, même si je peux comprendre l'utopie des onglets, je ne peux pas imaginer ne pas utiliser d'espaces.
Quelques opinions pertinentes qui peuvent être intéressantes:
Onglets pour la victoire.
J'ai absolument. haine. 4. espaces.
Pourquoi? Principalement parce que je suis fatigué de naviguer dans mon code avec un clavier et de devoir constamment appuyer sur leftleftleftleft pour parcourir une indentation. Cela est né des premières versions de Notepad ++ et même du simple bloc-notes Windows où il n'existait pas de bouton de formatage. J'ai eu tellement de problèmes quand les gens n'utilisaient que 3 alors que j'en avais utilisé 4 partout ailleurs entre autres.
L'autre raison est que le caractère de tabulation existe spécifiquement pour l'indentation, et n'a été adopté que plus tard pour la navigation. Pourquoi faisons-nous spacespacespacespace alors qu'un simple tab fonctionnerait? Pourquoi les IDE devraient-ils gérer correctement le code espacé 2-5 et le format alors qu'un simple onglet et une option de préférence fonctionneraient?
Malheureusement, je suis la minorité.
Personnellement, j'aime utiliser des onglets dans tout, car chaque développeur peut contrôler la quantité d'indentation par onglet. De cette façon, vous bénéficiez d'une flexibilité d'affichage.
Cela étant dit, j'imite généralement le style de codage dans le fichier pour commencer (car je passe beaucoup de temps à effectuer des travaux de maintenance).
Je ne pense pas qu'il existe une telle indentation appropriée (du moins pas sans guerre mineure).
Personnellement, j'aime quatre espaces. Ils me permettent de lire le code beaucoup plus rapidement et ils se ressemblent dans tous les éditeurs - même Vi.
Espaces, car lorsque vous alignez des commentaires à droite du code, ou des listes de paramètres de fonction, ou des expressions multilignes complexes, ou des choses de cette nature, vous voulez que votre beau travail apparaisse bien pour tout le monde. Si vous utilisez des tabulations et autorisez les utilisateurs à définir leurs tabstops différemment, ils rompent l'alignement pour tous, sauf les cas les plus simples de retrait de code.
En outre, il est flagrant que tout le monde dans le monde devrait utiliser vim, ce qui rend trivial le retrait, le retrait et la navigation à travers les "tabulations" même dans les fichiers en retrait d'espace.
Les onglets sont le choix naturel et orthodoxe, car ils sont par définition utilisés pour l'indentation.
Malheureusement, les tabulations sont implémentées de manière inégale, donc la seule solution réelle est de 4 espaces.
Vous avez évidemment besoin d'une approche combinée.
Si vous partagez du code avec d'autres développeurs, vous devez normaliser, et comme c'est impossible (koff koff), vous devez faire en sorte que tout le monde fasse quatre espaces.
Ensuite, vous avez besoin d'un éditeur suffisamment intelligent pour ne pas être stupide à ce sujet, pour savoir qu'il doit traiter une ligne avec quatre espaces à l'avant comme si elle était en retrait. Tout éditeur IDE ou éditeur de programmeurs moderne peut flux automatique de code avec des espaces au lieu d'onglets.
Pourquoi quelqu'un ne peut-il pas implémenter cela:
- le code est stocké dans un format compact bénéfique pour le système en question
- comme chaque développeur ouvre le code, il est formaté exactement comme ils le souhaitent
- quand ils en ont fini, retour au format compact
Tout le monde est content car ils voient tous leur "propre" format
Est-ce si difficile?
Je suis un type de 4 espaces, les tabulations ne sont tout simplement pas cohérentes.
La réponse est qu'il ne peut y avoir aucun caractère d'indentation approprié pour chaque situation. Le formatage à l'aide de caractères est rigide et peut provoquer des conflits lorsque différents styles sont utilisés au sein d'une équipe.
La seule méthode pour formater le code de manière parfaite et flexible avec différents styles de formatage est de le faire virtuellement, c'est-à-dire sans aucun caractère de retrait. Le seul éditeur de code que je connaisse qui prend cela en charge est celui utilisé dans l'exemple ci-dessous:
Pour démontrer formatage virtuel, la capture d'écran ci-dessous provient d'un éditeur XSLT * qui utilise cette méthode d'indentation (il y a aussi une courte vidéo ici ). Chaque caractère du XSLT a été surligné en jaune, à des fins d'illustration, pour permettre de voir clairement les seuls caractères de tabulation ou d'espace dans le contenu. L'indentation du code est gérée par le système de rendu de l'éditeur qui ajuste la marge gauche (qui a un fond blanc).
Les seuls caractères d'espace de début précèdent les lignes Livres, car il s'agit d'un contenu textuel littéral, pas de code, ces caractères d'espace doivent être conservés.
Avec le formatage virtuel, vous choisissez la largeur d'indentation en fonction de l'environnement et du style d'indentation sans affecter les caractères du fichier source. Vous pouvez même définir la largeur d'indentation à 0, si vous avez besoin d'une vue aplatie du code, comme indiqué ci-dessous:
Pour comparer cela avec la mise en forme des caractères d'espace, le même XSLT ouvert dans un éditeur sans mise en forme virtuelle est transformé par le formateur automatique de cet éditeur en ceci:
Les blocs jaunes vides plus grands dans la capture d'écran ci-dessus montrent clairement les caractères d'espace ajoutés par le formateur de l'éditeur conventionnel. Malheureusement, ceux-ci ne peuvent plus être distingués du contenu réel, de sorte que le XSLT devrait être modifié pour corriger ce problème.
Résumé
XSLT est peut-être un cas extrême, mais ce principe est vrai pour de nombreux langages de programmation: les caractères doivent être utilisés pour le contenu et une méthode alternative recherchée en ce qui concerne le formatage.
** Divulgation: l'éditeur XSLT avec formatage virtuel a été développé par ma propre entreprise *
Non mentionné jusqu'à présent: il existe des langages (Python, Haskell) où l'indentation est importante. Mais 1 caractère compte comme 1 caractère, qu'il s'agisse d'un espace ou d'un onglet, de sorte que l'indentation vue par le compilateur peut ne pas être la même que celle que vous voyez à l'écran si vous utilisez des tabulations.
Par conséquent, dans des langues comme Haskell, les espaces sont indispensables. Dans Makefiles, TABS est un must. Dans tous les autres, c'est une question de goût personnel et de nos jours pas grand-chose - chaque éditeur décent a une commande "(en tête) des tabulations vers les espaces" et "(en tête) des espaces vers les tabulations".
Espaces ou onglets - Ce que Atwood dit vraiment, c'est de choisir une chose et d'être cohérent dans votre projet. Le seul Saint Graal de la mise en forme du code est de s'assurer que sa cohérence afin que le psychopathe qui maintient votre code après vous ne vous sentez pas obligé de remédier définitivement à la situation.
Cela dit, si vous travaillez en Python ou tout autre langage où les espaces sont une construction de programmation réelle, je ne peux pas imaginer utiliser des onglets.
Apparemment, les onglets gâchent les choses dans Delphi, donc je n'utilise pas d'onglets dans Delphi.
Cependant, je fais tout le reste en utilisant Emacs et j'utilise toujours des onglets parce que mes onglets vont exactement là où je veux qu'ils aillent.
J'utilisais des espaces, mais j'ai récemment utilisé des tabulations uniquement parce que c'est ce à quoi Eclipse était réglé quand j'ai finalement remarqué. Tous les autres développeurs de mon équipe utilisent Eclipse, il était donc logique de normaliser les onglets lorsque nous avons réalisé que nous les utilisions déjà depuis des lustres et qu'il n'y avait aucune raison de s'embêter à changer d'espace. J'ai été surpris de voir à quel point cela n'a pas été un problème.
La définition de la taille de l'onglet affichée sur 3 ou 5 caractères dans votre IDE simplifie considérablement la distinction entre les sections de code qui sont indentées par des espaces (presque toujours 4 de nos jours) et celles qui sont indentées par tab.
De nombreux arguments ont déjà été avancés, mais personne n'a mentionné où nous pourrions nous diriger à l'avenir .
Tabulations ni espaces!
Idéalement, le code devrait être considéré comme des données et ne pas être stocké dans un formatage de texte spécifique. Tout développeur peut appliquer sa propre vue préférée. De plus, cette vue ne doit pas se limiter au texte , mais peut inclure des tableaux, des sélecteurs de couleurs et des formules mathématiques.
Cette idée n'est pas trop farfelue. C'est l'éditeur Programmation Orientée Langage de JetBrain Meta Programming System (MPS) qui m'a fait réaliser que cela résout toute la discussion, ajoutant simultanément beaucoup de possibilités supplémentaires. (Oui, cela est possible avec les plugins de l'éditeur, mais travailler directement sur du texte ajoute tellement de complexités inutiles, contrairement à l'approche adoptée par MPS.)
Contrairement aux tabulations et aux espaces, il y a peu d'inconvénients qui peuvent être mentionnés pour travailler directement sur arbres de syntaxe abstraite . Tout ce qui est nécessaire, c'est que la technologie devienne un produit commercialement viable. Les premiers signes de cela apparaissent. Largement basé sur MPS, un éditeur d'actionscript commercial, Realaxy a été créé.
J'adorerais voir l'un des grands joueurs sauter sur le concept de cette technologie et voir ce qui se passe!
Ni mieux, ni pire. La seule chose importante est d'être cohérent.
Si vous êtes une équipe, choisissez ce que vous aimez personnellement. Considérez le comportement par défaut de votre éditeur préféré, mais choisissez ce que vous voulez.
Si vous faites partie d'une équipe, faites ce que fait l'équipe. Période.
Dans mes différents emplois, j'ai utilisé deux espaces, quatre espaces, huit espaces, des tabulations, des espaces et des tabulations, je pense que j'ai peut-être également utilisé un espace. Je dis à mon éditeur ce qu'il faut faire, puis je n'y pense plus, l'éditeur travaille les détails.
La seule autre chose est de vous assurer de choisir un éditeur intelligent. Emacs ou vi? Maintenant c'est une guerre sainte que je suis prêt à mener :-)