--- title: "Coding style" version: 2.2 locale: fr source: https://docs.djangoproject.com/fr/2.2/internals/contributing/writing-code/coding-style/ canonical: https://djangodocs.dev/fr/2.2/internals/contributing/writing-code/coding-style/ --- # Coding style Please follow these coding standards when writing code for inclusion in Django. ## Python style - Please conform to the indentation style dictated in the `.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. - Unless otherwise specified, follow [**PEP 8**](https://peps.python.org/pep-0008/). Use [flake8](https://pypi.org/project/flake8/) to check for problems in this area. Note that our `setup.cfg` file contains some excluded files (deprecated modules we don’t care about cleaning up and some third-party code that Django vendors) as well as some excluded errors that we don’t consider as gross violations. Remember that [**PEP 8**](https://peps.python.org/pep-0008/) is only a guide, so respect the style of the surrounding code as a primary goal. 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 119 characters as this is the width of GitHub code review; anything longer requires horizontal scrolling which makes review more difficult. 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. - Utilisez 4 espaces pour l’indentation. - Use four space hanging indentation rather than vertical alignment: ``` raise AttributeError( 'Here is a multiline error message ' 'shortened for clarity.' ) ``` Instead of: ``` raise AttributeError('Here is a multiline error message ' 'shortened for clarity.') ``` This makes better use of space and avoids having to realign strings if the length of the first line changes. - Use single quotes for strings, or a double quote if the string contains a single quote. Don’t waste time doing unrelated refactoring of existing code to 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 (i.e. `poll.get_unique_voters()`, not `poll.getUniqueVoters()`). - Use `InitialCaps` for class names (or for factory functions that return classes). - In docstrings, follow the style of existing docstrings and [**PEP 257**](https://peps.python.org/pep-0257/). - In tests, use [`assertRaisesMessage()`](/fr/2.2/topics/testing/tools/#django.test.SimpleTestCase.assertRaisesMessage) and [`assertWarnsMessage()`](/fr/2.2/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. - 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). """ ... ``` ## Importations - Utilisez [isort](https://github.com/timothycrosley/isort#readme) pour automatiser le tri des importations en suivant les directives ci-dessous. Pour faire vite : ```console $ pip install isort $ isort -rc . ``` *Windows* ```doscon ...\> pip install isort ...\> isort -rc . ``` Ceci 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 ``` - Placez 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. Placez 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. Par exemple (les commentaires ne sont qu’à titre informatif) : *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: # ... ``` - Utilisez des importations les plus directes possibles quand elles sont disponibles ``` from django.views import View ``` au lieu de ``` from django.views.generic.base import View ``` ## Style des gabarits - Dans le code des gabarits Django, placez un et un seul espace entre les accolades et le contenu des balises. Faites : ```html+django {{ foo }} ``` Ne faites pas : ```html+django {{foo}} ``` ## Style des vues - Dans les vues de Django, le premier paramètre d’une vue fonction devrait s’appeler `request`. Faites ``` def my_view(request, foo): # ... ``` Ne faites pas : ``` def my_view(req, foo): # ... ``` ## Style des modèles - Les noms de champs devraient être tout en minuscules, en utilisant des soulignements au lieu du StyleChameau. Faites ``` class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) ``` Ne faites pas : ``` class Person(models.Model): FirstName = models.CharField(max_length=20) Last_Name = models.CharField(max_length=40) ``` - La `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 ``` class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) class Meta: verbose_name_plural = 'people' ``` Ne faites pas : ``` class Person(models.Model): first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) class Meta: verbose_name_plural = 'people' ``` Ne faites pas ça non plus : ``` class Person(models.Model): class Meta: verbose_name_plural = 'people' first_name = models.CharField(max_length=20) last_name = models.CharField(max_length=40) ``` - L’ordre des classes internes de modèles et des méthodes standards doit être le suivant (notez qu’elles ne sont pas toutes obligatoires) : - Tous 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): DIRECTION_UP = 'U' DIRECTION_DOWN = 'D' DIRECTION_CHOICES = [ (DIRECTION_UP, 'Up'), (DIRECTION_DOWN, 'Down'), ] ``` ## Utilisation de `django.conf.settings` 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 settings.configure({}, SOME_SETTING='foo') ``` Cependant, 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 ``` from django.conf import settings from django.urls import get_callable default_foo_view = get_callable(settings.FOO_VIEW) ``` …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`. ## Divers - Marquez toutes les chaînes à traduire ; voir la [documentation i18n](/fr/2.2/topics/i18n/) pour plus de détails. - Supprimez les instructions `import` qui ne sont plus utilisées lorsque vous modifiez du code. [flake8](https://pypi.org/project/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. ## Style JavaScript Pour plus de détails sur le style de code JavaScript utilisé par Django, consultez [JavaScript](/fr/2.2/internals/contributing/writing-code/javascript/).