--- title: "Estilo de código" version: 4.0 locale: pt-br source: https://docs.djangoproject.com/pt-br/4.0/internals/contributing/writing-code/coding-style/ canonical: https://djangodocs.dev/pt-br/4.0/internals/contributing/writing-code/coding-style/ --- # Estilo de código Por favor siga esses padrões quando estiver escrevendo código para inclusão no Django. ## Pre-commit checks [pre-commit](https://pre-commit.com) is a framework for managing pre-commit hooks. These hooks help to identify simple issues before committing code for review. By checking for these issues before code review it allows the reviewer to focus on the change itself, and it can also help to reduce the number of CI runs. To use the tool, first install `pre-commit` and then the git hooks: ```console $ python -m pip install pre-commit $ pre-commit install ``` *Windows* ```doscon ...\> py -m pip install pre-commit ...\> pre-commit install ``` On the first commit `pre-commit` will install the hooks, these are installed in their own environments and will take a short while to install on the first run. Subsequent checks will be significantly faster. If an error is found an appropriate error message will be displayed. If the error was with `black` or `isort` then the tool will go ahead and fix them for you. Review the changes and re-stage for commit if you are happy with them. ## Estilo Python - All files should be formatted using the [black](https://black.readthedocs.io/en/stable/) auto-formatter. This will be run by `pre-commit` if that is configured. - The project repository includes an `.editorconfig` file. We recommend using a text editor with [EditorConfig](https://editorconfig.org/) support to avoid indentation and whitespace issues. The Python files use 4 spaces for indentation and the HTML files use 2 spaces. - Exceto quando indicado explicitamente, sempre siga a [**PEP 8**](https://peps.python.org/pep-0008/). Utilize o [flake8](https://pypi.org/project/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**](https://peps.python.org/pep-0008/) é apenas um guia, então tenha como objetivo principal o respeito ao estilo do código ao seu redor. An exception to [**PEP 8**](https://peps.python.org/pep-0008/) 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 88 characters as this is the line length used by `black`. This check is included when you run `flake8`. Documentation, comments, and docstrings should be wrapped at 79 characters, even though [**PEP 8**](https://peps.python.org/pep-0008/) suggests 72. - String variable interpolation may use [%-formatting](https://docs.python.org/3/library/stdtypes.html#old-string-formatting), [f-strings](https://docs.python.org/3/reference/lexical_analysis.html#f-strings), or [`str.format()`](https://docs.python.org/3/library/stdtypes.html#str.format) as appropriate, with the goal of maximizing code readability. Final judgments of readability are left to the Merger’s discretion. As a guide, f-strings should use only plain variable and property access, with prior local variable assignment for more complex cases: ``` # Allowed f'hello {user}' f'hello {user.name}' f'hello {self.user.name}' # Disallowed f'hello {get_user()}' f'you are {user.age * 365.25} days old' # Allowed with local variable assignment user = get_user() f'hello {user}' user_days_old = user.age * 365.25 f'you are {user_days_old} days old' ``` f-strings should not be used for any string that may require translation, including error and logging messages. In general `format()` is more verbose, so the other formatting methods are preferred. Don’t waste time doing unrelated refactoring of existing code to adjust the formatting method. - 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 (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**](https://peps.python.org/pep-0257/). - In tests, use [`assertRaisesMessage()`](/pt-br/4.0/topics/testing/tools/#django.test.SimpleTestCase.assertRaisesMessage) and [`assertWarnsMessage()`](/pt-br/4.0/topics/testing/tools/#django.test.SimpleTestCase.assertWarnsMessage) instead of [`assertRaises()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaises) and [`assertWarns()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertWarns) so you can check the exception or warning message. Use [`assertRaisesRegex()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertRaisesRegex) and [`assertWarnsRegex()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertWarnsRegex) only if you need regular expression matching. Use [`assertIs(…, True/False)`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertIs) for testing boolean values, rather than [`assertTrue()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertTrue) and [`assertFalse()`](https://docs.python.org/3/library/unittest.html#unittest.TestCase.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). """ ... ``` > **Changed in Django 4.0.3** > > All Python code in Django was reformatted with [black](https://black.readthedocs.io/en/stable/). ## Imports - Use [isort](https://github.com/PyCQA/isort#readme) to automate import sorting using the guidelines below. Início Rápido: ```console $ python -m pip install "isort >= 5.1.0" $ isort . ``` *Windows* ```doscon ...\> py -m pip install "isort >= 5.1.0" ...\> isort . ``` Isso 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 ``` - Coloque 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 the 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. Utilize 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. Por exemplo (os comentários existem somente para propósitos de explicação): *`django/contrib/admin/example.py`* ```python # 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: # ... ``` - Utilize import de conveniência quando possível. Por exemplo, faça isso: ``` from django.views import View ``` ao invés de: ``` from django.views.generic.base import View ``` ## Estilo dos templates - No código de templates Django, coloque um (e somente um) espaço entre as chaves e o conteúdo da tag. Faça isso: ```html+django {{ foo }} ``` Não faça isso: ```html+django {{foo}} ``` ## Estilo de uma View - Nas views do Django, o primeiro parâmetro na função de uma view deve ser chamado `request`. Faça isso: ``` def my_view(request, foo): # ... ``` Não faça isso: ``` def my_view(req, foo): # ... ``` ## Estilo de um Model - Os nomes dos campos devem ser todos minúsculos, usando underscores ao invés de camelCase. Faça isso: ``` class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) ``` Não faça isso: ``` class Person(models.Model): FirstName = models.CharField(max_length=20) Last_Name = models.CharField(max_length=40) ``` - A `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: ``` class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) class Meta: verbose_name_plural = 'people' ``` Não faça isso: ``` class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) class Meta: verbose_name_plural = 'people' ``` Não faça isso também: ``` class Person(models.Model): class Meta: verbose_name_plural = 'people' first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) ``` - A 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): - Todos 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 list of tuples, with an all-uppercase name as a class attribute on the model. Example: ``` class MyModel(models.Model): DIRECTION_UP = 'U' DIRECTION_DOWN = 'D' DIRECTION_CHOICES = [ (DIRECTION_UP, 'Up'), (DIRECTION_DOWN, 'Down'), ] ``` ## Utilização do `django.conf.settings` 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 [`DJANGO_SETTINGS_MODULE`](/pt-br/4.0/topics/settings/#envvar-DJANGO_SETTINGS_MODULE) environment variable) is allowed and possible as follows: ``` from django.conf import settings settings.configure({}, SOME_SETTING='foo') ``` Poré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: ``` from django.conf import settings from django.urls import get_callable default_foo_view = get_callable(settings.FOO_VIEW) ``` A 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. Ao 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`. ## Variados - Marque todas as strings para internacionalização; veja a documentação [i18n](/pt-br/4.0/topics/i18n/) para mais detalhes. - Remova comandos `import` que não são mais usados quando você mudar o código. O [flake8](https://pypi.org/project/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. ## Estilo JavaScript Para detalhes sobre o estilo de código JavaScript adotado no Django, veja [JavaScript](/pt-br/4.0/internals/contributing/writing-code/javascript/).