Quelques règles à suivre pour produire un code qui sastisfait les normes proposées par les développeurs de Python, consultables dans leur intégralité dans la langue de Shakespeare ici. En voici un résumé.

Code layout

  • Indentation composée de 2 espaces (pas de tabulations). Bien que soit conseillée une indentation de 4 espaces, utiliser 2 espaces ne gêne pas la lecture et permet de mieux faire tenir le code sur 80 colonnes.
  • Longueur de ligne limitée à 79 caractères ; en cas de dépassement, utiliser la convention suivante :
def __init__(self, width, height,
             color='black', emphasis=None, highlight=0):
    if width == 0 and height == 0 and \
       color == 'red' and emphasis == 'strong' or \
       highlight > 100:
        raise ValueError("sorry, you lose")
    if width == 0 and height == 0 and (color == 'red' or
                                       emphasis is None):
        raise ValueError("I don't think so")
    Blob.__init__(self, width, height,
                  color, emphasis, highlight)
  • Séparer la première méthode d’une classe et la définition de la classe par deux lignes blanches.
  • Séparer les méthodes d’une classe par une ligne blanche.
  • Des lignes vides suplémentaires peuvent être utilisées pour séparer des groupes de fonctions.
  • Les fonctions définies sur une lignes peuvent ne pas être séparées par une ligne.
  • Encodage en Latin-9. La deuxième ligne de chaque module sera la suivante :
# -*- coding: iso-8859-15 -*-

Importation de modules

* Faire les imports en début de fichier, après la docstring du module.
* importer les modules ou paquetages sur des lignes séparées. Ne pas faire :
import sys, os

mais :

import os
import sys

Cependant, pour des modules d’un même paquetage, on peut utiliser la syntaxe suivante :

from subprocess import Popen, PIPE
  
* Regrouper les imports, en commençant par les librairies standards, puis les librairies tierces et enfin, les librairies locales, en séparant les groupes par un espace.
  • Pour des imports intra-paquetages dans un paquetage, utliser le chemin complet dans ce paquetage.
  • L’import de classes d’un modules est fait comme celà :
from foo.bar.mon_module import Ma_classe

En cas d’erreur, utiliser :

import foo.bar.mon_module

Et acceder à la classe comme suit :

mon_module.Ma_classe()

Utilisation des espaces dans les expressions

Les exemples suivants de ce qu’il faut et ne faut pas faire sont explicites :

  • Dans les parenthèses et crochets, ne pas faire :
spam( ham[ 1 ], { eggs: 2 } )

préférer :

spam(ham[1], {eggs: 2})
  • Après une virgule, un point virgule, ne pas faire :
if x == 4 : print x , y ; x , y = y , x

préférer :

if x == 4: print x, y; x, y = y, x
  • Pour une fonction, un dictionnaire, une liste, ne pas faire :
spam (1)
dict ['key'] = list [index]

préférer :

spam(1)
dict['key'] = list[index]
  • Bien que déconseillé dans le PEP8, ajouter des espaces pour aligner des déclarations est plus lisible dans certains cas.
x             = 1
y             = 2
long_variable = 3
  • Entourer les opérateurs binaires et arithmétiques d’un espace de chaque côté. Donc, ne pas faire :
i=i+1
submitted +=1
x = x*2 - 1
hypot2 = x*x + y*y
c = (a+b) * (a-b)

préférer :

i = i + 1
submitted += 1
x = x * 2 - 1
hypot2 = x * x + y * y
c = (a + b) * (a - b)
  • Dans les arguments de fonctions, ne pas entourer les opérateurs d’espaces pour les paramètres par défaut :
def complex(real, imag = 0.0):
    return magic(r = real, i = imag)

préférer :

def complex(real, imag=0.0):
    return magic(r=real, i=imag)

* Ne pas regrouper des déclarations sur une même ligne :

if foo == 'blah': do_blah_thing()
do_one(); do_two(); do_three()

préférer :

if foo == 'blah':
    do_blah_thing()
do_one()
do_two()
do_three()

Commentaires

  • Rédiger les commentaires en anglais.
  • Commencer un commentaire par une majuscule et le terminer par un point (c’est une phrase !).
  • Placer les commentaires avant le code, sur le même niveau d’indentation.
  • Un commentaire commence par un dièse suivi d’un espace.
  • Les paragraphes dans un bloc de commentaires sont séparés par une ligne :
#.
  • Eviter les commentaire “inline” (sur la même ligne que le code).
  • Ne pas trop commenter, ou commenter inutilement, du style :
x = x + 1                 # Increment x

Docstring

Les docstring sont des chaînes de caractères que Python utilise pour générer la documentation via pydoc. Les bonnes pratiques sont détaillées dans la PEP0257.

La docstring est la première ligne qui suit la ligne de définition de la classe, la fonction. La syntaxe est la suivante :

def my_method():
    """Return a foobang

    Optional plotz says to frobnicate the bizbaz first.

    """

Ou si le commentaire tient sur une ligne :

def my_method():
    """Return a foobang."""

Conventions de nommage

Les conventions de nommages utilisées en Python sont :

  • CapWords

Nom de module

Notamment pour des raisons de compatibilité avec certains OS, les modules, qui portent le nom du fichier, doivent avoir un nom court, en minuscules et sans underscores.

Nom de classe

Utiliser la convention CapWords, préfixé un underscore si la classe est à usage interne.

exemples :


class UneClasseExterne:

class _UneClasseInterne:

Pour les classes d’exceptions qui attrapent les erreurs, utiliser le suffixe Error.

class MessageError(Exception):
    """Base class for errors in the email package."""

Nom de fonction

Les noms de fonctions sont en minuscules et avec des underscores.

Nom de méthode

Idem que pour les noms de fonctions, avec un underscore pour une méthode privée.

Arguments des méthodes

Le premier argument d’une méthode d’instance est self. Pour une méthode de classe, utiliser cls.

Variables (et attributs) de classes (et d'instances)

  • Les attributs publics ne possèdent pas d’underscore comme premier caractère. Ajouter un underscore en fin de nom s’il y a risque de conflit. FIXME voir les properties dans les nouvelles classes
  • Un attribut d’une classe sous-classée non-accessible par cette sous-classe sera nommé en commençant par un double-underscore.

Recommandations de programmation

  • Ne pas utiliser if x pour dire if x is not None.
  • Pour les tests sur les singletons tel None, utiliser is et is not.
  • Utiliser les exceptions sous formes de classes, pas de chaînes.
  • Utiliser les méthodes string, pas le module string.
  • Le test des type d’objets doit se faire via la méthode isinstance(), ne pas faire une comparaison avec l’opérateur is. Pour tester le type string, utiliser comme classe de comparaison basestring.
if isinstance(une_chaine, basestring):
    ...
  • Ne pas comparer des booléens à True ou False avec les opérateurs == ou is.

Fichiers types

Tous les modules, même les init.py de packages doivent comporter une docstring.

#! /usr/bin/env python
# -*- coding: iso-8859-15 -*-
# Copyright (C) 2006 Aiddiag Team <stanislas.guerra@etu.univ-lille2.fr>
#
"""here the docstring.


"""

__version__ = '0.1'
__author__ = "Stanislas Guerra"
__author_email__ = "first-name dot last-name @ gmail.com"
__date__ = "2006-07-07"

# here the imports

# here the code



# the module's demonstration.
if __name__ == '__main__':
  print "Entering demo."

 
gnu/python/style_guide_fr.txt · Dernière modification: 2007/03/16 21:56
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki