Quelques astuces pour rendre votre code Python plus lisible avec PEP-8
En suivant PEP-8, la lisibilité et la cohérence de votre code Python sont améliorées.
Un petit œuf de Pâques est si vous l'importez dans un fichier python.
import this
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
L'un des auteurs de PEP-8, Guido van Rossum, a déclaré que "le code est lu beaucoup plus souvent qu'il n'est écrit". Une fois que le code est écrit dans un projet, il ne sera plus écrit, mais il sera revisité par le créateur ou quelqu'un de nouveau. La lisibilité est importante pour que le code soit facile à comprendre comment il fonctionne et pourquoi.
Un autre avantage d'avoir un code lisible est qu'il fait preuve de professionnalisme. Lorsqu'il s'agit d'un employeur ou de nouveaux collaborateurs, il est important d'avoir ces directives de base pour faciliter la lecture de votre code par les autres. Alors, commençons.
Échancrure
PEP-8 recommande 4 espaces pour le niveau d'indentation, mais personnellement, l'utilisation d'espaces entraîne beaucoup plus de travail de suppression et de formatage, donc je m'en tiens aux onglets. Tous les éditeurs de texte, sauf les plus basiques, ont un paramètre pour convertir les tabulations en espaces. Qui tape réellement 4 espaces à chaque fois ? Il est important de noter que mélanger les tabulations et les espaces est un non-non car Python distingue les deux et s'assure que tout le monde sur un projet est sur la même page.
Maintenant, en ce qui concerne l'indentation suspendue, qui est un style de composition où toutes les lignes d'un paragraphe sont en retrait sauf la première ligne, il y a quelques éléments à prendre en compte.
- Il s'agit d'un style en Python sur la façon de formater une déclaration entourée de parenthèses.
- Il ne doit y avoir aucun argument sur la première ligne.
- Une indentation supplémentaire doit être utilisée pour se distinguer clairement en tant que ligne de continuation.
# Correct:
# Aligned with opening delimiter.
foo = long_function_name(var_one, var_two,
var_three, var_four)
# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
# Hanging indents should add a level.
foo = long_function_name(
var_one, var_two,
var_three, var_four)
# Wrong:
# Arguments on first line forbidden when not using vertical alignment.
foo = long_function_name(var_one, var_two,
var_three, var_four)
# Further indentation required as indentation is not distinguishable.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
# No extra indentation.
if (this_is_one_thing and
that_is_another_thing):
do_something()
# Add a comment, which will provide some distinction in editors
# supporting syntax highlighting.
if (this_is_one_thing and
that_is_another_thing):
# Since both conditions are true, we can frobnicate.
do_something()
# Add some extra indentation on the conditional continuation line.
if (this_is_one_thing
and that_is_another_thing):
do_something()
my_list = [
1, 2, 3,
4, 5, 6,
]
result = some_function_that_takes_arguments(
'a', 'b', 'c',
'd', 'e', 'f',
)
my_list = [
1, 2, 3,
4, 5, 6,
]
result = some_function_that_takes_arguments(
'a', 'b', 'c',
'd', 'e', 'f',
)
La façon préférée d'envelopper les longues lignes est la continuation de ligne implicite entre parenthèses, crochets et accolades. Cela devrait être utilisé de préférence à l'utilisation d'une barre oblique inverse pour la continuation de la ligne.
Mais la barre oblique inverse est toujours appropriée à des moments tels que les déclarations with et assert .
with open('/path/to/some/file/you/want/to/read') as file_1, \
open('/path/to/some/file/being/written', 'w') as file_2:
file_2.write(file_1.read())
Pendant des décennies, le style recommandé était de casser après les opérateurs binaires. Mais cela peut nuire à la lisibilité de deux manières :
- Les opérateurs ont tendance à se disperser sur différentes colonnes à l'écran.
- Chaque opérateur est déplacé de son opérande vers la ligne précédente.
Ici, l'œil doit faire un travail supplémentaire pour dire quels éléments sont ajoutés et lesquels sont soustraits :
# Wrong:
# operators sit far away from their operands
income = (gross_wages +
taxable_interest +
(dividends - qualified_dividends) -
ira_deduction -
student_loan_interest)
Suivre la tradition des mathématiques aboutit généralement à un code plus lisible :
# Correct:
# easy to match operators with operands
income = (gross_wages
+ taxable_interest
+ (dividends - qualified_dividends)
- ira_deduction
- student_loan_interest)
Importations
Les importations doivent généralement figurer sur des lignes distinctes :
# Correct:
import os
import sys
# Wrong:
import sys, os
# Correct:
from subprocess import Popen, PIPE
Les importations doivent être regroupées dans l'ordre suivant :
- Importations de bibliothèque standard.
- Importations de tiers connexes.
- Importations spécifiques à une application/bibliothèque locale.
https://peps.python.org/pep-0008/#introduction