Un petit billet pour parler de bonnes habitudes à prendre le plus tôt possible.
Il existe en python des guides de bonnes pratiques appelés PEP (pour Python Enhancement Proposals).
La PEP 8 (Style Guide for Python Code) est particulièrement intéressante. Elle donne des règles de présentation du code pour le rendre le plus lisible et conventionnel possible : tout programmeur en python digne de ce nom se doit de la respecter !
Voici aussi un lien vers une note d’un collègue à propos de print et surtout input dont l’utilisation est d’un autre temps et qu’il faudra s’empresser de proscrire et remplacer par l’utilisation de fonctions.
Petite synthèse de ce que dit la PEP 8 (il existe même des modules permettant de contrôler si un script python est conforme à cette PEP !)
- Les lignes doivent d’être d’au plus 79 caractères. On peut passer à la ligne dans dans une énumération (séparée par des virgules), ou en utilisant le caractère
\ avant de passer à la ligne.
On peut aussi aller à la ligne dans une suite d’opérateurs binaires mais il faut que l’opérateur soit à la ligne (comme en maths) :
OUI :
tout = (premier + deuxieme + troisieme - quatrieme)
|
NON :
tout = (premier + deuxieme + troisieme - quatrieme)
|
- Sauter des lignes entre les fonctions ou (avec parcimonie tout de même) dans les fonctions pour séparer des "blocs logiques".
- Encoder les fichiers en
UTF-8. - Ne mettez pas plusieurs import sur une même ligne :
OUI :
import numpy import matplotlib
|
NON :
|
Éviter d’importer directement toutes les fonctions d’un module avec from <module> import * car, en cas d’homonymie d’une fonction dans les différents modules importés, il peut être difficile (et gênant !) de savoir de quel module elle provient lorsqu’on l’utilise.
- Utiliser des espaces pour aérer votre code. : vous verrez, ce sera beaucoup plus agréable à lire et surtout beaucoup plus facile à débugger !
- Pas d’espace intérieur aux parenthèses, crochets, accolades.
OUI :
test(valeur[1], {quantite: 3})
|
NON :
test( valeur[ 1 ], { quantite: 3 } )
|
- Une espace après mais pas avant une virgule, une point-virgule, deux-points :
OUI :
if x == 4: print(x, y) x, y = y, x
|
NON :
if x == 4 : print(x , y) x , y = y , x
|
SAUF si les deux-points sont utilisés pour faire du slicing : autant de chaque côté, et jamais d’espace entre deux : consécutifs.
OUI :
ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:] ham[:: step_fn(x)] ham[lower + offset : upper + offset]
|
NON :
ham[1: 9], ham[1 :9], ham[1:9 :3] ham[lower : : upper] ham[lower + offset:upper + offset] ham[ : upper]
|
- Jamais d’espace avant des parenthèses d’appel d’une fonction ou des crochets de slicing.
OUI :
fonction(1) liste_a[3] = liste_b[2]
|
NON :
fonction (1) liste_a [3] = liste_b [2]
|
- Jamais plus d’une espace autour d’un opérateur d’affectation
OUI :
x = 1 y = 2 long_variable = 3
|
NON :
x = 1 y = 2 long_variable = 3
|
- Entourer d’espaces les opérateurs :
=, +=, -=, (etc.), ==, <, >, !=, <>, <=, >=, in, not in, is, is not, and, or, not, +, -, *, %, /, //, etc. On peut éventuellement ne pas entourer d’espaces les opérateurs ayant la priorité la plus forte.
OUI :
i = i + 1 i += 1 i = i * 2 x = x*2 - 1 x = x * 2 - 1
|
NON :
|
- Ne pas utiliser d’espace autour du signe
= pour désigner un argument d’une fonction.
OUI :
def complex(real, imag=0.0): return magic(r=real, i=imag)
|
NON :
def complex(real, imag = 0.0): return magic(r = real, i = imag)
|
- Ne pas mettre plusieurs instructions sur une même ligne.
OUI :
if chose == 'bla': faire_la_chose_bla() faire_un() faire_deux() faire_trois()
|
NON :
if chose == 'bla': faire_la_chose_bla() faire_un(); faire_deux(); faire_trois()
|
- Éviter les
if/for/while sur une seule ligne.
PREFERER :
if test: faire_quelquechose() for x in liste: faire_quelquechose() while t < 10: faire_quelquechose()
|
EVITER :
if test: faire_quelquechose() for x in liste: faire_quelquechose() while t < 10: faire_quelquechose()
|
- Commenter le code : ni trop, ni trop peu. Avec des
# plutôt que des chaînes de caractères. - Documenter les fonctions : les docstrings sont des chaînes de caractères sur la première ligne de la fonction décrivant son utilisation. C’est ce qui est obtenu avec
help(fonction). Leur utilisation est décrite dans la PEP 257.
def fonction(arguments): """Cette fonction prend (des choses) en arguments et renvoie (d'autres choses)."""
|
- A propos des noms à donner aux variables :
- Eviter les caractères
l, o, O, I qui ressemblent trop à 0 et 1. Si vous êtes tenté d’utiliser l, préférez L. - Compatibilité ASCII : pas de lettres accentuées, caractères spéciaux, etc.
- Les modules doivent avoir des noms courts, tout en minuscule (avec d’éventuels underscores
_). - Noms de fonctions en minuscules, avec underscores si nécessaire (et les noms de fonctions doivent être compréhensibles !) Éviter d’utiliser des noms déjà utilisés.
- Constantes en MAJUSCULES.
- La comparaison avec des constantes comme
None doivent se faire avec is, is not plutôt que ==, !=.
OUI :
if variable is not None: faire_des_choses()
|
NON :
if variable != None: faire_des_choses()
|
- Utiliser
is not plutôt que not ... is.
OUI :
if variable is not None: faire_des_choses()
|
NON :
if not variable is None: faire_des_choses()
|
- Il vaut mieux écrire
return None quand la fonction ne doit rien renvoyer.
OUI :
def foo(x): if x >= 0: return math.sqrt(x) else: return None def bar(x): if x < 0: return None return math.sqrt(x)
|
NON :
def foo(x): if x >= 0: return math.sqrt(x) def bar(x): if x < 0: return return math.sqrt(x)
|
Commentaires