Onglets et espaces dans la programmation Python

https://stackoverflow.com/questions/119562

02-07-2019
|

Question

J'ai toujours utilisé des tabulations pour l'indentation lorsque je fais de la programmation Python. Mais ensuite, je suis tombé sur une question sur SO, où quelqu'un a fait remarquer que la plupart des programmeurs Python utilisent des espaces au lieu d'onglets pour minimiser les erreurs rédacteurs.

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 faux?

Devrais-je changer d'éditeur pour insérer tout de suite des espaces à la place des tabulations ou continuer comme avant?

La solution

Parce que le PEP-8 nous indique de: utiliser des espaces.

Autres conseils

Fatigué de courir après les typos d'indentation (8 espaces? non, 7 oops 9 ...), je suis passé de sources à "onglets uniquement".

1 onglet == 1 niveau de retrait, point final

Le problème est le suivant: si vous souhaitez afficher l'indentation en tant que largeur de 4, 8 ou pi / 12 caractères, il vous suffit de modifier les paramètres dans votre éditeur de texte, ne vous mêlez pas du code.

(Personnellement, j'utilise un onglet de largeur de 4 caractères ... mais certains préfèreraient 3 ou 8 espaces, ou même des polices à largeur variable.)

Ainsi parle le Seigneur: Tu indenteras avec quatre espaces. Ni plus ni moins. Quatre seront le nombre d'espaces que vous indenterez, et le nombre de votre indentation sera de quatre. Huit tu ne vas pas indenter, ni non plus tu indenter deux, sauf que vous allez ensuite à quatre. Les onglets sortent. - Georg Brandl

UTILISEZ UN ÉDITEUR AFFICHANT LES CARACTÈRES DE TAB (tous les espaces, en l'occurrence). Vous programmez, vous 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 est que les gens utilisent différents éditeurs et que la seule chose commune au monde est la suivante: 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 seulement contraire au PEP, il s’agit également du 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 sur la touche Retour arrière 4x s'il s'agit d'espaces; alors que je n'ai besoin que de le frapper une fois si c'est un onglet.

Je continuerai à utiliser des tabulations car & # 8212; comme cela a été dit avant & # 8212, 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 onglets, 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 désormais vscode et écrit également un Extension TabSanity pour résoudre les problèmes de retour arrière, de suppression et de navigation par touches fléchées.

Le plus " pythonique " manière est d’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 les espaces et les tabulations , choisissez l’un ou l’autre. Cela dit, la spécification recommande des espaces. La plupart des développeurs utilisent des espaces. Par conséquent, à moins que vous n'ayez vraiment une bonne raison de ne pas le faire, je dirais que vous devez utiliser des espaces.

Pour 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, annuler la mise en retrait et traverser l'indentation. (Même si votre IDE a une certaine astuce d’indentation d’espace, il ne sera jamais aussi bon que des onglets.)
Différents programmeurs peuvent utiliser différentes tailles d'affichage d'onglets à leur guise.
Vous ne pouvez jamais avoir le curseur & "à l'intérieur de &"; 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. Vous obtiendrez ainsi 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 mise en retrait 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. des onglets pour C ++ / Java et des espaces pour Python.
Les indentations erronées peuvent être plus évidentes (c'est-à-dire qu'un onglet supplémentaire est beaucoup plus grand qu'un espace supplémentaire).

Contre des onglets:

La plupart des programmeurs Python utilisent des espaces pour que vous puissiez aller contre la convention.
Utiliser des espaces pour aligner des instructions multilignes est plus facile que d’utiliser des tabulations. Vous pouvez utiliser des tabulations pour indentation, des espaces pour alignement, mais cela semble un peu risqué en Python!

Certaines personnes ont exagéré certains problèmes:

Vous pouvez obtenir des espaces dans l'indentation à onglets 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. En outre, la plupart des erreurs d’indentation seront capturées par Python et les meilleurs IDE devraient pouvoir mettre en évidence différentes indentations.
Vous ne pouvez pas facilement aligner les objets avec les onglets: cela est vrai si vous souhaitez un alignement parfait du personnage, mais PEP-8 vous recommande de ne pas le faire, et Python ne fonctionne pas bien avec des instructions multilignes. de toute façon.
Les éditeurs ont des paramètres différents pour la taille d'affichage des onglets de sorte que votre code sera différent selon les endroits: oui, c'est 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 l'IDE de l'indentation d'espace n'est aussi efficace que d'utiliser simplement des onglets.

Ainsi, à moins que vous n'aimiez vraiment pas l'incohérence avec la plupart (probablement pas tous!), code Python, utilisez des tabulations et activez la visualisation d'espaces et l'indentation en surbrillance (if 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.

Mise à jour : j'ai découvert qu'il existe un éditeur dans le monde entier (à l'exception des absurdités comme Vim) qui prend correctement en charge les espaces en tant qu'indentation: Atom. Il a une option appelée & "; Des tabstops atomiques &"; cela fait 4 espaces se comporter comme s'il s'agissait d'un onglet à tous égards (sauf être capable de 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 du code VSCode .

Je suis récemment tombé sur un article intitulé Python: Mythes concernant l'indentation , qui traite de cette question et de questions connexes. Cet article a de bonnes raisons de recommander l’utilisation d’espaces lors de l’écriture de code Python, mais des divergences subsistent.

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 butée lorsque vous appuyez sur la touche de tabulation au lieu d’insérer un caractère \ t. Et puis oubliez-le.

Vous POUVEZ mélanger des tabulations et des espaces ... MAIS un onglet est considéré comme ayant la même indentation que 8 espaces, donc à moins que votre éditeur ne soit configuré pour considérer un onglet comme 8 espaces, vous nous posez des problèmes lorsque vous les mélangez .

Le seul inconvénient que je rencontre avec l’utilisation des espaces à la place des tabulations est qu’il est impossible de supprimer facilement un niveau d’indentation; vous devez supprimer quatre espaces au lieu d'un seul onglet.

Règle des onglets. Même argument pour les boucles imbriquées et vous souhaitez ramener la boucle externe & "; Retour &"; 1 niveau. Conseil: Si vous souhaitez convertir un ancien code python contenant des énigmes spatiales en onglets, utilisez l'utilitaire TabOut disponible en tant qu'exécutable dans . http://www.textpad.com/add-ons/ .

Je suis persuadé 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 aucune justification au-delà de la tradition, IMO.

Une erreur

entre rédacteurs se produit lorsque vous avez une 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, les païens qui ont fait cela (mélange d’onglets et d’espaces) l’ont eu, de sorte que ses onglets ont également 4 espaces; il ne voit donc 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 en supprimant un niveau d'indentation , ce qui donne maintenant au code le même aspect . encore 2 niveaux 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 les onglets et les espaces. Si vous vous en tenez à cela, 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 onglets et les espaces est de toujours exécuter python avec -tt, ce qui produira une erreur lors du mélange des onglets et des espaces.

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’apparence du code lorsqu’il est mis en retrait avec des tabulations plutôt que des espaces. Je sais que cela va à l’encontre de ce que font 99% des programmeurs Python, 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.

Lorsque j’ai commencé à apprendre le langage Python, j’ai été un peu décontenancé par l’idée d’un espace blanc important, car la plupart des langages qui l’utilisent 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 lors de l’utilisation d’onglet, mais cela n’est pas possible avec les paramètres d’interpréteur par défaut. Il existe une meilleure explication à cela dans Learning Python , dans O'Reilly Média .

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é à 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, sauf si vous spécifiez la largeur de la tabulation dans le fichier.

Deuxièmement, la conception syntaxique de Python consiste en grande partie à encourager la lisibilité du code et un style cohérent entre les programmeurs d'un même projet. Cela dit, la question qui se pose est de savoir, pour un projet donné, 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 & Nbsp; 8 , alors il est logique de le faire, car cela correspondra à ce que les gens attendent.

J'ai rencontré des projets qui combinent avec succès des onglets et des espaces. Fondamentalement, les espaces sont utilisés pour mettre en retrait de petites sections, le fait qu'il s'agisse d'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 lorsqu'il s'agit de grands blocs de texte mis en retrait par 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 & Nbsp; 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 utilisateurs puissent lire explicitement comment configurer leur éditeur. match.

De plus, Python 2.x dispose d’une option -t pour émettre des avertissements concernant les onglets et les 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 & Nbsp; 3 suppose <=> et, autant que je sache, il n’existe 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 car 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 d'indentation préféré: les onglets. L’inconvénient est que je ne respecte pas la norme PEP-8.

Pour mes projets, je choisis généralement l'option 3.

Expérience et PEP-8 concluent clairement que le mélange les espaces et TAB s doivent être évités. Si vous voulez les mélanger, vous devez visualiser les espaces dans l'EDI - mais vous perdez alors l'avantage de l'indentation de Python, ce qui rend les étendues facilement visibles. La visualisation des espaces dans un IDE encombre l’affichage.

S'il s'agit de tabulations ou , il doit s'agir d'espaces pour une raison simple: on peut basculer la quasi-totalité des IDE et des éditeurs de texte pour remplacer automatiquement les tabulations par des espaces, mais l'inverse n'est pas vrai.

Même s'il existe des environnements de développement intégrés (IDE) capables de convertir automatiquement les espaces de début de ligne en onglets, cela aboutira é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 & "; Ascii-art &"; Il faut aussi éviter par hasard qu’il ne reste qu'un espace après les onglets qui précèdent.

D'autres réponses ont apporté plusieurs arguments en faveur des onglets:

Frapper <=> est 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 / la dédentation est plus facile lorsque vous devez simplement supprimer un onglet au lieu de 2/3/4/8 espaces. 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 / annulations. 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 c’est un avantage évident d’utiliser uniquement <=> s. 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 de <=> s 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’accorde, et la méthode d’indentation en est certainement l’une, même dans d’autres langages de programmation où les implications sont & «Seulement»! au niveau visuel.

Mon dieu, 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 <=>.

Aucune réponse n'est complète sans le lien que Greg a déjà fourni dans sa réponse : 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. Toutefois, si les indentations sont dans des espaces, votre ami devra en fait changer le code source s'il souhaite le définir selon ses préférences. 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 n’est pas un 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 onglets ne fonctionnent tout simplement pas: en fonction du style de codage que vous utilisez, il peut être nécessaire d'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.

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 en retrait de 500 & nbsp; Ko pourrait être réduit à 200 & nbsp; KB lors de l'échange des espaces pour les onglets, c’est pourquoi j’utilise toujours des onglets.

Une taille de fichier réduite signifie un chargement, une compilation, une exécution (dans certains cas), etc. plus rapides.

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, il peut remplacer & "; \ t &"; avec " " ou " " ou peu importe ...

En plus de tous les arguments déjà énumérés, je trouve celui-ci assez important (tiré de Mythes sur l'indentation ):

De plus, les onglets sont souvent détruits ou mal convertis lors des opérations de copie / collage, ou lors de l'insertion d'un morceau de code source dans une page Web ou un autre type de code de balisage.

Un autre argument (fortement lié à l'environnement, cependant) contre les onglets est qu'ils sont parfois absents des claviers de téléphone . On pourrait probablement remédier à cela en installant un autre clavier, si possible.

Un argument pour onglets que personne ne semblait avoir encore mentionné est qu'un 1 onglet correspond à 1 caractère (0x09, 1 octet dans le fichier), alors que 4 espaces correspondent à 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 le numéro 7012: onglets est meilleur que les espaces pour l'indentation :

Le Python & "espaces seulement" & "; la norme 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 le code partagé (...)

En quoi 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.

Existe-t-il d'autres raisons pour lesquelles on utiliserait des espaces plutôt que des tabulations pour Python? Ou est-ce tout simplement faux?

Oui, il existe d'autres raisons valables, comme le soulignent 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 tout le code Python, alors qu’il s’agit en fait 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 inconvénients relatifs des espaces et des tabulations.

Devrais-je changer d'éditeur pour insérer tout de suite des espaces à la place des tabulations ou continuer comme avant?

Cela dépend, et la réponse à cette dernière question est la suivante: je pensais pouvoir ajouter de la valeur à ce fil de discussion. 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 la norme de codage existante
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 tombez-vous?

Enfin, pour clarifier ma position, j'utilise des onglets pour mes propres projets en solo, car les onglets me semblent plus sensés et je suis plus productif avec les onglets.

Je pense 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 ++, accédez à " préférences " - > " paramètres de tabulation " et choisissez " Python " de la liste à droite. Assurez-vous ensuite & "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.

Il s'agit du PEP & nbsp; 8 à compter du mois de juillet. 2017:

Il semble que cette déclaration ne laisse de place à aucun autre choix.

Mais ce n'est pas uniquement ce que PEP & nbsp; 8 nous indique quelques lignes plus tard:

Dans ce qui précède, la première instruction exprime une préférence pour les espaces, et la seconde indique l'existence d'un code indenté avec des tabulations et cette préférence pour certains codeurs.

Ainsi : PEP & nbsp; 8 est tolérant à l’indentation des onglets. Il ne tolère pas les tabulations et les espaces mixtes pour l'indentation, ce qui est compréhensible, puisque l'indentation est obligatoire.

Il convient de mentionner que le le style de codage Python de Google suit également le Règle des 4 espaces.

Il existe d'autres arguments et justifications divers en faveur des onglets ou des 4 espaces.

Si vous travaillez dans une entreprise qui applique PEP & nbsp; 8, ou partagez régulièrement votre code avec d'autres personnes qui suivent PEP & nbsp; 8, alors le sens commun dicte 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 font plus Money Than 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 je peux me conformer à PEP-8 sans me gêner de marteler mon bouton de retour arrière de façon répétée juste pour supprimer l’indentation. et une ampoule s'allume dans ma tête.

J'ai ouvert le logiciel Logitech, défini 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 et l’autre effectue un retour arrière quatre fois. Incroyable. Juste incroyable. Tellement facile de toucher 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. Allez chercher un clavier Logitech G105 et tous vos problèmes disparaîtront!

Je viens 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 uniquement par PEP-8. Sublime Text 2 fait un excellent travail de visualisation des onglets avec la ligne pointillée verticale verticale et blanc cassé. Bien que, dans certains cas, je mélange un espace ou deux pour aligner des éléments d’une liste ou d’un dictionnaire, je n’ai jamais eu la possibilité de le faire. ê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 vous choisissez 4 onglets d'espaces et insérez 10 onglets, il reste de l'espace pour 40 caractères afin de respecter la limite de 80 colonnes. Si un autre codeur préfère les tabulations de 8 espaces, la même ligne apparaîtra sur 120 caractères et non sur une ligne valide à 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 la différence.

Modifier: sujet associé: Conserver la longueur de ligne maximale Lorsque vous utilisez des tabulations 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 devant interagir avec la source au-delà de l'éditeur de choix et quels que soient les paramètres configurés. dans.

Comme exemples concrets, considérons le rendu des docstrings Python dans une info-bulle dans Code Visual Studio . , ou dans un outil de diff comme Au-delà de la comparaison ou WinMerge , outils de performance ou de couverture de code, etc. En gros, tous ces autres outils d'interfaçage peuvent avoir des paramètres différents pour l'interprétation des onglets. être ennuyeux et parfois déroutant à l'idée de trouver des choses très différentes ou très éloignées de l'écran parmi les outils que vous pouvez explorer.

En bref, vous définissez l'alignement dans la source plutôt que de vous disputer 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 la mise en oeuvre / configuration d'un onglet tiers.

Un autre angle est la copie de la source des onglets principaux à exécuter sur un terminal où le caractère de tabulation peut déclencher une fin 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 cohérence entre les outils était le signe de l'esprit de discernement d'un développeur perspicace cherchant à commander le monde, ce qui indiquerait peut-être un indice de la différence de salaire constatée sur Stack & nbsp; Overflow .)

J'utilise une indentation de deux espaces et un éditeur (kwrite) qui insère des espaces au lieu de tabulations lorsque j'appuie sur la touche de tabulation.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow