Veuillez respecter ces standards de codage lorsque vous écrivez du code destiné à faire partie de Django.
Veuillez respecter le style d’indentation défini dans le fichier .editorconfig
. Nous recommandons d’utiliser un éditeur de texte avec prise en charge de EditorConfig 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.
Utilisez flake8 pour détecter les problèmes de ce genre. Notez que notre fichier setup.cfg
contient une exclusion de certains fichiers (modules obsolètes qu’il serait inutile de corriger et certains codes d’origine externe que Django incorpore), ainsi que l’exclusion de certains contrôles d’erreurs que nous ne considérons pas comme des violations graves. Souvenez-vous que PEP 8 n’est qu’un guide, le respect du style du code environnant est l’objectif principal.
An exception to PEP 8 is our rules on line lengths. Don’t limit lines of
code to 79 characters if it means the code looks significantly uglier or is
harder to read. We allow up to 119 characters as this is the width of GitHub
code review; anything longer requires horizontal scrolling which makes review
more difficult. This check is included when you run flake8
. Documentation,
comments, and docstrings should be wrapped at 79 characters, even though
PEP 8 suggests 72.
Utilisez 4 espaces pour l’indentation.
Use four space hanging indentation rather than vertical alignment:
raise AttributeError(
'Here is a multiline error message '
'shortened for clarity.'
)
Au lieu de :
raise AttributeError('Here is a multiline error message '
'shortened for clarity.')
Cela améliore l’utilisation de l’espace et évite de devoir changer l’alignement des chaînes quand la longueur de la première ligne change.
Utilisez des guillemets simples pour les chaînes, ou des guillemet doubles si la chaîne contient elle-même un guillemet simple. Ne perdez pas de temps à réarranger du code existant non lié à la modification en cours pour se conformer à ce style.
Évitez l’utilisation de « we » dans les commentaires, par ex. « Loop over » plutôt que « We loop over ».
Use underscores, not camelCase, for variable, function and method names
(i.e. poll.get_unique_voters()
, not poll.getUniqueVoters()
).
Use InitialCaps
for class names (or for factory functions that
return classes).
In docstrings, follow the style of existing docstrings and PEP 257.
In tests, use
assertRaisesMessage()
and
assertWarnsMessage()
instead of assertRaises()
and
assertWarns()
so you can check the
exception or warning message. Use assertRaisesRegex()
and assertWarnsRegex()
only if you need regular
expression matching.
Use assertIs(…, True/False)
for testing
boolean values, rather than assertTrue()
and
assertFalse()
, so you can check the actual boolean
value, not the truthiness of the expression.
In test docstrings, state the expected behavior that each test demonstrates. Don’t include preambles such as « Tests that » or « Ensures that ».
Reserve ticket references for obscure issues where the ticket has additional details that can’t be easily described in docstrings or comments. Include the ticket number at the end of a sentence like this:
def test_foo():
"""
A test docstring looks like this (#123456).
"""
...
Utilisez isort pour automatiser le tri des importations en suivant les directives ci-dessous.
Pour faire vite :
$ python -m pip install isort
$ isort -rc .
...\> py -m pip install isort
...\> isort -rc .
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
Placez les importations dans ces groupes :: futur, bibliothèque standard, bibliothèques tierces, autres composants Django, composant Django local, instructions try/except. Trier les lignes de chaque groupe dans l’ordre alphabétique selon le nom complet du module. Dans chaque section, placez toutes les instructions import module
avant celles de type from module import objects
. Utilisez des importations absolues pour les autres composants Django et des importations relatives pour les composants locaux.
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) :
# future
from __future__ import unicode_literals
# 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
Dans le code des gabarits Django, placez un et un seul espace entre les accolades et le contenu des balises.
Faites :
{{ foo }}
Ne faites pas :
{{foo}}
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):
# ...
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):
first_name = models.CharField(max_length=20)
last_name = models.CharField(max_length=40)
class Meta:
verbose_name_plural = 'people'
Ne faites pas ça non plus :
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) :
class Meta
def __str__()
def save()
def get_absolute_url()
Si choices
est défini pour un champ de modèle, définissez chaque choix sous forme de liste de tuples, 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'),
]
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
) 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
.
import
qui ne sont plus utilisées lorsque vous modifiez du code. 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.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.Pour plus de détails sur le style de code JavaScript utilisé par Django, consultez JavaScript.
août 03, 2020