Please follow these coding standards when writing code for inclusion in Django.
\nPlease conform to the indentation style dictated in the .editorconfig\nfile. We recommend using a text editor with EditorConfig support to avoid\nindentation and whitespace issues. The Python files use 4 spaces for\nindentation and the HTML files use 2 spaces.
Unless otherwise specified, follow PEP 8.
\nUse flake8 to check for problems in this area. Note that our setup.cfg\nfile contains some excluded files (deprecated modules we don’t care about\ncleaning up and some third-party code that Django vendors) as well as some\nexcluded errors that we don’t consider as gross violations. Remember that\nPEP 8 is only a guide, so respect the style of the surrounding code as a\nprimary goal.
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.
Use four space hanging indentation rather than vertical alignment:
\nraise AttributeError(\n 'Here is a multiline error message '\n 'shortened for clarity.'\n)\nInstead of:
\nraise AttributeError('Here is a multiline error message '\n 'shortened for clarity.')\nThis makes better use of space and avoids having to realign strings if the\nlength of the first line changes.
\nUse single quotes for strings, or a double quote if the string contains a\nsingle quote. Don’t waste time doing unrelated refactoring of existing code\nto conform to this style.
Avoid use of « we » in comments, e.g. « Loop over » rather than « We loop over ».
Use underscores, not camelCase, for variable, function and method names\n(i.e. poll.get_unique_voters(), not poll.getUniqueVoters()).
Use InitialCaps for class names (or for factory functions that\nreturn classes).
In docstrings, follow the style of existing docstrings and PEP 257.
In tests, use\nassertRaisesMessage() and\nassertWarnsMessage()\ninstead of assertRaises() and\nassertWarns() so you can check the\nexception or warning message. Use assertRaisesRegex()\nand assertWarnsRegex() only if you need regular\nexpression matching.
In test docstrings, state the expected behavior that each test demonstrates.\nDon’t include preambles such as « Tests that » or « Ensures that ».
\nReserve ticket references for obscure issues where the ticket has additional\ndetails that can’t be easily described in docstrings or comments. Include the\nticket number at the end of a sentence like this:
\ndef test_foo():\n """\n A test docstring looks like this (#123456).\n """\n ...\nUse isort to automate\nimport sorting using the guidelines below.
\nQuick start:
\nLinux / macOS
$ pip install isort\n$ isort -rc .\nWindows
...\\> pip install isort\n...\\> isort -rc .\nThis runs isort recursively from your current directory, modifying any\nfiles that don’t conform to the guidelines. If you need to have imports out\nof order (to avoid a circular import, for example) use a comment like this:
import module # isort:skip\nPut imports in these groups: future, standard library, third-party libraries,\nother Django components, local Django component, try/excepts. Sort lines in\neach group alphabetically by the full module name. Place all import module\nstatements before from module import objects in each section. Use absolute\nimports for other Django components and relative imports for local components.
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 tuple 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')\nHowever, if any setting is accessed before the settings.configure line,\nthis will not work. (Internally, settings is a LazyObject which\nconfigures itself automatically when the settings are accessed if it has not\nalready been configured).
So, if there is a module containing some code as follows:
\nfrom django.conf import settings\nfrom django.urls import get_callable\n\ndefault_foo_view = get_callable(settings.FOO_VIEW)\n…then importing this module will cause the settings object to be configured.\nThat means that the ability for third parties to import the module at the top\nlevel is incompatible with the ability to configure the settings object\nmanually, or makes it very difficult in some circumstances.
\nInstead of the above code, a level of laziness or indirection must be used,\nsuch as django.utils.functional.LazyObject,\ndjango.utils.functional.lazy() or lambda.
Marquez toutes les chaînes à traduire ; voir la documentation i18n pour plus de détails.
Remove import statements that are no longer used when you change code.\nflake8 will identify these imports for you. If an unused import needs to\nremain for backwards-compatibility, mark the end of with # NOQA to\nsilence the flake8 warning.
Systematically remove all trailing whitespaces from your code as those\nadd unnecessary bytes, add visual clutter to the patches and can also\noccasionally cause unnecessary merge conflicts. Some IDE’s can be\nconfigured to automatically remove them and most VCS tools can be set to\nhighlight them in diff outputs.
Please don’t put your name in the code you contribute. Our policy is to\nkeep contributors” names in the AUTHORS file distributed with Django\n– not scattered throughout the codebase itself. Feel free to include a\nchange to the AUTHORS file in your patch if you make more than a\nsingle trivial change.
Pour plus de détails sur le style de code JavaScript utilisé par Django, consultez JavaScript.
\n