Onglets et espaces dans la programmation Python
J'ai toujours utilisé des tabulations pour l'indentation lorsque je fais de la programmation Python. Mais ensuite, je suis tombé sur une question ici sur SO dans laquelle quelqu'un a souligné que la plupart des programmeurs Python utilisent des espaces au lieu d'onglets pour minimiser les erreurs d'éditeur à éditeur.
Comment cela fait-il une différence? Y a-t-il d'autres raisons pour lesquelles on utiliserait des espaces plutôt que des tabulations pour Python? Ou est-ce tout simplement pas vrai?
Devrais-je changer d'éditeur pour insérer tout de suite des espaces au lieu des tabulations ou continuer comme avant?
Parce que PEP-8 nous dit d’utiliser des espaces.
Fatigué de courir après les typos d'indentation (8 espaces? Non, 7 oops 9 ...), je suis passé de sources en "onglets uniquement".
1 onglet == 1 niveau de retrait, point final
Le point important est le suivant: si vous souhaitez afficher l’indentation en largeur de 4, 8 ou pi/12 caractères, il vous suffit de modifier les paramètres dans votre éditeur de texte, ne modifiez pas le code.
(Personnellement, j'utilise un onglet de largeur de 4 caractères ... mais certains préfèreraient 3 ou 8 espaces, voire des polices à largeur variable.)
Ainsi parle le Seigneur: Tu vas indenter avec quatre espaces. Ni plus ni moins. Quatre seront le nombre d'espaces que vous aurez indentés, et le nombre de vos indentés sera de quatre. Huit tu ne vas pas indenter, ni non plus tu indenter deux, sauf que vous allez ensuite à quatre. Les onglets sont bien sortis. - Georg Brandl
Utilisez un éditeur qui affiche les caractères de tabulation (tous les espaces blancs, d'ailleurs). Vous programmez, n'écrivez pas un article.
J'utilise des onglets. Il n'y a pas de place pour une erreur d'un espace dans les onglets (si vous pouvez les voir). Le problème IS que les gens utilisent différents éditeurs, et la seule chose commune dans le monde est: tab == indent, comme ci-dessus. Certains types arrivent avec la touche de tabulation définie sur le mauvais nombre d'espaces ou le font manuellement et font des dégâts. Utilisez les onglets et utilisez un véritable éditeur. (Ce n'est pas simplement contraire au PEP, il s'agit également de C/C++ et d'autres langages agnostiques sans espace).
/ quitte la tribune
Ma principale raison pour utiliser des tabulations sur des espaces est la touche de retour arrière. Si je suis sur une ligne et que je veux revenir en arrière, supprimer une mise en retrait sur cette seule ligne, je dois appuyer en arrière 4 fois s'il s'agit d'espaces; alors que je n'ai besoin de le frapper qu'une fois si c'est un onglet.
Je continuerai à utiliser des tabulations car, comme cela a été dit auparavant, il est plus facile de convertir des tabulations en espaces, mais pas l'inverse.
Je pense que je veux écrire un programme simple qui convertit le code avec des espaces en code avec des tabulations, parce que je flippe des espaces de haine. Ils me conduisent au mur!
Oh! Et utiliser les touches fléchées pour naviguer à gauche et à droite est toujours pénible quand il s'agit d'espaces.
UPDATE: Sublime Text 3 supprime maintenant un onglet souple complet avec la touche de retour arrière; cependant, la navigation par touches fléchées est toujours fastidieuse.
UPDATE: J'utilise maintenant vscode et j'ai également écrit une extension TabSanity pour résoudre les retours arrière, les suppressions et la navigation par touches de direction.
La méthode la plus "pythonique" consiste à utiliser 4 espaces par niveau d'indentation. L'interpréteur Python reconnaîtra toutefois des espaces ou des tabulations. Le seul gottcha est que vous ne devez jamais mélanger des espaces et des tabulations , choisissez l’un ou l’autre. Cela dit, la spécification recommande des espaces, la plupart des développeurs utilisent des espaces, donc à moins que vous n'ayez une très bonne raison de ne pas le faire, je dirais que vous devez utiliser des espaces.
Autant que je sache, voici les avantages et les inconvénients des onglets par rapport aux espaces.
Avantages des onglets:
- Moins de frappes au clavier sont nécessaires pour mettre en retrait, désindenter et traverser l'indentation. (Même si votre IDE a une habileté d'empreinte indentative, il ne sera jamais aussi bon que des tabulations.)
- Différents programmeurs peuvent utiliser différentes tailles d'affichage d'onglets à leur guise.
- Vous ne pouvez jamais avoir le curseur "à l'intérieur" d'un caractère d'indentation. Par exemple, supposons que vous copiez certaines lignes. Avec les onglets, vous pouvez cliquer de manière vague sur le début d’une ligne pour commencer votre sélection et vous obtiendrez le premier onglet. Avec des espaces, vous risquez de manquer le premier caractère d'espace à moins que vous ne touchiez la petite cible située entre sa position et la marge. De même, pour supprimer une empreinte d'une ligne, la plupart des éditeurs ne gèrent pas bien appuyer sur la touche Retour arrière si votre curseur se trouve au milieu d'un caractère d'indentation de quatre espaces. Cela supprimera généralement un espace. Avec les onglets cela fonctionne comme prévu.
- Cohérence avec les autres langues, vous n'avez donc pas besoin de configurer votre éditeur, par exemple. onglets pour C++/Java et des espaces pour Python.
- De fausses indentations peuvent être plus évidentes (c'est-à-dire qu'un onglet supplémentaire est beaucoup plus grand qu'un espace supplémentaire).
Inconvénients des onglets:
- La plupart des programmeurs Python utilisent des espaces, vous iriez donc à l'encontre des conventions.
- L'utilisation d'espaces pour aligner des instructions multilignes est plus facile que d'utiliser des tabulations. Vous pouvez utiliser des tabulations pour l'indentation, des espaces pour l'alignement, mais cela semble un peu risqué en Python!
Certaines personnes ont exagéré certains problèmes:
Vous pouvez obtenir des espaces perdus dans l'indentation tabulée qui gâchent tout: pratiquement tous les éditeurs/éditeurs prennent en charge la visualisation des espaces, et il est presque aussi probable que vous obteniez des onglets égarés dans les indentations d'espace! Je ne peux pas voir cela comme une erreur commune de toute façon. De plus, les erreurs d'indentation la plupart seront interceptées par Python, et les bons IDE devraient pouvoir mettre en évidence différentes indentations.
Vous ne pouvez pas facilement aligner les choses avec les onglets: cela est vrai si vous souhaitez un alignement parfait, mais PEP-8 vous recommande de ne pas le faire, et Python ne fonctionne pas bien avec les instructions multilignes de toute façon.
Les utilisateurs ont des paramètres différents pour la taille d'affichage des onglets dans leurs éditeurs afin que votre code ait une apparence différente selon les endroits: oui, c'est en fait une fonctionnalité intéressante des onglets.
J'ai commencé par utiliser des espaces pour être cohérent avec d'autres codes Python, mais pour être honnête, c'est suffisamment frustrant pour que je revienne probablement aux onglets. Beaucoup dépend des capacités de votre IDE, mais selon mon expérience, aucune prise en charge par IDE de l'indentation d'espace n'est équivalente à l'utilisation de tabulations.
Donc, à moins que vraiment n'aime pas être incompatible avec most (probablement pas tout!), Code Python, utilisez des tabulations et activez la visualisation par des espaces et la mise en surbrillance de l'indentation (si disponible). La principale raison pour moi est la facilité de sélection et la réduction (assez importante de l'OMI) des frappes au clavier. Certaines conventions sont stupides.
Update: j'ai découvert qu'il existe un éditeur dans le monde entier (à l'exclusion des absurdités comme Vim) qui prend correctement en charge les espaces en tant qu'indentation: Atom. Il a une option appelée "tabstops atomiques" qui fait que 4 espaces se comportent comme s'il s'agissait d'un onglet à tout point de vue (sauf pouvoir le redimensionner). Malheureusement, Atom est un éditeur assez lent et gonflé, mais c’est une excellente fonctionnalité et si vous êtes obligé d’utiliser des espaces, cela pourrait être une bonne option. Espérons qu'un jour, d'autres éditeurs vont commencer à le soutenir. Voici le problème pour VSCode .
Je suis récemment tombé sur un article intitulé Python: les mythes concernant l'indentation qui traite de cette question et de questions connexes. L'article a de bonnes raisons de recommander l'utilisation d'espaces lors de l'écriture de code Python, mais il y a certainement de la place pour un désaccord.
Je pense que c'est vrai que la plupart des programmeurs Python utilisent uniquement des espaces.
Utilisez un éditeur qui vous permet d'insérer des espaces jusqu'à la tabulation lorsque vous appuyez sur la touche de tabulation, au lieu d'insérer un caractère\t. Et puis oublie ça.
Vous POUVEZ mélanger des onglets et des espaces ... MAIS un onglet est considéré comme la même indentation que 8 espaces. Par conséquent, à moins que votre éditeur ne soit configuré pour considérer un onglet comme 8 espaces, vous demandez des problèmes pour les mélanger.
Le seul inconvénient que je rencontre avec l'utilisation d'espaces au lieu d'onglets est qu'il est difficile de supprimer un niveau d'indentation. vous devez supprimer quatre espaces au lieu d'un seul onglet.
Je suis fermement convaincu que, quelle que soit la convention historique, les tabulations sont simplement un meilleur choix et doivent remplacer les espaces dans toutes les futures lignes de code Python écrites. Comme chasser un tyran incompétent. Mon raisonnement est le suivant: la simplicité en tant que valeur fondamentale . Utilisez deux ou peut-être quatre caractères pour la tâche sémantique d'un? Il n'y a pas de justification au-delà de la tradition, IMO.
Règle des onglets. Même argument pour les boucles imbriquées et vous souhaitez ramener la boucle externe "en arrière" de 1 niveau. Conseil: Si vous souhaitez convertir un ancien code python contenant des énigmes spatiales en onglets, utilisez l'utilitaire TabOut disponible sous forme d'exécutable sur http://www.textpad.com/add-ons/ .
Quand j'ai appris le python pour la première fois, l'idée d'un espace blanc important m'a un peu gênée, car la plupart des langages d'utilisation sont inflexibles. Cela dit, j'ai été impressionné par la capacité de Python à comprendre une variété de styles d'indentation. Lorsqu’on examine quel style utiliser pour un nouveau projet, je pense qu’il est important de garder deux choses à l’esprit.
- Tout d'abord, il est important de comprendre comment Python interprète l'indentation. Bryan Oakley a évoqué la possibilité d’erreurs erronées lorsqu’on utilise des tabulations, mais cela n’est pas possible avec les paramètres d’interpréteur par défaut. Il existe une meilleure explication de cela dans Learning Python, de O'Reilly Media .
En gros, il existe une variable (qui peut être modifiée en incluant un commentaire en haut du fichier source # tab-width:) qui définit la largeur de la tabulation. Lorsque Python rencontre un onglet, il augmente la distance d'indentation jusqu'au multiple suivant de tab-width. Ainsi, si un espace suivi d'un onglet est entré le long de la gauche du fichier, le prochain multiple de tab-width est égal à 8. Si un onglet seul est entré, la même chose se produit.
De cette manière, il est prudent, si votre éditeur est configuré correctement, d’utiliser des onglets et même de mélanger des onglets et des espaces. Tant que vous réglez l'onglet de votre éditeur sur la même largeur que la déclaration de largeur de tabulation Python (ou 8 si elle est absente). Il est généralement déconseillé d’utiliser un éditeur dont la largeur de tabulation n’est pas supérieure à 8 espaces, sauf si vous spécifiez la largeur de tabulation dans le fichier.
- Deuxièmement, une grande partie de la conception syntaxique de Python consiste à encourager la lisibilité du code et un style cohérent entre les programmeurs d'un même projet. Cela dit, la question devient, pour un projet particulier, ce qui rendra le code le plus lisible par les personnes travaillant sur le projet. Il est certes judicieux de conserver un style d'indentation cohérent, mais en fonction de la plate-forme et de l'éditeur utilisés par le projet, un style différent peut avoir un sens pour différents projets. S'il n'y a aucune raison impérieuse de ne pas se conformer à PEP 8 , il est logique de le faire, car cela correspondra à ce que les gens attendent.
J'ai rencontré des projets utilisant une combinaison d'onglets et d'espaces. Fondamentalement, les espaces sont utilisés pour mettre en retrait de petites sections, le fait que ce soit dans une section en retrait est relativement peu important; tandis que les onglets sont utilisés pour attirer l’attention du lecteur sur une grande caractéristique structurelle. Par exemple, les classes commencent par un onglet, dans lequel les contrôles conditionnels simples dans une fonction utilisent deux espaces.
Les onglets sont également utiles pour traiter de gros blocs de texte en retrait avec plusieurs niveaux. Lorsque vous supprimez 3 ou 4 niveaux d’indentation, il est beaucoup plus facile de s’aligner avec l’onglet approprié que avec le nombre approprié d’espaces. Si un projet n'utilise pas le style recommandé par PEP 8, il est probablement préférable d'écrire un guide de style dans un fichier quelque part, afin que le motif d'indentation reste cohérent et que les autres personnes puissent lire explicitement comment configurer leur éditeur.
En outre, Python 2.x dispose d'une option -t pour émettre des avertissements concernant les onglets et espaces mixtes et -tt pour émettre une erreur. Ceci s’applique uniquement aux onglets et aux espaces mixtes dans la même portée. Python 3 suppose -tt et, autant que je sache, il n’ya aucun moyen de désactiver cette vérification.
Je suis principalement un programmeur C++, mais parfois, mes projets incluent de petites quantités de Python. J'utilise des tabulations pour mettre en retrait mon code C++. Cela signifie que j'ai trois options ici:
- Utilisez des onglets en C++ et des espaces en Python. Cela permet à mes fichiers C++ de rester tels quels et je suis la recommandation PEP-8, mais je suis incohérent dans mon projet.
- Changer mon code C++ pour utiliser des espaces. Cela permet à tous les fichiers de mon projet d'être cohérents et je suis la recommandation PEP-8, mais je dois revenir en arrière et modifier tous mes fichiers C++. Je considère cela comme une mauvaise chose parce que je préfère les onglets.
- Utiliser des onglets dans mon code C++ et mon code Python. Cela rend l'ensemble de mon projet cohérent et me permet d'utiliser mon style de retrait préféré: les onglets. L'inconvénient est que je ne suis pas la norme PEP-8.
Pour mes projets, je choisis généralement l'option 3.
L'erreur éditeur à éditeur se produit lorsque vous avez indentation mixte dans un fichier. Cela se présente comme suit: un bloc de code est mis en retrait avec 4 espaces, puis un niveau d’indentation "dans", il est mis en retrait avec des onglets. Maintenant, le païen qui a fait cela (mélange d'onglets et d'espaces) l'a eu, de sorte que ses onglets ont également 4 espaces, donc il ne voit aucun problème et Python ne voit aucun problème.
Maintenant, notre victime arrive plus tard, et ses onglets sont réglés sur 8 espaces. Maintenant, nos victimes pensent que le code a l'air complètement détruit, et le corrige par supprimant un niveau d'indentation, ce qui donne maintenant le code (look} _ comme s'il en était encore à 2 d'indentation, mais est vraiment un niveau. À ce stade, tout l'enfer se déchaîne.
La leçon à tirer est qu’il ne faut jamais, jamais, mélanger des onglets et des espaces. Si vous vous en tenez à cela, alors il est facile de réindenter votre code dans des espaces ou des tabulations, peu importe ce que vous utilisez personnellement. La meilleure façon de ne pas mélanger les tabulations et les espaces est de toujours exécuter python avec -tt, ce qui produira une erreur lorsque les tabulations et les espaces sont mélangés.
En ce qui concerne les tabulations et les espaces, j’utilise personnellement des tabulations, séparant ainsi l’indentation de l’aspect; il est beaucoup plus facile de modifier l’aspect du code lorsqu’il est indenté avec des tabulations plutôt que avec des espaces. Je sais que cela va à l’encontre de ce que 99% des programmeurs Python font, mais c’est ma préférence personnelle, et il est facile dans tous les cas de convertir un fichier à onglet en un fichier espacé. L'inverse n'est pas toujours vrai, car vous pouvez accidentellement supprimer 4 espaces dans des chaînes, etc.
L’expérience et PEP-8 les deux concluent clairement qu’il faut éviter de mélanger les espaces et les TABs . Si vous souhaitez les mélanger, vous devez visualiser les espaces dans le IDE - mais vous perdez l’avantage de l'indentation de Python rendant les scopes facilement visibles. La visualisation des espaces dans un IDE encombre l’affichage.
S'il s'agit d'espaces de tabulation ou, il doit s'agir d'espaces pour une raison simple: on peut changer presque tous les IDE et les éditeurs de texte pour remplacer automatiquement les tabulations par des espaces, mais l'inverse n'est pas vrai.
Même si certains IDE peuvent convertir automatiquement les espaces de début d'une ligne en onglets, cela conduira éventuellement à un mélange d'onglets et d'espaces. Considérez des instructions multilignes telles que des appels de fonction avec beaucoup de paramètres ou de chaînes de documentation. Bien que "l'art ascii" soit également à éviter, il peut facilement arriver accidentellement qu'il ne reste qu'un seul espace après les onglets principaux.
D'autres réponses ont apporté plusieurs arguments en faveur des onglets:
- Frapper
TABest plus efficace. Bien sûr, cela est vrai, mais tous les éditeurs de texte permettent d’insérer immédiatement le nombre souhaité d’espaces lorsqu’une touche de tabulation est enfoncée. - L'indentation/dédentation est plus facile lorsqu'il suffit de supprimer un onglet au lieu d'espaces 2/3/4/8. Certes, mais la plupart des éditeurs de texte permettent néanmoins de le faire automatiquement: sélection de blocs, mise en retrait/retrait sont les fonctionnalités de base d’un éditeur de programmation, telles que les commentaires et les commentaires. Si un éditeur de texte n’a pas implémenté cette fonctionnalité, il doit au moins disposer d’une fonctionnalité de macro facile à utiliser avec laquelle on peut obtenir le même résultat.
- Différents programmeurs aiment différentes largeurs d'indentation. C’est vrai, et l’avantage évident de n’utiliser que
TABs. Le problème est l'interaction avec d'autres individus et/ou équipes. Pour que cela fonctionne dans le monde réel, tout le monde devrait se mettre d'accord sur l'utilisation deTABs uniquement. Comme cela n’est pas arrivé, cela ne fonctionne quand même pas. Dans un scénario réel, il existe de toute façon un ensemble de directives de codage sur lesquelles un projet s’entend, et la méthode d’indentation en est certainement l’une, même dans d’autres langages de programmation où les implications ne sont "que" visuelles.
A mon humble avis, le point principal qui manque ici à la plupart (sinon à toutes) des réponses est l’interaction entre les équipes ou les individus, en particulier dans les cas où la liste des participants n’est pas connue au début. Lorsque le code rencontre le code, tous doivent utiliser des tabulations ou tous des espaces. Il ne peut pas être mélangé sans rencontrer des problèmes de fonctionnalité. Les gens ne sont pas parfaits. Les outils ne sont pas parfaits. C’est pourquoi, à mon humble avis, nous ne devrions absolument pas utiliser TABs.
Aucune réponse n'est complète sans le lien que Greg a fourni dans sa réponse déjà: Python: Mythes sur l'indentation
Tout le monde a des préférences différentes sur la quantité de code à mettre en retrait. Supposons que vous partagez le code avec quelqu'un et que celui-ci a des préférences différentes en matière d'indentation. Si les indentations sont dans les onglets, votre ami peut toujours modifier la largeur de l'onglet dans les paramètres de son éditeur. Cependant, si les indentations sont dans des espaces, votre ami devra réellement changer le code source s'il veut le définir à sa préférence. Ensuite, lorsque vous recevez les modifications de votre ami, vous pouvez décider de le modifier selon vos préférences. Dans ce cas, vous devrez soit gérer l'ennui de modifier les niveaux d'indentation dans les deux sens, soit l'une des personnes doit adopter les préférences de l'autre au niveau d'indentation. Si vous et votre ami utilisez tous les deux des onglets, le fait que vous ayez des préférences différentes ne pose aucun problème, car vous pouvez voir différents niveaux d'indentation pendant que le code reste inchangé. C'est pourquoi, à mon avis, les onglets sont meilleurs que les espaces d'indentation dans tous les langages de programmation.
Il existe un scénario dans lequel les tabulations ne fonctionnent tout simplement pas: en fonction du style de codage que vous utilisez, vous devrez peut-être indenter certaines lignes de code avec une précision d'un espace, c'est-à-dire:
def foobar():
x = some_call(arg1,
arg2)
Dans ce cas, utiliser uniquement des tabulations ne fonctionnera pas du tout. utiliser des tabulations pour le retrait principal et des espaces pour le sous-retrait fonctionnera, mais violera la règle stricte de ne pas mélanger les deux.
Ce ne sera toutefois pas le cas si vous utilisez un document de style/conventions de codage qui évite des situations comme dans l'exemple de code ci-dessus.
En plus de tous les arguments déjà énumérés, je trouve celui-ci assez important (de Mythes sur l'indentation ):
De plus, les onglets sont souvent détruits ou mal convertis au cours d'opérations de copier-coller ou lorsqu'un morceau de code source est inséré dans une page Web ou dans un autre type de code de balisage.
Un autre argument (fortement spécifique à l’environnement, toutefois) contre les onglets est qu’ils sont parfois manquants sur les claviers de téléphone . On pourrait probablement remédier à cela en installant un autre clavier, si possible.
Un argument pour tabulations que personne ne semblait avoir encore mentionné est qu'un tabulation contient 1 caractère (0x09, 1 octet dans le fichier), alors que 4 espaces sont 4 caractères (4 fois 0x20, 4 octets dans le fichier) ; ainsi, utiliser des espaces entraîne 4x une perte d'espace.
Pour conclure cette liste incohérente d’arguments, je voudrais citer la réponse de Tim Peters dans Numéro 7012: Les onglets sont préférables aux espaces pour l’indentation :
Le standard "espaces seulement" de Python est pour code distribué. Des années d’expérience nous ont appris sans aucun doute que les onglets ont causé des problèmes sans fin pour partagé code (...)
Le problème avec l'utilisation d'espaces au lieu d'onglets est que la taille du fichier devient incroyablement grande. Par exemple, un fichier avec un retrait de 500 Ko pourrait être réduit à 200 Ko lors de l'échange d'espaces pour des onglets, c'est pourquoi j'utilise toujours des onglets.
Une taille de fichier plus petite signifie un chargement, une compilation, une exécution plus rapides (dans certains cas), etc.
Pour moi, il n'y a aucun intérêt à utiliser des espaces, mais si quelqu'un utilise un éditeur qui a des problèmes avec les onglets, ils peuvent alors remplacer "\ t" par "" ou "" ou autre.
Comment cela fait-il une différence?
Certains éditeurs sont configurés par défaut pour remplacer un seul caractère de tabulation par un nombre défini de caractères d'espace, mais d'autres ne le sont pas. Si tout le monde utilise des espaces, cette différence dans les paramètres d'éditeur par défaut peut être ignorée.
Y a-t-il d'autres raisons pour lesquelles on utiliserait des espaces plutôt que des tabulations pour Python? Ou est-ce tout simplement pas vrai?
Oui, il y a d'autres raisons valables, comme l'ont souligné de nombreuses réponses avant moi. "PEP-8" dit, cependant, n'est pas l'une de ces raisons. Cela vient du mythe qui se perpétue que PEP-8 est la norme de codage pour all le code Python, alors qu’il s’agit simplement de la norme de codage pour l’ensemble standard de bibliothèques Python. Certains prétendent que PEP-8 est largement accepté et d'autres affirment que la plupart des programmeurs Python utilisent des espaces au lieu d'onglets. Je voudrais demander des preuves de ces affirmations, car le nombre de votes sur ce site montre clairement que les onglets sont préférés par les masses. Je trouve assez malheureux que vous ayez accepté «PEP8 le dit» comme réponse à votre question, alors qu’il existe de nombreuses autres réponses qui expliquent les avantages et les inconvénients relatifs des espaces et des tabulations.
Devrais-je changer d'éditeur pour insérer tout de suite des espaces au lieu des tabulations ou continuer comme avant?
Cela dépend, et la réponse à cette dernière question est l'endroit où je pensais pouvoir ajouter une valeur à ce fil. IMHO, quelle que soit la langue utilisée, la meilleure norme de codage à utiliser dépend de la situation dans laquelle vous vous trouvez:
- Si vous avez commencé à travailler sur une base de code existante: ne soyez pas difficile, suivez les normes de codage existantes
- Si une équipe commence un nouveau projet à partir de zéro: discutez, choisissez une norme de codage au début en équipe et respectez-la.
- Si vous allez en solo: faites ce qui vous fait sentir le plus heureux et le plus productif
Alors, dans quelle situation es-tu tombé?
Enfin, pour clarifier ma position, pour mes propres projets en solo, j'utilise des onglets, car les onglets me semblent plus sensés et je suis plus productif avec les onglets.
Ceci est PEP 8 à partir de juillet 2017:
Il semble que cette déclaration ne laisse pas la place à un autre choix.
Mais ce n’est pas uniquement ce que PEP 8 nous dit, quelques lignes plus tard:
Dans ce qui précède, la première instruction exprime un préférence pour les espaces, et la seconde reconnaît l'existence d'un code indenté avec des tabulations et de cette préférence pour certains codeurs.
So: PEP 8 est tolérant à l'indentation des tabulations . Il ne tolère pas les tabulations et les espaces mélangés pour l'indentation, qui, comme l'indentation elle-même est obligatoire, est compréhensible.
Il convient de noter que le style de codage Python de Google suit également la règle des 4 espaces.
Il y a d'autres divers arguments et justifications en faveur des onglets ou des 4 espaces.
Si vous travaillez dans une entreprise qui applique PEP 8 ou si vous partagez régulièrement votre code avec d'autres personnes qui suivent PEP 8, le bon sens vous impose 4 espaces. Je suis (était peut-être) habitué aux onglets de C/C++. Mais avec un IDE correctement défini, la différence devient minime.
Utilisez des espaces à la place des onglets, pour la seule raison pour laquelle vous gagnerez plus d'argent :)
Réf.: Les développeurs qui utilisent des espaces gagnent plus d’argent que ceux qui utilisent des onglets (article de blog Stack Overflow).
Je suis donc en train de lire toutes les réponses et de me demander comment me conformer au PEP-8 sans me gêner de marteler mon bouton de retour en arrière de façon répétée, juste pour supprimer l’indentation. l'ampoule s'allume dans ma tête. Ouvrez le logiciel logitech, définissez quelques macros pour les boutons situés juste à côté du bouton d'onglet et le problème est résolu. Un bouton ajoute quatre espaces, l’autre effectue un retour arrière quatre fois. Incroyable. Juste incroyable. Tellement facile de frapper les boutons avec mon petit doigt aussi. Voir, regardez ceci: "" <- quatre espaces! Avec une simple pression sur un bouton! Si je pouvais vous montrer les backspaces, je le ferais aussi. Obtenez un clavier Logitech G105 et tous vos problèmes disparaîtront!
Je crois qu'il existe une solution pour avoir les deux:
- Compatibilité avec PEP-8 et utilisation d'espaces
- Commodité d'utiliser une tabulation au lieu de 4 espaces
Dans Notepad ++, allez dans "Préférences" -> "Paramètres de l'onglet" et choisissez "Python" dans la liste de droite. Assurez-vous ensuite de "Taille de l'onglet: 4" et cochez la case "Remplacer [onglet] par un espace". Dans ce cas, vous pouvez simplement utiliser la touche de tabulation pour mettre en retrait, mais Notepad ++ le transforme réellement en 4 espaces pour vous.
Je viens tout juste de commencer, mais je trouve qu'il est beaucoup plus facile d'utiliser des tabulations que des espaces et je ne comprends pas la promotion des espaces PEP-8 uniquement. Sublime Text 2 fait un excellent travail de visualisation des onglets avec la ligne pointillée verticale verticale et blanc cassé. être nuisible.
J'adore les tabulations mais c'est en quelque sorte incompatible avec une autre règle que j'aime bien: la limite de 80 colonnes.
Si on choisit 4 tabulations d'espacement et insère 10 tabulations, il reste de la place pour 40 caractères afin de respecter la limite de 80 colonnes ..__ Si un autre codeur préfère 8 tabulations d'espacement, la même ligne apparaîtra sur 120 caractères et ne sera pas comme une ligne valide de 80 colonnes!
Si vous souhaitez définir une limite de 80 colonnes, vous devez choisir une longueur pour un onglet. Dans ce cas, avoir x espaces ou une tabulation de longueur x ne fait pas vraiment de différence.
Edit: thread connexe: Maintien de la longueur de ligne maximale lors de l'utilisation d'onglets au lieu d'espaces?
Je pense que l'un des principaux avantages de l'utilisation des espaces est la suppression de la variabilité dans la manière dont le code source est restitué à travers la pléthore d'outils externes qui doivent interagir avec la source au-delà de l'éditeur de choix et quels que soient les paramètres dans lesquels ils ont été configurés.
Comme exemples concrets, considérons le rendu des docstrings Python dans une info-bulle dans Visual Studio Code , ou dans un outil de diff comme Beyond Compare ou WinMerge , des outils de couverture de performance ou de code, etc. Tous ces autres outils d'interfaçage peuvent avoir chacun des paramètres différents pour l'interprétation des onglets. Cela peut être ennuyeux et parfois désorientant de trouver des choses très différentes ou très éloignées de l'écran parmi les outils que vous pouvez explorer.
En un mot, vous définissez l'alignement dans la source plutôt que de créer une configuration uniforme pour la suite d'outils de votre arsenal. Les espaces sont strictement interprétés dans une police monospace pour assurer un alignement fiable et cohérent sur toute l'étendue de l'outillage en raison de la définition de la police, et non de l'implémentation/configuration de rendu des onglets d'un tiers.
Un autre angle par rapport à cela consiste à copier la source des onglets principaux à exécuter sur un terminal où le caractère de tabulation peut déclencher une complétion de tabulation par inadvertance. Par exemple, si vous copiez la source Python suivante (onglets utilisés comme indentation),
cmd_create_db = '''CREATE TABLE test (
Col1 INTEGER,
Col2 INTEGER,
Col3 TEXT)'''
vous pouvez voir quelque chose comme suit (visible sur le terminal intégré de Visual Studio Code) ...
>>> cmd_create_db = '''CREATE TABLE test (
... .DS_StoreCol1 INTEGER,
... .DS_StoreCol2 INTEGER,
... .DS_StoreCol3 TEXT)'''
>>> cmd_create_db
'CREATE TABLE test (\n.DS_StoreCol1 INTEGER,\n.DS_StoreCol2 INTEGER,\n.DS_StoreCol3 TEXT)'
(De plus, je me suis demandé si cette observation de la cohérence entre les outils était le signe de l'esprit de discernement d'un développeur perspicace cherchant à ordonner le monde, ce qui indiquerait peut-être un indice de la différence de salaire constatée sur Stack Overflow.)
J'utilise deux espaces et un éditeur (kwrite) qui insère des espaces au lieu de tabulations lorsque je frappe la touche de tabulation.
Avoir récemment eu à traiter avec du code existant qui mélangeait des espaces et des tabulations, c'est vraiment déroutant.
Lorsque vous mixez (ce que vous ne devriez vraiment pas faire, mais qui existe malheureusement malheureusement), il apparaît que "1 onglet == 1 niveau de retrait" n'est pas vrai.
Prenons l'exemple suivant (essayé avec Python 2.7):
# Mostly use spaces
class TestClass:
def __init__(self):
self.total = 0
def add(self, x):
# 8 spaces at the start of the following line:
self.total += x
# SO automatically uses spaces, but use tabs in the next 2 lines.
# One tab at the start of the following line:
if self.total > 10:
# Two tabs at the start of the following line:
print "Greater than 10!"
# Now use spaces again.
return self.total
tc = TestClass()
print "Total: %d" % (tc.add(5),)
print "Total: %d" % (tc.add(5),)
print "Total: %d" % (tc.add(5),)
Ici, il y a 4 espaces avant def add(...) (1 niveau d'identification), 8 espaces avant self.total += x (2 niveaux d'indentation) et un seul onglet avant if self.total > 10.
Pourtant, cet onglet unique se comporte comme 2 niveaux d'indentation, puisque ce code fonctionne. En revanche, si vous remplacez tous les onglets par 4 espaces (un seul niveau d'indentation, c'est là que se trouve def dans la classe), vous obtiendrez une erreur d'indentation inattendue avant return car ce n'est plus dans un bloc def.
Ceci est vraiment déroutant avec les éditeurs qui affichent des tabulations de 4 caractères. Bien sûr, cela peut être configuré, mais cela affecte également les visualiseurs de code source (comme GitHub, par exemple) où il n’est pas forcément facile à configurer (ou visibles immédiatement lorsque vous en avez besoin).
L'onglet v. Le comportement de l'espace dépendra toujours de l'éditeur:
- Si votre éditeur insère automatiquement des espaces chaque fois que vous appuyez sur la touche de tabulation, il insérera le nombre correct d'espaces, de sorte qu'un autre éditeur affiche exactement le même style.
- Si votre éditeur n'utilise pas d'onglets, il est toujours possible que vous ne remarquiez pas une ligne utilisant des espaces au lieu d'onglets (surtout si d'autres éditeurs sont utilisés dans le projet).
Les deux ont leurs inconvénients. L'essentiel est qu'il doit y avoir un choix arbitraire entre les tabulations et les espaces, mais ils ne doivent jamais être mélangés. Comme vous ne savez jamais comment votre code va être lu et utilisé plus tard, il est bon d'avoir une convention qui affecte tous les codeurs Python. PEP-8 dit des espaces, ainsi soit-il.
Ce qui compte, c’est de ne pas le faire à la manière de Java :
Quatre espaces doivent être utilisés comme unité d'indentation. L'exact la construction de l'indentation (espaces vs tabulations) n'est pas spécifiée. Onglets doit être défini exactement tous les 8 espaces (pas 4).
Oui ... 1 onglet = 2 niveaux d'indentation dans le monde Java! Heureusement, cela n’a pas la même signification en termes de compilation.
Les gens utiliseront différents éditeurs sur le même code. Ces éditeurs représenteront un onglet à l'écran différemment. Si vous travaillez sur un éditeur qui représente une tabulation de 4 espaces, si vous indenter la première ligne de "\t " et la seconde de "\t\t", ils auront l'air d'être au même niveau de retrait: 8 espaces.
L'interpréteur Python ne connaît pas votre éditeur et doit interpréter l'onglet comme une certaine indentation. En fait, la tabulation est interprétée par 8 espaces, de sorte que les niveaux d'indentation diffèrent de ce que vous vouliez: 12 espaces pour la première ligne, 16 espaces pour la seconde. Vous êtes grillé.
Un argument plus obscur (pour certains!) Du côté des onglets: on me dit que les onglets fonctionnent mieux avec les lecteurs d'écran pour les aveugles.
Je suis récemment passé des onglets aux espaces, pour la conformité PEP 8.
J'ai aimé les onglets précédemment pour deux raisons:
- Avec les onglets, tout le monde peut voir le code avec le niveau d'indentation de leur choix utilisez simplement des espaces à droite et des onglets à gauche.
- faire des onglets assez mal
... mais après avoir réalisé à quel point le PEP 8 est devenu important, j'ai quand même basculé. Selon moi, la valeur principale des espaces par-dessus les onglets est la simplicité - ce que vous voyez est ce que vous avez. Et conformité au PEP 8. Et je suis arrivé avec une règle Vim qui allumait les espaces pour les fichiers Python, laissant l'onglet Makefile.