Por favor siga esses padrões quando estiver escrevendo código para inclusão no 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 isort then the tool will go ahead and fix them for\nyou. Review the changes and re-stage for commit if you are happy with\nthem.
Por favor adapte-se ao estilo de identação ditado no arquivo .editorconfig. Nós recomendamos usar o editor de textos com suporte a EditorConfig para evitar problemas com identação e espaços em branco. Os arquivos Python usam 4 espaços para identação e os arquivos HTML usam 2 espaços.
Exceto quando indicado explicitamente, sempre siga a PEP 8.
\nUtilize o flake8 para procurar por problemas nesta área. Note que o nosso arquivo de setup.cfg contém alguns arquivos excluídos (modulos depreciados que nós não nos importamos em limpar e algum código de terceiros que o Django oferece) assim como alguns erros excluídos que nós não consideramos como violações graves. Lembre-se de que a PEP 8 é apenas um guia, então tenha como objetivo principal o respeito ao estilo do código ao seu redor.
Uma exceção a PEP 8 são nossas regras sobre o comprimento das linhas. Não limite linhas de código para 79 caracteres se isso significar deixar o código mais feio ou mais difícil de ler. Nós permitimos até 119 caracteres já que esse é o limite do revisor de código do GitHub; qualquer coisa mais longa que isso requer rolagem horizontal o que faz a revisão mais difícil. Essa verificação está incluída quando você roda o flake8. Documentação, comentários, e docstrings devem estar envolvidas em até 79 caracteres, mesmo que a PEP 8 sugira somente 72.
Utilize quatro espaços para identação.
Use four space hanging indentation rather than vertical alignment:
\nraise AttributeError(\n 'Here is a multiline error message '\n 'shortened for clarity.'\n)\nAo invés de:
\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.
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()).
Utilize IniciaisMaiúsculas para nomes de classes (ou para funções factory que retornem 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\nsorting using the guidelines below.
\nInício Rápido:
\nLinux / macOS
$ python -m pip install "isort >= 5.1.0"\n$ isort .\nWindows
...\\> py -m pip install "isort >= 5.1.0"\n...\\> isort .\nIsso roda o isort recursivamente do seu diretório atual, modificando quaisquer arquivos que não estejam de acordo com as orientações gerais. Se você precisa ter imports fora de ordem (para evitar um import circular, por exemplo) use um comentário como esse:
import module # isort:skip\nColoque os imports nesses grupos: future, bibliotecas padrão, bibliotecas de terceiros, outros componentes Django, componentes Django locais, try/excepts. Ordene as linhas em cada grupo por ordem alfabética pelo nome completo do módulo. Coloque todos os comandos do tipo import module antes de comandos do tipo from module import objects em cada uma das seções. Utilize absolute imports para outros componentes Django e local imports para componentes locais.
On each line, alphabetize the items with the upper case items grouped before\nthe lowercase items.
Quebre linhas longas usando parênteses e identando as linhas de continuação com 4 espaços. Inclua uma vírgula depois do último import e coloque o parênteses de fechamento em sua própria linha.
\nUtilize uma única linha em branco entre o último import e qualquer código a nível de módulo, e utilize duas linhas em branco acima da primeira função ou classe.
\nPor exemplo (os comentários existem somente para propósitos de explicação):
\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, 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 # ...\nUtilize import de conveniência quando possível. Por exemplo, faça isso:
\nfrom django.views import View\nao invés de:
\nfrom django.views.generic.base import View\nNo código de templates Django, coloque um (e somente um) espaço entre as chaves e o conteúdo da tag.
\nFaça isso:
\n{{ foo }}\nNão faça isso:
\n{{foo}}\nNas views do Django, o primeiro parâmetro na função de uma view deve ser chamado request.
Faça isso:
\ndef my_view(request, foo):\n # ...\nNão faça isso:
\ndef my_view(req, foo):\n # ...\nOs nomes dos campos devem ser todos minúsculos, usando underscores ao invés de camelCase.
\nFaça isso:
\nclass Person(models.Model):\n first_name = models.CharField(max_length=20)\n last_name = models.CharField(max_length=40)\nNão faça isso:
\nclass Person(models.Model):\n FirstName = models.CharField(max_length=20)\n Last_Name = models.CharField(max_length=40)\nA classe Meta deve aparecer depois que os campos são declarados, com uma única linha em branco separando os campos da definição da classe.
Faça isso:
\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'\nNão faça isso:
\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'\nNão faça isso também:
\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)\nA ordem dos modelos internos das classes e dos métodos padrão devem ser como a seguir (tendo em mente que eles não são todos obrigatórios):
\nTodos os campos do banco de dados
Atributos customizados do manager
classe Meta
def __str__()
def save()
def get_absolute_url()
Quaisquer métodos customizados.
If choices is defined for a given model field, define each choice as a\nlist of tuples, 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 ]\ndjango.conf.settingsLink para este cabeçalho#Em geral os módulos não devem utilizar em seu topo configurações armazenadas em django.conf.settings (quando queremos que alguma configuração só seja interpretada quando o módulo é importado, por exemplo). A motivação para isso é a seguinte:
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')\nPorém, se qualquer configuração é acessada antes da linha settings.configure, isso não irá funcionar (internamente, settings é um LazyObject que, caso não tenha sido configurado antes, se configura sozinho e automaticamente quando o settings é acessado).
Então, se existir um módulo contendo código como o descrito a seguir:
\nfrom django.conf import settings\nfrom django.urls import get_callable\n\ndefault_foo_view = get_callable(settings.FOO_VIEW)\nA importação desse módulo fará com que o objeto settings seja configurado. Isso significa que a abilidade de importar módulos no topo por terceiros é incompatível com a abilidade de configurar o objeto settings manualmente, ou faz com que ela seja extremamente difícil em algumas circunstâncias.
\nAo invés do código acima, um nível de laziness ou indireção deve ser usado, tais como django.utils.functional.LazyObject, django.utils.functional.lazy() ou lambda.
Marque todas as strings para internacionalização; veja a documentação i18n para mais detalhes.
Remova comandos import que não são mais usados quando você mudar o código. O flake8 irá identificar esses imports para você. Se um import não utilizado precisa permanecer para compatibilidade com versões anteriores, marque o seu final com # NOQA para silenciar o warning do flake8.
Remova sistematicamente todos os espaços em branco no final do seu código já que eles adicionam bytes desnecessários, adicionanm poluição visual aos patches e também podem eventualmente ocasionar conflitos de merge. Algumas IDEs podem ser configuradas para automaticamente removê-los e a maioria das ferramentas de versionamento de código podem ser configuradas para exibi-los na geração dos diffs.
Por favor não coloque o seu nome no código que você está contribuindo. Nossa política é de manter os nomes de quem contribui no arquivo AUTHORS distribuído com o Django – e não espalhado por todo o código do projeto. Sinta-se à vontade para incluir uma mudança no arquivo AUTHORS no seu patch se você fez mais do que uma mudança trivial.
Para detalhes sobre o estilo de código JavaScript adotado no Django, veja JavaScript.
\n