Python: utiliser 4 espaces pour l'indentation. Pourquoi?
Lors du codage 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.
Alors, quelqu'un peut-il me convaincre d'utiliser 4 espaces au lieu de 2? Quels avantages et inconvénients?
P.S. Et enfin, quel moyen facile de convertir toute la base de code existante de 2 espaces en 4 espaces?
P.P.S. PEP-8 Recommande également strictement de ne pas utiliser les onglets pour l'indentation. lire ici
Donc, pour résumer:
Avantages:
- Ayez plus d'espace pour organiser lorsque vous enroulez une chaîne de plus de 80 lignes.
- Peut copier du code à partir d'extraits de code et cela fonctionne.
Les inconvénients:
- Avec un niveau plus profond d'instructions imbriquées, vous disposez de moins d'espace pour le code réel.
Merci.
Tout le monde utilise 4 espaces. C'est la seule raison d'utiliser 4 espaces que j'ai rencontrés et acceptés. Dans mon cœur, je veux toujours utiliser des tabulations (1 caractère de retrait par retrait, a du sens, non? Séparer le retrait des autres espaces. Je me fiche que les tabulations puissent être affichées avec des largeurs différentes, qui ne fait aucune différence syntaxique. Le pire qui puisse arriver est que certains commentaires ne s'alignent pas. L'horreur!) mais je l'ai accepté depuis que la communauté python dans son ensemble utilise 4 espaces, j'utilise 4 espaces. De cette façon, je peux assembler du code à partir d'extraits de code que d'autres ont écrits, et tout fonctionne.
J'aime le fait que quatre caractères d'espace indentent bien le code interne d'une fonction, car def + un espace fait quatre caractères.
def·foo():
····pass
Je pense que la vraie question est pourquoi les espaces et non les tabulations.
Les onglets sont clairement meilleurs:
- Cela fait presque impossible d'avoir une indentation incohérente (j'ai vu du code qui a normalement 4 espaces en retrait, mais certaines parties se trouvent être à un espace, il est difficile de dire par simple inspection s'il y en a 7 ou 8 espaces ... Cela ne se produirait pas avec des tabulations, sauf si vous définissez votre tabstop sur 1 espace).
- Tab est une représentation --- sémantique logique pour l'indentation, il vous permet (et à tout autre développeur) de choisir afficher autant "d'espaces" (ou plutôt de colonnes) que vous voulez sans salir avec les préférences des autres.
- C'est aussi moins de frappes si vous n'avez qu'un "bloc-notes" (ou un autre éditeur factice) à portée de main.
- L'ajout et la suppression d'onglets est une opération symétrique. La plupart des IDE peuvent insérer automatiquement 4 espaces lorsque vous appuyez sur la touche de tabulation, mais en général, ils ne suppriment qu'un seul espace lorsque vous appuyez sur le retour arrière (l'opération de retrait est toujours accessible en tant que touche Maj, mais c'est une combinaison de deux touches) ou vous utilisez la souris pour cliquer au milieu de l'indentation et supprimez un caractère.
- Ils prennent seulement 1 octet au lieu de 4 (multipliez par des milliers de lignes et vous économisez quelques Ko!: P)
- Vous avez une chose de moins pour régler un accord, car si vous décidez d'aller chercher des espaces, alors la discussion recommence pour 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 le focus (bien que vous puissiez en coller un).
Il n'y a pas de "meilleure" indentation. C'est un sujet religieux de la guerre sainte. Quatre, c'est bien parce que c'est suffisant pour rendre l'indentation claire, mais pas tellement que tout votre écran est principalement composé d'espaces et vous devez faire défiler horizontalement pour lire la moitié du programme.
Il a également l'avantage d'être un "demi-onglet" avec la définition historique d'un "onglet".
Autre que cela, utilisez ce que votre groupe aime. C'est comme le chocolat contre la vanille.
Un moyen simple de basculer consiste à utiliser un éditeur prenant en charge les tabulations et les tabulations spatiales. Convertissez tous vos tabulations d'espace en tabulations, définissez la taille de la tabulation sur quatre, puis reconvertissez les tabulations en tabulations d'espace.
Assez facile à faire avec un script python aussi. Il suffit de compter tous les espaces de tête, puis d'ajouter la même quantité au début de la ligne et de l'écrire.
Le PEP n'est pas votre patron. S'il est déjà uniformément en retrait de 2 espaces, il n'y a aucune raison de modifier tout votre code pour s'y conformer. Vous pouvez le suivre à l'avenir si vous pensez vraiment que c'est aussi vital, mais, franchement, je ne le fais pas. Vous feriez mieux de suivre la convention qui vous fournit (ainsi qu'à vos collègues) le plus de confort à la fois en lecture et en écriture.
Tout éditeur décent (emacs, vim) résumera tout ce non-sens pour vous. Il fonctionnera aussi bien avec des espaces ou des tabulations, 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 de tabulation). Il peut également convertir entre les différents formats sans trop de problèmes (voir le :retab commande dans vim).
Si vous essayez de convertir le formatage source en masse, je vous recommande de jeter un œil à l'utilitaire indent .
Cela dit, je ne peux pas résister à répondre à l'autre question ... Ma préférence a toujours été pour les onglets, car cela contourne tout le problème et tout le monde peut afficher le code source avec les largeurs définies comme bon leur semble. C'est également beaucoup moins de frappe lorsque vous travaillez dans des éditeurs qui ne sont pas utiles pour le convertir. En ce qui concerne 2 vs 4 espaces, c'est purement cosmétique.
Une des raisons est également la suivante: lorsque vous avez une longue ligne (plus de 80 symboles) et que vous souhaitez la diviser en 2, vous n'aurez qu'un seul espace à mettre en retrait, ce qui est un peu déroutant:
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'aucune norme de codage n'impose un style particulier, utilisez tout ce qui vous convient. Personnellement (et conformément à notre norme de codage), j'utilise des onglets durs pour que quiconque regarde le code puisse utiliser ses propres préférences.
Pour effectuer une modification, il vous suffit de remplacer tous les espaces de début de ligne par des espaces deux fois plus volumineux. Il existe plusieurs façons de procéder; dans l'éditeur de texte Vim, je peux penser à deux: premièrement:
:%s/^\(\s\{2}\)\+/\=repeat(' ', len(submatch(0))*2)
Il s'agit d'une expression régulière simple qui recherche 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, de nombreux autres outils offriront des fonctionnalités similaires: je serais surpris si quelque chose comme sed, awk, Perl ou python ne pouvait pas le faire très facilement.
Les normes d'identification et de style de codage général varient d'une langue à l'autre, d'un projet à l'autre. Il y a une raison pour adopter une norme de style de codage: pour que le code soit uniforme, peu importe qui l'a écrit. Cela améliore la lisibilité du projet et, pour le dire franchement, il a meilleure apparence.
Il y a une raison qui n'est pas valable 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 varient, et si elles étaient laissées à elles-mêmes, le chaos s'ensuivrait, au détriment de tous.
Si vous écrivez du code pour vous seul, que personne ne lira jamais, allez-y et écrivez-le comme vous le souhaitez. Sinon, suivre le standard accepté de votre communauté rendra votre code beaucoup plus agréable aux yeux de tous. Et rappelez-vous également que si vous décidez de contribuer du code à une communauté à l'avenir, vous aurez plus de facilité si vous êtes déjà habitué à leur style de codage.
En ce qui concerne la modification de la taille des onglets, il existe de nombreux formateurs de code source qui prennent en charge Python, et la plupart des éditeurs et IDE du programmeur ont également cette capacité. Vous l'avez probablement déjà, il suffit de consulter la documentation de l'éditeur que vous utilisez.
Si vous voulez écrire du code python avec d'autres programmeurs, cela devient un problème si vous utilisez un retrait différent pour eux. La plupart des programmeurs Python ont tendance à utiliser 4- indentation de l'espace.
L'une des raisons est que si vous utilisez moins d'espaces pour l'indentation, vous pourrez imbriquer plus d'instructions (car la longueur de ligne est normalement limitée à 80).
Maintenant, je suis presque sûr que certaines personnes ne s'entendent toujours pas sur le nombre de constructions imbriquées qui devrait être le maximum.
Il est plus facile d'identifier visuellement les longs blocs de code imbriqués avec 4 espaces. Gain de temps lors du débogage.
utiliser 4 espaces ou 2 espaces dépend entièrement de vous. 4 espaces n'est qu'une convention. Le plus important, ne mélangez pas les tabulations et les espaces. Utilisez la barre d'espace