Veuillez respecter ces standards de codage lorsque vous écrivez du code destiné à faire partie de Django.
\nVeuillez 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.
\nUtilisez 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\ncode to 79 characters if it means the code looks significantly uglier or is\nharder to read. We allow up to 119 characters as this is the width of GitHub\ncode review; anything longer requires horizontal scrolling which makes review\nmore difficult. This check is included when you run flake8. Documentation,\ncomments, and docstrings should be wrapped at 79 characters, even though\nPEP 8 suggests 72.
Utilisez 4 espaces pour l’indentation.
Utilisez l’indentation pendante de quatre espaces plutôt que l’alignement vertical
\nraise AttributeError(\n 'Here is a multiline error message '\n 'shortened for clarity.'\n)\nAu lieu de :
\nraise AttributeError('Here is a multiline error message '\n 'shortened for clarity.')\nCela 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.
\nUtilisez 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.
String variable interpolation may use\n%-formatting, f-strings, or str.format() as appropriate, with the goal of\nmaximizing code readability.
Final judgments of readability are left to the Merger’s discretion. As a\nguide, f-strings should use only plain variable and property access, with\nprior local variable assignment for more complex cases:
\n# Allowed\nf'hello {user}'\nf'hello {user.name}'\nf'hello {self.user.name}'\n\n# Disallowed\nf'hello {get_user()}'\nf'you are {user.age * 365.25} days old'\n\n# Allowed with local variable assignment\nuser = get_user()\nf'hello {user}'\nuser_days_old = user.age * 365.25\nf'you are {user_days_old} days old'\nf-strings should not be used for any string that may require translation,\nincluding error and logging messages. In general format() is more\nverbose, so the other formatting methods are preferred.
Don’t waste time doing unrelated refactoring of existing code to adjust the\nformatting method.
\nÉ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.
Dans les tests, utilisez assertRaisesMessage() et assertWarnsMessage() au lieu de assertRaises() et assertWarns() afin de pouvoir contrôler le message d’exception ou d’avertissement. N’utilisez assertRaisesRegex() et assertWarnsRegex() que si vous avez besoin de la correspondance par expression régulière.
Utilisez assertIs(…, True/False) pour tester les valeurs booléennes, plutôt que assertTrue() et 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 ».
\nRé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
\ndef test_foo():\n """\n A test docstring looks like this (#123456).\n """\n ...\nUse isort to automate import\nsorting using the guidelines below.
\nPour faire vite :
\nLinux / macOS
$ python -m pip install isort >= 5.1.0\n$ isort -rc .\nWindows
...\\> py -m pip install isort >= 5.1.0\n...\\> isort -rc .\nCeci 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\nPlacez 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.
\nPlacez 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.
\nPar exemple (les commentaires ne sont qu’à titre informatif) :
\n# future\nfrom __future__ import unicode_literals\n\n# standard library\nimport json\nfrom itertools import chain\n\n# third-party\nimport bcrypt\n\n# Django\nfrom django.http import Http404\nfrom django.http.response import (\n Http404, HttpResponse, HttpResponseNotAllowed, StreamingHttpResponse,\n cookie,\n)\n\n# local Django\nfrom .models import LogEntry\n\n# try/except\ntry:\n import yaml\nexcept ImportError:\n yaml = None\n\nCONSTANT = 'foo'\n\n\nclass Example:\n # ...\nUtilisez des importations les plus directes possibles quand elles sont disponibles
\nfrom django.views import View\nau lieu de
\nfrom django.views.generic.base import View\nDans le code des gabarits Django, placez un et un seul espace entre les accolades et le contenu des balises.
\nFaites :
\n{{ foo }}\nNe faites pas :
\n{{foo}}\nDans les vues de Django, le premier paramètre d’une vue fonction devrait s’appeler request.
Faites
\ndef my_view(request, foo):\n # ...\nNe faites pas :
\ndef my_view(req, foo):\n # ...\nLes noms de champs devraient être tout en minuscules, en utilisant des soulignements au lieu du StyleChameau.
\nFaites
\nclass Person(models.Model):\n first_name = models.CharField(max_length=20)\n last_name = models.CharField(max_length=40)\nNe faites pas :
\nclass Person(models.Model):\n FirstName = models.CharField(max_length=20)\n Last_Name = models.CharField(max_length=40)\nLa 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
\nclass Person(models.Model):\n first_name = models.CharField(max_length=20)\n last_name = models.CharField(max_length=40)\n\n class Meta:\n verbose_name_plural = 'people'\nNe faites pas :
\nclass Person(models.Model):\n first_name = models.CharField(max_length=20)\n last_name = models.CharField(max_length=40)\n class Meta:\n verbose_name_plural = 'people'\nNe faites pas ça non plus :
\nclass Person(models.Model):\n class Meta:\n verbose_name_plural = 'people'\n\n first_name = models.CharField(max_length=20)\n last_name = models.CharField(max_length=40)\nL’ordre des classes internes de modèles et des méthodes standards doit être le suivant (notez qu’elles ne sont pas toutes obligatoires) :
\nTous les champs de la base de données
Attributs des gestionnaires personnalisés
class Meta
def __str__()
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 liste de tuples, avec un nom tout en majuscules comme attribut de classe du modèle. Exemple
class MyModel(models.Model):\n DIRECTION_UP = 'U'\n DIRECTION_DOWN = 'D'\n DIRECTION_CHOICES = [\n (DIRECTION_UP, 'Up'),\n (DIRECTION_DOWN, 'Down'),\n ]\ndjango.conf.settingsLien vers cette rubrique#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\n\nsettings.configure({}, SOME_SETTING='foo')\nCependant, 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
\nfrom django.conf import settings\nfrom django.urls import get_callable\n\ndefault_foo_view = get_callable(settings.FOO_VIEW)\n…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.
Marquez toutes les chaînes à traduire ; voir la documentation i18n pour plus de détails.
Supprimez les instructions 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.
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.
Pour plus de détails sur le style de code JavaScript utilisé par Django, consultez JavaScript.
\n