Python: utiliser 4 espaces pour l'indentation. Pourquoi? [fermé]
en codant python j'utilise seulement 2 espaces pour indenter, bien sûr PEP-8 recommande vraiment d'avoir 4 espaces, mais historiquement pour moi c'est inhabituel.
est-ce que quelqu'un peut me convaincre d'utiliser 4 espaces au lieu de 2? Quels avantages et inconvénients?
P. S. et enfin, quel est le moyen facile de convertir tous les codes de base existants de 2 espaces à 4 espaces?
P. P.S. PEP-8 recommande également de ne pas utiliser des onglets pour l'indentation. lire ici
donc, pour résumer:
Pour:
- ont plus d'espace pour organiser lorsque wraping chaîne de plus de 80 lignes de long.
- peut copier le code à partir de snippets et il fonctionne tout simplement.
Inconvénients:
- avec un niveau plus profond de déclarations imbriquées vous avez moins espace pour le code réel.
Merci.
13 réponses
tout le monde utilise 4 espaces. C'est la seule raison d'utiliser 4 espaces que j'ai appris et accepté. Dans mon cœur, je veux toujours utiliser des onglets (1 caractère indent par indent, ça a du sens, non? Séparer le tiret des autres espaces. Je ne me soucie pas que les onglets peuvent être affiché comme des largeurs différentes, qui ne fait aucune différence syntaxique. Le pire qui puisse arriver est que certains commentaires ne sont pas alignés. L'horreur!) mais j'ai accepté cela depuis le python la communauté dans son ensemble utilise 4 espaces, j'utilise 4 espaces. De cette façon, je peux assembler le code à partir de morceaux que d'autres ont écrit, et tout fonctionne.
j'aime le fait que quatre caractères de l'espace indentent bien le code interne d'une fonction, parce que def + un espace fait quatre caractères.
def·foo():
····pass
je pense que la vraie question est pourquoi les espaces et pas les onglets.
Onglets sont nettement mieux:
- il rend presque impossible d'avoir indentation incohérente (j'ai vu le code qui a normalement 4 indents d'espaces, mais alors certaines pièces se trouvent être un espace hors, il est difficile de dire par simple inspection s'il y a 7 ou 8 espaces... Cela ne se produirait pas avec les onglets, à moins que vous définissiez votre tabstop à 1 espace).
- onglet est un logique représentation sémantique pour indentation, il vous permet (et à tout autre développeur) de choisir de afficher autant "d'espaces" (ou plutôt des colonnes) que vous voulez sans toucher aux préférences des autres.
- C'est aussi moins de touches si vous avez seulement "bloc-notes" (ou un autre mannequin de l'éditeur).
- ajouter et supprimer des onglets est un fonctionnement symétrique . La plupart des IDE peuvent insérer automatiquement 4 espaces lorsque vous appuyez sur la touche tab, mais habituellement ils suppriment seulement 1 espace lorsque vous appuyez sur backspace (l'opération un-indent est toujours accessible sous shift-tab, mais c'est une combinaison de deux touches) ou vous utilisez la souris pour cliquer au milieu de l'indentation et supprimer un caractère.
- ils prennent seulement 1 octet plutôt que 4 (multiplier par milliers de lignes et vous économisez quelques Ko! : p)
- vous avez une chose de moins à régler un accord, parce que si vous décidez d'aller pour les espaces, puis la discussion recommence à choisir combien (bien que le consensus semble être autour de quatre).
avantages des espaces:
- Guido les aime.
- vous ne pouvez pas facilement taper un onglet ici, il transfère la mise au point (bien que vous pouvez coller un).
il n'y a pas de" meilleure " indentation. C'est un sujet religieux de la guerre sainte. Quatre est agréable parce que c'est assez pour rendre l'indentation claire, mais pas tellement que votre écran entier est la plupart du temps blanc et vous devez faire défiler horizontalement pour lire la moitié du programme.
Il a également l'avantage d'être un "demi-onglet" w/r à la définition historique d'un "onglet."
sinon, utilisez ce que votre groupe veut. C'est comme le chocolat contre la vanille.
un moyen facile d'échanger est d'utiliser un éditeur qui a tab et tabulation de l'espace. Convertissez tous vos espaces-onglets principaux en onglets, réglez la taille de l'onglet à quatre, puis convertissez les onglets principaux de nouveau en espaces-onglets.
Assez facile à faire avec un script python. Juste compter tous les espaces de tête, puis ajouter le même montant au début de la ligne et de l'écrire.
le PEP n'est pas votre patron. S'il y a déjà toujours 2 espaces indentés, il n'y a aucune raison de changer tout votre code pour vous y conformer. Vous pourriez le suivre si vous pensez vraiment que c'est vital, mais, franchement, je ne le fais pas. Vous êtes mieux d'aller avec ce que la convention vous fournit (et vos collègues) le plus de confort à la fois dans la lecture et l'écriture.
N'importe quel bon éditeur (emacs, vim) va faire abstraction de tout ce non-sens pour vous. Il fonctionnera également bien avec les espaces ou les onglets, et il peut être configuré pour utiliser n'importe quel nombre d'espaces (ou n'importe quel nombre de largeurs d'espace pour un caractère d'onglet). Il peut également convertir entre les différents formats sans trop de problèmes (voir la commande :retab
dans vim).
si vous essayez de convertir le formatage source en vrac, je vous recommande de jeter un oeil à la tiret de l'utilitaire.
cela dit, je ne peux pas résister à répondre à l'autre question... Ma préférence a toujours été pour les onglets, car il contourne l'ensemble de la question et tout le monde peut voir le code source avec les largeurs définies comme ils le jugent bon. C'est aussi beaucoup moins taper quand vous travaillez dans des éditeurs qui ne sont pas utiles pour la convertir. Pour ce qui est de 2 contre 4 espaces, c'est purement esthétique.
aussi une des raisons est: quand vous avez une longue ligne (plus de 80 symboles) et que vous voulez la diviser en 2, vous aurez seulement 1 espace pour indenter, qui est un peu confus:
if code80symbolslong and somelongvariablegoeshere and somelongerthan80symbols \
and someotherstatementhere:
# some code inside if block
pass
if code80symbolslong and somelongvariablegoeshere and somelongerthan80symbols \
and someotherstatementhere:
# some code inside if block
pass
si vous êtes le seul codeur à travailler sur votre fichier source et qu'il n'existe aucune norme de codage qui impose un style particulier, utilisez ce qui vous convient. Personnellement (et conformément à notre norme de codage), j'utilise des onglets durs de sorte que quiconque regarde le code peut utiliser sa propre préférence.
pour faire un changement, vous avez simplement besoin de changer tous les espaces de début de ligne à ceux qui sont deux fois plus grands. Il y a plusieurs façons de faire cela; dans l'éditeur de texte Vim, Je peut penser à deux: premièrement:
:%s/^\(\s\{2}\)\+/\=repeat(' ', len(submatch(0))*2)
il s'agit d'une simple expression régulière qui cherche une ou plusieurs paires d'espaces au début de la ligne et les remplace par deux fois plus d'espaces que ceux trouvés. Il peut être étendu pour faire tous les fichiers en ouvrant vim avec:
vim *.py
(ou l'équivalent), suivi de (non testé):
:argdo %s/^\(\s\{2}\)\+/\=repeat(' ', len(submatch(0))*2)/ | w
alternativement:
" Switch to hard tabs:
:set noexpandtab
" Set the tab stop to the current setting
:set tabstop=2
" Change all spaces to tabs based on tabstop
:retab!
" Change the tab stop to the new setting
:set tabstop=4
" Go back to soft tabs
:set expandtab
" Replace all the tabs in the current file to spaces
:retab
bien sûr, beaucoup d'autres les outils offriront des fonctionnalités similaires: je serais surpris si quelque chose comme sed
, awk
, perl
ou python
ne pouvait pas faire ça très facilement.
Identation et générales style de codage normes varient d'une langue à l'autre, d'un projet à l'autre. Il y a une raison à l'adoption d'une norme de style de codage: pour que le code soit uniforme, peu importe qui l'a écrit. Cela améliore la lisibilité dans le projet, et, pour le dire franchement, il semble mieux.
il y a une raison qui n'est pas valide lors de l'adoption d'une norme de style de codage: parce que vous l'aimez. Les normes de codage existent précisément parce que les préférences des gens varier, et si on les laisse à leurs propres, le chaos s'ensuivra, au détriment de tous.
si vous écrivez un code pour vous-même, que personne ne lira jamais, allez-y et écrivez ce que vous voulez. Sinon, suivre la norme acceptée de votre communauté rendra votre code beaucoup plus agréable aux yeux de tout le monde. Et rappelez-vous aussi que si vous décidez de contribuer code à une communauté dans l'avenir, vous aurez un temps plus facile si vous êtes habitué à leur style de codage déjà.
en ce qui concerne la modification de la taille de l'onglet, il existe de nombreux formateursde code source qui prennent en charge Python, et la plupart des éditeurs de programmeurs et des IDEs ont également cette capacité. Vous avez probablement déjà, c'est juste une question de consultation de la documentation de l'éditeur que vous utilisez.
L'une des raisons est que si vous utilisez moins d'espaces pour l'indentation, vous serez en mesure de nicher plus d'énoncés (puisque la longueur de ligne est normalement limitée à 80).
maintenant je suis presque sûr que certaines personnes sont encore en désaccord sur le nombre de constructions imbriquées devrait être le maximum.
Si vous voulez écrire du code python avec d'autres programmeurs, il devient un problème si vous utilisez un autre renfoncement comme eux. La plupart des programmeurs Python ont tendance à utiliser l'indentation à 4 espaces.
utiliser 4 espaces ou 2 espaces est entièrement à vous. 4 espaces n'est qu'une convention. Ce qui est le plus important, Ne mélangez pas les onglets et les espaces. Utilisez la barre d'espace