---
title: "Style de code"
version: 6.0
locale: fr
source: https://docs.djangoproject.com/fr/6.0/internals/contributing/writing-code/coding-style/
canonical: https://djangodocs.dev/fr/6.0/internals/contributing/writing-code/coding-style/
---
# Style de code
Veuillez respecter ces standards de codage lorsque vous écrivez du code destiné à faire partie de Django.
## Vérifications « pre-commit »
[pre-commit](https://pre-commit.com) est un système de gestion des points d’ancrage d’avant commit. Ces points d’ancrage aident à identifier des problèmes simples avant de valider du code en vue d’un examen. En contrôlant ces problèmes avant l’examen du code, cela permet au relecteur de se concentrer sur les changement réels, et cela peut aussi réduire le nombre d’exécutions des tests en intégration continue.
Pour utiliser cet outil, installez d’abord `pre-commit`, puis les points d’ancrage git :
```console
$ python -m pip install pre-commit
$ pre-commit install
```
*Windows*
```doscon
...\> py -m pip install pre-commit
...\> pre-commit install
```
Lors du premier commit, `pre-commit` va installer les points d’entrée. Ils sont installés dans leur propre environnement et prendront un peu de temps à être installés lors de la première exécution. Les contrôle suivants seront nettement plus rapides. Si une erreur est trouvée, un message d’erreur approprié est affiché. Si l’erreur est due à `black` ou `isort`, l’outil en question va se charger de corriger l’erreur. Vérifier ces modifications et validez-les dans le commit si elles vous conviennent.
## Style Python
- Tous les fichiers doivent être écrits en utilisant l’outil de mise en forme automatique [black](https://pypi.org/project/black/). Cet outil sera lancé par `pre-commit` si celui-ci est configuré.
- Le dépôt du projet inclut un fichier `.editorconfig`. Nous recommandons d’utiliser un éditeur de texte avec prise en charge de [EditorConfig](https://editorconfig.org/) pour éviter des problèmes d’indentation et d’espace. Les fichiers Python utilisent 4 espaces pour l’indentation et les fichiers HTML 2 espaces.
- Sauf exception particulière, suivez les recommandations [**PEP 8**](https://peps.python.org/pep-0008/).
Utilisez [flake8](https://pypi.org/project/flake8/) pour détecter les problèmes de ce genre. Notez que notre fichier `.flake8` contient une exclusion de certains contrôles d’erreurs que nous ne considérons pas comme des violations graves. Souvenez-vous que [**PEP 8**](https://peps.python.org/pep-0008/) n’est qu’un guide, le respect du style du code environnant est l’objectif principal.
An exception to [**PEP 8**](https://peps.python.org/pep-0008/) is our rules on line lengths. We allow up to 88
characters in code, as this is the line length used by `black`.
Documentation, comments, and docstrings should be wrapped at 79 characters.
These limits are checked when `flake8` is run.
- String variable interpolation may use
[%-formatting](https://docs.python.org/3/library/stdtypes.html#old-string-formatting), [f-strings](https://docs.python.org/3/reference/lexical_analysis.html#f-strings), or [`str.format()`](https://docs.python.org/3/library/stdtypes.html#str.format) as appropriate, with the goal of
maximizing code readability.
Le jugement final sur la lisibilité est à la discrétion de la personne qui finalisera la fusion. Comme ligne de conduite, les chaînes f-strings ne devraient utiliser que des variables simples et des accès de propriétés, avec attribution préalable à des variables locales pour les cas plus complexes
```
# Allowed
f"hello {user}"
f"hello {user.name}"
f"hello {self.user.name}"
# Disallowed
f"hello {get_user()}"
f"you are {user.age * 365.25} days old"
# Allowed with local variable assignment
user = get_user()
f"hello {user}"
user_days_old = user.age * 365.25
f"you are {user_days_old} days old"
```
Les chaînes f-strings ne doivent pas être utilisées pour les chaînes nécessitant d’être traduites, y compris les erreurs ou les messages de journalisation. En général, `format()` est plus bavard, donc les autres méthodes de mise en forme sont privilégiées.
Ne gaspillez pas de temps à réécrire du code existant sans lien avec le problème en cours simplement pour ajuster la méthode de mise en forme.
- Évitez l’utilisation de « we » dans les commentaires, par ex. « Loop over » plutôt que « We loop over ».
- Utilisez les soulignements, pas la CasseChameau, pour les noms de variables, de fonctions et de méthodes (par ex. `poll.get_unique_voters()` au lieu de `poll.getUniqueVoters()`).
- Utilisez la `CasseChameau` pour les noms de classes (ou pour les fonctions fabriques qui renvoient des classes).
- Dans les chaînes de documentation (docstring), suivez le style des chaînes existantes ainsi que [**PEP 257**](https://peps.python.org/pep-0257/).
- Dans les tests, utilisez [`assertRaisesMessage()`](/fr/6.0/topics/testing/tools/#django.test.SimpleTestCase.assertRaisesMessage) et [`assertWarnsMessage()`](/fr/6.0/topics/testing/tools/#django.test.SimpleTestCase.assertWarnsMessage) au lieu de [`assertRaises()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaises) et [`assertWarns()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertWarns) afin de pouvoir contrôler le message d’exception ou d’avertissement. N’utilisez [`assertRaisesRegex()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaisesRegex) et [`assertWarnsRegex()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertWarnsRegex) que si vous avez besoin de la correspondance par expression régulière.
Utilisez [`assertIs(…, True/False)`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertIs) pour tester les valeurs booléennes, plutôt que [`assertTrue()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertTrue) et [`assertFalse()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertFalse), car cela vous permet de contrôler la valeur booléenne exacte et pas seulement le résultat booléen de l’évaluation de l’expression.
- Dans les chaînes de documentation des tests, exprimez le comportement attendu tel que démontré par chaque test. N’incluez pas de préambules tels que « Tests that » ou « Ensures that ».
Réservez les références aux tickets pour les problèmes obscurs où le ticket dispose de détails supplémentaires ne pouvant pas être facilement décrits dans les chaînes de documentation ou les commentaires. Incluez alors le numéro de ticket à la fin d’une phrase comme ceci
```
def test_foo():
"""
A test docstring looks like this (#123456).
"""
...
```
- Where applicable, use unpacking generalizations compliant with [**PEP 448**](https://peps.python.org/pep-0448/),
such as merging mappings (`{**x, **y}`) or sequences (`[*a, *b]`). This
improves performance, readability, and maintainability while reducing errors.
## Importations
- Utilisez [isort](https://pypi.org/project/isort/) pour automatiser le tri des importations en suivant les directives ci-dessous.
Pour faire vite :
```console
$ python -m pip install "isort >= 7.0.0"
$ isort .
```
*Windows*
```doscon
...\> py -m pip install "isort >= 7.0.0"
...\> isort .
```
Ceci exécute `isort` de manière récursive à partir du répertoire courant, en modifiant tout fichier ne se conformant pas aux directives. S’il est nécessaire d’avoir des importations non triées (par exemple pour éviter une importation circulaire), utilisez un commentaire comme ceci
```
import module # isort:skip
```
- Put imports in these groups: future, standard library, third-party libraries,
other Django components, local Django component, try/excepts. Sort lines in
each group alphabetically by the full module name. Place all
`import module` statements before `from module import objects` in each
section. Use absolute imports for other Django components and a one-dot
relative import (`from .foo import Bar`) for local components. Avoid
multi-dot relative imports.
- Sur chaque ligne, triez les éléments par ordre alphabétique en groupant les noms avec majuscule avant les noms avec minuscule.
- Séparez les longues lignes par des parenthèses et indentez les lignes de continuation par 4 espaces. Ajoutez une virgule finale après la dernière importation et placez la parenthèse fermante sur sa propre ligne.
Placez une seule ligne vierge entre la dernière importation et tout code de niveau module, et placez deux lignes vierges au-dessus de la première fonction ou classe.
Par exemple (les commentaires ne sont qu’à titre informatif) :
*`django/contrib/admin/example.py`*
```python
# future
from __future__ import annotations
# standard library
import json
from itertools import chain
# third-party
import bcrypt
# Django
from django.http import Http404
from django.http.response import (
Http404,
HttpResponse,
HttpResponseNotAllowed,
StreamingHttpResponse,
cookie,
)
# local Django
from .models import LogEntry
# try/except
try:
import yaml
except ImportError:
yaml = None
CONSTANT = "foo"
class Example: ...
```
- Utilisez des importations les plus directes possibles quand elles sont disponibles
```
from django.views import View
```
au lieu de
```
from django.views.generic.base import View
```
## Style des gabarits
Suivez les règles ci-après dans le code des gabarits de Django.
- `{% extends %}` doit être la première ligne excepté d’éventuels commentaires.
Faites :
```html+django
{% extends "base.html" %}
{% block content %}
{{ pages.title }}
{% endblock content %}
```
Ou ceci :
```html+django
{# This is a comment #}
{% extends "base.html" %}
{% block content %}
{{ pages.title }}
{% endblock content %}
```
Ne faites pas :
```html+django
{% load i18n %}
{% extends "base.html" %}
{% block content %}
{{ pages.title }}
{% endblock content %}
```
- Placez exactement une espace entre `{{`, le nom de la variable, et `}}`.
Faites :
```html+django
{{ user }}
```
Ne faites pas :
```html+django
{{user}}
```
- Dans `{% load ... %}`, énumérez les bibliothèques dans l’ordre alphabétique.
Faites :
```html+django
{% load i18n l10 tz %}
```
Ne faites pas :
```html+django
{% load l10 i18n tz %}
```
- Placez exactement une espace entre `{%`, le contenu de la balise, et `%}`.
Faites :
```html+django
{% load humanize %}
```
Ne faites pas :
```html+django
{%load humanize%}
```
- Placez le nom de la balise `{% block %}` dans la balise `{% endblock %}` si elles ne sont pas sur la même ligne.
Faites :
```html+django
{% block header %}
Code goes here
{% endblock header %}
```
Ne faites pas :
```html+django
{% block header %}
Code goes here
{% endblock %}
```
- À l’intérieur des accolades, séparez les mots par des espaces uniques, sauf autour des `.` pour l’accès aux attributs et autour de `|` pour le chaînage avec des filtres.
Faites :
```html+django
{% if user.name|lower == "admin" %}
```
Ne faites pas :
```html+django
{% if user . name | lower == "admin" %}
{{ user.name | upper }}
```
- Dans les gabarits utilisant `{% extends %}`, évitez l’indentation des balises `{% block %}` de niveau supérieur.
Faites :
```html+django
{% extends "base.html" %}
{% block content %}
```
Ne faites pas :
```html+django
{% extends "base.html" %}
{% block content %}
...
```
## Style des vues
- Dans les vues de Django, le premier paramètre d’une vue fonction devrait s’appeler `request`.
Faites
```
def my_view(request, foo): ...
```
Ne faites pas :
```
def my_view(req, foo): ...
```
## Style des modèles
- Les noms de champs devraient être tout en minuscules, en utilisant des soulignements au lieu du StyleChameau.
Faites
```
class Person(models.Model):
first_name = models.CharField(max_length=20)
last_name = models.CharField(max_length=40)
```
Ne faites pas :
```
class Person(models.Model):
FirstName = models.CharField(max_length=20)
Last_Name = models.CharField(max_length=40)
```
- La `class Meta` doit apparaître *après* les définitions de champs, avec une seule ligne vierge séparant les champs de la définition de classe.
Faites
```
class Person(models.Model):
first_name = models.CharField(max_length=20)
last_name = models.CharField(max_length=40)
class Meta:
verbose_name_plural = "people"
```
Ne faites pas :
```
class Person(models.Model):
class Meta:
verbose_name_plural = "people"
first_name = models.CharField(max_length=20)
last_name = models.CharField(max_length=40)
```
- L’ordre des classes internes de modèles et des méthodes standards doit être le suivant (notez qu’elles ne sont pas toutes obligatoires) :
- Tous les champs de la base de données
- Attributs des gestionnaires personnalisés
- `class Meta`
- `def __str__()` et autres méthodes magiques de Python
- `def save()`
- `def get_absolute_url()`
- Toute autre méthode personnalisée
- Si `choices` est défini pour un champ de modèle, définissez chaque choix sous forme de table de correspondance, avec un nom tout en majuscules comme attribut de classe du modèle. Exemple :
```
class MyModel(models.Model):
DIRECTION_UP = "U"
DIRECTION_DOWN = "D"
DIRECTION_CHOICES = {
DIRECTION_UP: "Up",
DIRECTION_DOWN: "Down",
}
```
Il existe aussi l’option d’utiliser des [Types énumératifs](/fr/6.0/ref/models/fields/#field-choices-enum-types):
```
class MyModel(models.Model):
class Direction(models.TextChoices):
UP = "U", "Up"
DOWN = "D", "Down"
```
## Utilisation de `django.conf.settings`
Les modules ne devraient généralement pas utiliser des réglages stockés dans `django.conf.settings` à leur premier niveau (c’est-à-dire évalués au moment de l’importation du module). Voici pourquoi :
La configuration manuelle des réglages (qui ne dépend pas de la variable d’environnement [`DJANGO_SETTINGS_MODULE`](/fr/6.0/topics/settings/#envvar-DJANGO_SETTINGS_MODULE)) est autorisée et possible comme ceci
```
from django.conf import settings
settings.configure({}, SOME_SETTING="foo")
```
Cependant, si un réglage est accédé avant la ligne `settings.configure`, ceci ne fonctionnera pas (en interne, `settings` est un `LazyObject` qui se configure automatiquement au moment où on accède aux réglages si ce n’est pas encore fait).
Ainsi, si un module contient du code tel que celui-ci
```
from django.conf import settings
from django.urls import get_callable
default_foo_view = get_callable(settings.FOO_VIEW)
```
…alors l’importation de ce module provoquera la configuration de l’objet `settings`. Cela signifie que la capacité d’importer le module au premier niveau à partir de code externe est incompatible avec la possibilité de configurer manuellement l’objet `settings`, ou cela le rend très difficile dans certaines circonstances.
Au lieu du code ci-dessus, un niveau de diffèrement ou d’indirection doit être ajouté, tel que `django.utils.functional.LazyObject`, `django.utils.functional.lazy()` ou `lambda`.
## Divers
- Marquez toutes les chaînes à traduire ; voir la [documentation i18n](/fr/6.0/topics/i18n/) pour plus de détails.
- Supprimez les instructions `import` qui ne sont plus utilisées lorsque vous modifiez du code. [flake8](https://pypi.org/project/flake8/) peut identifier ces importations à votre place. Si une importation inutilisée doit rester pour garantir une compatibilité, placez un commentaire `# NOQA` à la fin de la ligne pour indiquer à `flake8` de rester silencieux.
- Supprimez systématiquement tout espace vide en fin de ligne dans le code car ils ajoutent des caractères inutilement, présentent un encombrement visuel dans les correctifs et peuvent aussi provoquer occasionnellement des conflits de fusion inutiles. Certains environnements de développement peuvent être configurés pour les supprimer automatiquement et les plupart des outils de gestion de version peuvent être réglés pour les mettre en évidence dans les affichages de différences.
- N’écrivez pas votre nom dans le code que vous produisez. Notre politique est de placer les noms des contributeurs dans le fichier `AUTHORS` distribué avec Django au lieu de les répartir dans tout le code. Prenez la liberté d’inclure votre nom dans ce fichier `AUTHORS` dans votre correctif si vous faites plus qu’une simple modification triviale.
## Style JavaScript
For details about the JavaScript code style used by Django, see
[Code JavaScript](/fr/6.0/internals/contributing/writing-code/javascript/).