← Blog · 15 avril 2026 · L'équipe ConvertCaseHQ · 8 min de lecture

Nommage en Python selon PEP 8 : snake_case pour les variables et les fonctions

PEP 8 dit que les noms de fonctions et de variables doivent être en minuscules, avec des mots séparés par des tirets bas selon les besoins de la lisibilité. C'est du snake_case : total_price, send_invoice(). Les classes utilisent CapWords (InvoiceSender), les constantes des majuscules avec des tirets bas (MAX_RETRIES), et les modules reçoivent des noms courts, tout en minuscules. Cela couvre l'essentiel du Python que vous écrirez.

Le reste de la section de PEP 8 sur le nommage est l'endroit où se trouve le détail utile : ce que signifient les tirets bas initiaux et finaux, comment traiter les sigles, quelles lettres isolées éviter, et quand enfreindre les règles est le bon choix. Tout ce qui suit est vérifié d'après PEP 8 lui-même, et ce qui est cité entre guillemets en anglais reprend la formulation même de PEP 8.

Les conventions de nommage de PEP 8 en un coup d'œil

Voici l'essentiel du tableau dans un petit module :

# billing.py
MAX_RETRIES = 3
_rate_cache = {}


class PaymentDeclinedError(Exception):
    pass


class InvoiceSender:
    def __init__(self, smtp_host):
        self.smtp_host = smtp_host
        self._attempts = 0

    def send_invoice(self, invoice_id):
        self._attempts += 1
        ...

    @classmethod
    def from_settings(cls, settings):
        return cls(settings["smtp_host"])

Deux lignes plus rares méritent d'être connues. Les variables de type peuvent prendre un suffixe _co ou _contra pour marquer la covariance ou la contravariance, comme dans VT_co = TypeVar('VT_co', covariant=True). Quant aux variables globales, elles suivent les règles des fonctions ; si un module est conçu pour être utilisé avec from module import *, PEP 8 recommande de lister ses noms publics dans __all__.

Pourquoi du snake_case, au fait ?

PEP 8 date de juillet 2001, et il a pour auteurs déclarés Guido van Rossum, Barry Warsaw et Alyssa Coghlan. Son point de départ est une observation de Guido : le code se lit beaucoup plus souvent qu'il ne s'écrit. Les règles de nommage servent cet objectif. Les tirets bas gardent visibles les frontières entre les mots, même dans les noms longs (days_since_last_login), et la séparation entre valeurs en snake_case et classes en CapWords vous dit de quelle sorte de chose il s'agit avant même que vous la cherchiez. PEP 8 pose aussi un principe qui prime pour les API publiques : les noms doivent refléter la façon dont une chose s'utilise, pas la façon dont elle est implémentée.

Ce que signifient les tirets bas

Python n'a pas de mot-clé private ; ce sont donc les tirets bas qui jouent ce rôle, par convention. PEP 8 reconnaît quatre formes :

• _single_leading : un signal faible d'« internal use » (usage interne). from module import * ignore ces noms, mais rien d'autre n'empêche de les utiliser.
• single_trailing_ : évite un conflit avec un mot-clé. class_ vaut mieux que clss, même si PEP 8 note qu'un synonyme peut être encore préférable.
• __double_leading : à l'intérieur d'une classe, déclenche le name mangling (altération des noms). PEP 8 ne le suggère que pour éviter des conflits avec des attributs dans les sous-classes, et admet que certains ne l'aiment pas.
• __double_leading_and_trailing__ : des noms « magic » comme __init__ et __file__. PEP 8 dit de ne jamais en inventer ; n'utilisez que ceux qui sont documentés.

Le name mangling surprend ceux qui le prennent pour de la confidentialité. C'est un renommage, pas un verrou :

class Account:
    def __init__(self):
        self.__pin = "1234"

acct = Account()
acct.__pin            # AttributeError
acct._Account__pin    # "1234": the mangled name still works

Les constantes sont une convention, pas une règle

Écrire un nom en majuscules n'empêche personne de le réaffecter ; Python exécutera sans broncher MAX_RETRIES = 4. Si vous voulez qu'un outil l'impose, annotez le nom avec typing.Final :

from typing import Final

MAX_RETRIES: Final = 3
MAX_RETRIES = 4  # still runs, but mypy reports:
                 # Cannot assign to final name "MAX_RETRIES"

Les membres d'une énumération sont l'autre endroit où apparaissent des majuscules. Le HOWTO sur les enums de la documentation Python recommande fortement des noms de membres en UPPER_CASE, en partie parce que les énumérations représentent des constantes et en partie pour éviter les conflits avec des noms de méthodes : class Color(Enum) avec les membres RED et GREEN.

Sigles, lettres isolées et autres cas limites

Les sigles dans les noms de classes

PEP 8 demande de mettre en majuscules chaque lettre d'un sigle en CapWords : HTTPServerError vaut donc mieux que HttpServerError. La bibliothèque standard le respecte à certains endroits, comme http.server.HTTPServer et json.JSONDecodeError. En snake_case, les sigles passent simplement en minuscules : parse_json, http_status.

Cela compte si vous renommez avec un outil. Notre convertisseur de casse transforme processOrder en process_order et HTTPServerError en http_server_error, ce qui est exactement ce qu'il faut pour du snake_case. Mais sa sortie PascalCase écrit les sigles comme des mots : HTTP server error devient HttpServerError, et vous devrez corriger les majuscules à la main pour respecter PEP 8.

Les lettres à éviter

N'utilisez jamais l (L minuscule), O (o majuscule) ou I (i majuscule) comme noms d'un seul caractère. Dans certaines polices, ils sont impossibles à distinguer de 1 et de 0.

mixedCase

Les noms de fonctions en camelCase ne sont admis que là où c'est déjà le style dominant, par souci de compatibilité ascendante. L'exemple de PEP 8 lui-même est le module threading.

Pourquoi la bibliothèque standard enfreint ses propres règles

PEP 8 admet que le nommage dans la bibliothèque de Python est « a bit of a mess » (un peu en désordre). Vous rencontrerez logging.getLogger() et assertEqual() de unittest en mixedCase, ainsi que des classes en minuscules comme datetime.datetime. Les types intégrés comme list et dict sont en minuscules à dessein : PEP 8 décrit une convention distincte pour les éléments intégrés, avec CapWords réservé aux noms d'exceptions et aux constantes intégrées.

Deux règles de PEP 8 expliquent pourquoi ces noms restent pour l'essentiel ce qu'ils sont. D'abord, quand une bibliothèque existante a un style différent, la cohérence interne est préférée. Ensuite, la section intitulée « A Foolish Consistency is the Hobgoblin of Little Minds » (une sotte cohérence est le croquemitaine des petits esprits) : la cohérence avec PEP 8 compte, la cohérence au sein d'un projet compte davantage, et la cohérence au sein d'un module ou d'une fonction compte le plus. Ne cassez pas la compatibilité ascendante rien que pour vous conformer. C'est pourquoi une classe de test unittest définit toujours setUp() : le framework appelle précisément ce nom.

Vérifier les noms automatiquement avec Ruff ou pep8-naming

Inutile de relire les noms à l'œil. Le plugin flake8 pep8-naming les vérifie, et Ruff implémente les mêmes contrôles sous ses règles N. Prenons ce fichier :

maxRetries = 3


class order_processor:
    def processOrder(self, orderId):
        totalPrice = 0
        return totalPrice


class InvalidOrder(Exception):
    pass

Ruff signale chacun de ses noms :

$ ruff check --select N --output-format concise orders.py
orders.py:1:1: N816 Variable `maxRetries` in global scope should not be mixedCase
orders.py:4:7: N801 Class name `order_processor` should use CapWords convention
orders.py:5:9: N802 Function name `processOrder` should be lowercase
orders.py:5:28: N803 Argument name `orderId` should be lowercase
orders.py:6:9: N806 Variable `totalPrice` in function should be lowercase
orders.py:10:7: N818 Exception name `InvalidOrder` should be named with an Error suffix
Found 6 errors.

Pour activer ces règles sur tout un projet, ajoutez-les à pyproject.toml :

[tool.ruff.lint]
extend-select = ["N"]

Quand vous renommez un seul identifiant dans un fichier collé, notre outil Rechercher & remplacer indique combien de correspondances il a modifiées, ce qui offre un contrôle rapide avant de recoller le résultat. Pour toute une base de code, utilisez plutôt la fonction de renommage de votre éditeur, afin que les références dans les autres fichiers suivent.

Une liste de contrôle pour le nommage PEP 8

• snake_case pour les fonctions, méthodes, variables et arguments.
• CapWords pour les classes, avec les sigles en majuscules et un suffixe Error sur les exceptions.
• Majuscules avec tirets bas pour les constantes de niveau module, plus Final si vous voulez qu'un vérificateur les impose.
• Des noms de modules courts et en minuscules ; pas de tirets bas dans les noms de paquets.
• Un tiret bas initial pour les noms internes ; des doubles tirets bas seulement pour éviter les conflits avec les sous-classes.
• Quand une bibliothèque existante emploie un autre style, alignez-vous sur la bibliothèque.

Vous passez d'un langage à l'autre ? Notre aide-mémoire pour développeurs met les règles de Python en regard de celles de JavaScript, Java, Go, Rust et d'autres.