Pourquoi certaines langues recommandent-elles d'utiliser des espaces plutôt que des tabulations? [fermé]


10

Peut-être que je suis seul dans ce domaine, mais peu de choses m'ennuient comme les personnes qui utilisent des espaces plutôt que des tabulations. En quoi la saisie est-elle SpaceSpaceSpaceSpaceplus facile et plus intuitive que la saisie Tab? Bien sûr, la largeur de tabulation est variable, mais elle indique beaucoup plus l'espace d'indentation que les espaces. La même chose vaut pour le retour en arrière; retour arrière une ou quatre fois?

Pourquoi les langages comme Python recommandent-ils d'utiliser des espaces sur les tabulations?


24
Vous pouvez configurer la plupart des éditeurs pour insérer des espaces au lieu d'onglets lorsque vous appuyez sur tab. Si vous ne pouvez pas configurer cela dans votre éditeur préféré, vous avez besoin d'un meilleur éditeur.
Adam Lear

une chose, de nombreux éditeurs peuvent être configurés pour insérer 4 à 8 espaces lorsque vous appuyez sur «tab», il ne s'agit donc que d'une seule touche, tout comme tab.
Echo dit Réintégrer Monica

2
Cela ne répond toujours pas à ma question. Pourquoi des espaces au lieu des tabulations? Bien sûr, vous pouvez configurer votre éditeur pour insérer des espaces au lieu d'onglets, mais vous pouvez également insérer des onglets avec des espaces. La question est pourquoi voudriez-vous faire cela? Quel avantage possible en est-il tiré?
Naftuli Kay

4
Les espaces @Tk sont des onglets non ambigus qui peuvent être modifiés
Martin Beckett

3
@TKKocheran, car les onglets font des choses géniales à votre sortie lorsque vous les insérez accidentellement dans une chaîne.
zzzzBov

Réponses:


15

Cohérence, principalement.

En outre, quelque chose arrive parfois qui utilise réellement l'espace blanc - comme Python: dites-moi, que se passera-t-il si j'exécute l'extrait de code suivant?

def foo():
    print "a"
    print "b"

Réponse: Vous obtiendrez une IndentationError, car ces deux instructions d'impression ne sont pas en retrait au même niveau - et ne font donc pas partie du même bloc de code. (Le premier utilise une tabulation, le second tous les espaces)

Ensuite, il y a les cas frustrants lorsqu'un éditeur de développeur a des onglets définis sur 8 espaces, et un autre les a définis sur 4 et que quelqu'un utilise 5 pour une raison étrange ... Cela peut sembler parfaitement normal sur un poste de travail, mais lorsqu'il est archivé dans SVN et quelqu'un d'autre met à jour, ils verront un désordre horrible, horrible.

Ce sont donc deux bonnes raisons d'être toujours cohérent, que ce soit des espaces ou des tabulations.

Mais, les espaces permettent de contrôler bien plus l'indentation que les onglets et ne nécessitent aucune configuration spéciale dans les éditeurs pour que cela fonctionne. (Bien que cela puisse être plus facile - par exemple, dans vim, utilisez simplement set expandtabpour insérer des espaces chaque fois que vous appuyez sur tab)

EDIT: Et de manière assez amusante, le site semble avoir normalisé mes onglets dans des espaces afin que le navigateur puisse les afficher correctement. Cliquez sur "modifier" pour voir l'original, onglets inclus;)


5
Vos problèmes avec les onglets (en particulier, le désordre horrible SVN) ne surviennent que si vous utilisez l'option tabulations vers espaces dans votre éditeur. Si vous et votre équipe acceptez de désactiver l'option tabulations vers espace, un onglet sera toujours un onglet dans n'importe quelle vue: il s'agit simplement d'un choix de la largeur que vous souhaitez qu'il affiche dans votre éditeur.
HorusKol

@HorusKol Non, le désordre horrible est dû au fait que les espaces et les tabulations se sont mélangés. Je suppose que je n'ai pas rendu cela assez évident (voir la seule phrase après la ligne "horrid, horrid mess"). Les espaces ont donc été conçus pour s'aligner parfaitement avec les tabulations lorsqu'ils sont définis pour être équivalents à 4 espaces, mais lorsque quelqu'un d'autre les affiche (que les tabulations vers les espaces soient définis ou non), ils obtiennent un désordre.
Izkata

4
Je vois - eh bien, vous devez définir une ligne directrice pour votre équipe - soit utiliser systématiquement des espaces OU des tabulations ... de toute façon, les tabulations vers les espaces sont une mauvaise idée tout au long;)
HorusKol

21
C'est pourquoi je considère l'idée de langages significatifs d'espaces comme un défaut de conception. Les choses que vous ne pouvez pas voir ne devraient jamais casser votre code.
Paul Nathan

Juste pour mémoire, je suis d'accord avec @PaulNathan
Izkata

11

Ceci est une bonne discussion sur l'indentation et les espaces en Python; de l'article:

[I] l peut être une bonne idée d'éviter tous les onglets ensemble, car la sémantique des onglets n'est pas très bien définie dans le monde informatique, et ils peuvent être affichés complètement différemment sur différents types de systèmes et d'éditeurs. De plus, les onglets sont souvent détruits ou mal convertis lors des opérations de copier-coller, ou lorsqu'un morceau de code source est inséré dans une page Web ou tout autre type de code de balisage.

En ce qui concerne votre argument sur la pression de la barre d'espace ou de la touche de retour arrière 2 fois ou plus, puisque la plupart des éditeurs de code source insèrent un nombre configurable d'espaces en appuyant une seule fois sur la touche de tabulation, et de la même manière que le retrait, il n'y a plus de touches enfoncées lorsque en utilisant des espaces pour l'indentation.

Pour moi, je préfère les espaces parce que le code est toujours affiché avec la même quantité d'indentation, que je le visualise dans un IDE, ou less, ou Bloc-notes; c'est-à-dire que les espaces sont plus portables.


3
re: "que je le visualise dans un IDE, ou moins, ou dans le Bloc-notes; c'est-à-dire que les espaces sont plus portables" - c'est le meilleur argument pour les espaces que j'ai jamais entendu. Je suis moi-même un mec des "tabulations", mais j'ai parfois détesté voir du code espacé entre les tabulations rendu de manière inattendue.
Aerik

2

En Python, l'indentation contrôle le flux du programme et est donc vitale.
Si vous prenez du code formaté avec des onglets et copiez-le afin que les onglets soient modifiés ou perdus, la structure du code est détruite. Les espaces sont toujours des espaces = beaucoup plus sûrs.

Si l'usure de votre barre d'espace vous inquiète, votre éditeur peut probablement être configuré pour convertir automatiquement les tabulations en espaces.


Je suis plus préoccupé par le temps perdu à taper quatre fois l'espace ou le retour arrière par rapport à une seule touche pour faire les deux.
Naftuli Kay

Oui, mais Python est bizarre de cette façon. Je n'ai jamais rien rencontré d'autre qui se soucie des espaces.
Aerik

@TKKocheran Oh, c'est votre vraie préoccupation? Je ne sais pas comment ils l'ont fait, mais vim à mon travail est configuré de sorte que le retour arrière retourne au dernier tabstop, sur plusieurs espaces, de manière complètement transparente
Izkata

Pourriez-vous vider .vimrcpour moi :)
Naftuli Kay

1
@TKKocheran Trouvé - c'est juste set softtabstop=4, et TAB et BACKSPACE utiliseront 4 espaces comme tabulation. (Eh bien, à chaque tabstop, en traitant la largeur comme 4 espaces)
Izkata

2

Les espaces doivent toujours être utilisés, car les onglets seuls ne sont pas suffisamment flexibles pour de nombreux styles, et le mélange des onglets et des espaces produit (presque) toujours un désordre absolu.

Pour un exemple d'un style qui nécessite généralement des espaces, considérez quelque chose comme:

call_some_function(parameter1,
                   parameter2,
                   parameter3,
                   parameter4,
                   parameter5,
                   parameter6,
                   parameter7);

À moins que vous ne souhaitiez renommer toutes vos fonctions pour être un multiple exact de la taille des onglets (moins un pour la parenthèse), les onglets ne suffiront tout simplement pas.

En ce qui concerne le mélange des tabulations et des espaces, vous rencontrez presque immédiatement un problème grave: les tabulations ne sont pas systématiquement étendues de la même manière. Certains logiciels traitent un onglet comme équivalent à un nombre spécifique d'espaces. D'autres logiciels étendent un onglet modulo d'un nombre spécifique d'espaces - par exemple, un élément après un onglet commencera toujours par un numéro de colonne qui est un multiple de (disons) 8.

Même si vous pouvez vous assurer que les espaces ne se mélangent pas avec vos onglets, vous avez toujours un problème: les onglets jouent également mal avec les polices à largeur variable. Ce problème se produit lorsque (par exemple) vous souhaitez des commentaires de fin alignés:

a.m = 9;   // this is the slope
a.i = 4;   // this is the intensity
a.x = 1;   // this is the x-intercept

En l'état actuel, tous s'alignent parfaitement. Vu avec une police de largeur variable, cependant, les choses deviennent laides. Avec des espaces, les commentaires peuvent (souvent) être légèrement désalignés. Avec les onglets, cependant, le désalignement devient souvent assez radical:

a.m = 9;          // this is the slope
a.i = 4;  // this is the intensity
a.x = 1;          // this is the x-intercept

Soudain, la petite différence de largeur entre le «i» et le «m» ou le «x» dans notre police à largeur variable a été agrandie jusqu'à un taquet de tabulation entier.

L'essentiel est que presque tout changement dans la façon dont vous affichez le code avec des onglets, aussi banal soit-il, peut et va généralement produire un désordre illisible.

Pour répondre à vos autres questions: d'autres l'ont déjà signalé, mais je ne peux pas imaginer que quelqu'un dans un éditeur de programmation (ou beaucoup d'autre chose) utilise réellement la barre d'espace pour insérer les espaces, donc votre question sur: "taper spacespacespacespace" est non pertinent parce que personne ne fait ça de toute façon. De même avec l'espacement arrière: il est difficile d'imaginer un éditeur qui nécessiterait d'appuyer surBkSpc quatre fois pour aller à un tabulation précédent, donc (encore une fois) la question n'est pas pertinente.

En bout de ligne: les onglets sont parfaits si vous (et seulement vous) regarderez jamais votre code, et vous ne le faites qu'avec un seul éditeur que vous ne reconfigurez jamais (du tout!) Ces conditions, cependant, sont si proches de l'impossible imposer qu'il n'y ait qu'une seule réponse raisonnable: ne jamais utiliser d'onglets du tout.


1
Je vois que vous dites "les polices proportionnelles cassent à la fois les espaces et les tabulations mais elles cassent les tabulations pire, alors utilisez des espaces". Pourquoi ne pas utiliser des languettes élastiques? nickgravgaard.com/elastictabstops
amara

@sparkleshy: C'est une bonne idée, mais cela ne fait aucune différence avec le vrai code, et ne le sera pas tant que tous (ou du moins la grande majorité) des vrais éditeurs ne l'auront pas déjà inclus.
Jerry Coffin

... Je sais: '(- enfin, en quelque sorte. Vous pouvez toujours utiliser un éditeur soutenu par des espaces (comme la touche de tabulation devrait l'être si vous utilisez des espaces) mais prétend qu'ils sont des tabstops élastiques; cela rend la gestion des espaces plus facile.
amara

2
Si vous programmez avec des polices de largeur proportionnelle, eh bien, vous avez bien plus de problèmes que de simples onglets à craindre ...
Brian Knoblauch

1
@BrianKnoblauch: En tant que personne qui utilise la police eurofurence, je dois être en désaccord. Les seules choses qui me causent des problèmes sont les espaces. Cela a aussi à voir avec mon style de retrait bien sûr, qui ne doit jamais différer de plus d'un onglet entre les lignes. En supposant que j'obtienne des tabstops élastiques, mon code sera encore meilleur.
Magus

2

Le gros problème est l'incohérence de la largeur des "tabulations" parfois elles sont rendues comme quatre espaces parfois huit. Dans de nombreux éditeurs, vous pouvez les définir de 1 à 9 espaces.

Donc, cela transforme un simple éditeur WYSWYG en ce que vous voyez est ce que quelqu'un d'autre pourrait obtenir.

C'est un problème particulier pour Python, mais c'est aussi un problème dans tous les langages "accolades" car l'indentation est utilisée pour transmettre du sens aux lecteurs humains et les onglets foirés rendent le code difficile à lire.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.