Please follow these coding standards when writing code for inclusion in Django.
\npre-commit is a framework for managing pre-commit\nhooks. These hooks help to identify simple issues before committing code for\nreview. By checking for these issues before code review it allows the reviewer\nto focus on the change itself, and it can also help to reduce the number of CI\nruns.
\nTo use the tool, first install pre-commit and then the git hooks:
Linux / macOS
$ python -m pip install pre-commit\n$ pre-commit install\nWindows
...\\> py -m pip install pre-commit\n...\\> pre-commit install\nOn the first commit pre-commit will install the hooks, these are\ninstalled in their own environments and will take a short while to\ninstall on the first run. Subsequent checks will be significantly faster.\nIf an error is found an appropriate error message will be displayed.\nIf the error was with black or isort then the tool will go ahead and\nfix them for you. Review the changes and re-stage for commit if you are happy\nwith them.
All files should be formatted using the black auto-formatter. This\nwill be run by pre-commit if that is configured.
The project repository includes an .editorconfig file. We recommend using\na text editor with EditorConfig support to avoid indentation and\nwhitespace issues. The Python files use 4 spaces for indentation and the HTML\nfiles use 2 spaces.
Unless otherwise specified, follow PEP 8.
\nUse flake8 to check for problems in this area. Note that our\n.flake8 file contains some excluded files (deprecated modules we don’t\ncare about cleaning up and some third-party code that Django vendors) as well\nas some excluded errors that we don’t consider as gross violations. Remember\nthat PEP 8 is only a guide, so respect the style of the surrounding code\nas a primary 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 88 characters as this is the line length used\nby black. This check is included when you run flake8. Documentation,\ncomments, and docstrings should be wrapped at 79 characters, even though\nPEP 8 suggests 72.
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.
\nAvoid 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.
Use assertIs(…, True/False) for testing\nboolean values, rather than assertTrue() and\nassertFalse(), so you can check the actual boolean\nvalue, not the truthiness of the expression.
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 import sorting using the guidelines below.
\nQuick start:
\nLinux / macOS
$ python -m pip install "isort >= 5.1.0"\n$ isort .\nWindows
...\\> py -m pip install "isort >= 5.1.0"\n...\\> isort .\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.
On each line, alphabetize the items with the upper case items grouped before\nthe lowercase items.
Break long lines using parentheses and indent continuation lines by 4 spaces.\nInclude a trailing comma after the last import and put the closing\nparenthesis on its own line.
\nUse a single blank line between the last import and any module level code,\nand use two blank lines above the first function or class.
\nFor example (comments are for explanatory purposes only):
\ndjango/contrib/admin/example.py# 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,\n HttpResponse,\n HttpResponseNotAllowed,\n 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: ...\nUse convenience imports whenever available. For example, do this
\nfrom django.views import View\ninstead of:
\nfrom django.views.generic.base import View\nFollow the below rules in Django template code.
\n{% extends %} should be the first non-comment line.
Do this:
\n{% extends "base.html" %}\n\n{% block content %}\n <h1 class="font-semibold text-xl">\n {{ pages.title }}\n </h1>\n{% endblock content %}\nOr this:
\n{# This is a comment #}\n{% extends "base.html" %}\n\n{% block content %}\n <h1 class="font-semibold text-xl">\n {{ pages.title }}\n </h1>\n{% endblock content %}\nDon’t do this:
\n{% load i18n %}\n{% extends "base.html" %}\n\n{% block content %}\n <h1 class="font-semibold text-xl">\n {{ pages.title }}\n </h1>\n{% endblock content %}\nPut exactly one space between {{, variable contents, and }}.
Do this:
\n{{ user }}\nDon’t do this:
\n{{user}}\nIn {% load ... %}, list libraries in alphabetical order.
Do this:
\n{% load i18n l10 tz %}\nDon’t do this:
\n{% load l10 i18n tz %}\nPut exactly one space between {%, tag contents, and %}.
Do this:
\n{% load humanize %}\nDon’t do this:
\n{%load humanize%}\nPut the {% block %} tag name in the {% endblock %} tag if it is not\non the same line.
Do this:
\n{% block header %}\n\n Code goes here\n\n{% endblock header %}\nDon’t do this:
\n{% block header %}\n\n Code goes here\n\n{% endblock %}\nInside curly braces, separate tokens by single spaces, except for around the\n. for attribute access and the | for a filter.
Do this:
\n{% if user.name|lower == "admin" %}\nDon’t do this:
\n{% if user . name | lower == "admin" %}\n\n{{ user.name | upper }}\nWithin a template using {% extends %}, avoid indenting top-level\n{% block %} tags.
Do this:
\n{% extends "base.html" %}\n\n{% block content %}\nDon’t do this:
\n{% extends "base.html" %}\n\n {% block content %}\n ...\nIn Django views, the first parameter in a view function should be called\nrequest.
Do this:
\ndef my_view(request, foo): ...\nDon’t do this:
\ndef my_view(req, foo): ...\nField names should be all lowercase, using underscores instead of\ncamelCase.
\nDo this:
\nclass Person(models.Model):\n first_name = models.CharField(max_length=20)\n last_name = models.CharField(max_length=40)\nDon’t do this:
\nclass Person(models.Model):\n FirstName = models.CharField(max_length=20)\n Last_Name = models.CharField(max_length=40)\nThe class Meta should appear after the fields are defined, with\na single blank line separating the fields and the class definition.
Do this:
\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"\nDon’t do this:
\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)\nThe order of model inner classes and standard methods should be as\nfollows (noting that these are not all required):
\nAll database fields
Custom manager attributes
class Meta
def __str__()
def save()
def get_absolute_url()
Any custom methods
If choices is defined for a given model field, define each choice as a\nmapping, with an all-uppercase name as a class attribute on the model.\nExample:
class MyModel(models.Model):\n DIRECTION_UP = "U"\n DIRECTION_DOWN = "D"\n DIRECTION_CHOICES = {\n DIRECTION_UP: "Up",\n DIRECTION_DOWN: "Down",\n }\nAlternatively, consider using Enumeration types:
\nclass MyModel(models.Model):\n class Direction(models.TextChoices):\n UP = "U", "Up"\n DOWN = "D", "Down"\ndjango.conf.settingsLink to this heading#Modules should not in general use settings stored in django.conf.settings\nat the top level (i.e. evaluated when the module is imported). The explanation\nfor this is as follows:
Manual configuration of settings (i.e. not relying on the\nDJANGO_SETTINGS_MODULE environment variable) is allowed and possible\nas follows:
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.
Mark all strings for internationalization; see the i18n\ndocumentation for details.
Remove import statements that are no longer used when you change code.\nflake8 will identify these imports for you. If an unused import needs\nto remain 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.
For details about the JavaScript code style used by Django, see\nJavaScript code.
\n