From d1e5c55258d624058a93c8cacdb1f25ae7857554 Mon Sep 17 00:00:00 2001 From: Luke Plant Date: Fri, 14 Oct 2011 00:12:01 +0000 Subject: Fixed many more ReST indentation errors, somehow accidentally missed from [16955] git-svn-id: http://code.djangoproject.com/svn/django/trunk@16983 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- .../contributing/writing-code/coding-style.txt | 208 ++++++++++----------- 1 file changed, 104 insertions(+), 104 deletions(-) (limited to 'docs/internals/contributing/writing-code/coding-style.txt') diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt index 6c3c1b3a25..915cc7724b 100644 --- a/docs/internals/contributing/writing-code/coding-style.txt +++ b/docs/internals/contributing/writing-code/coding-style.txt @@ -7,137 +7,137 @@ Please follow these coding standards when writing code for inclusion in Django. Python style ------------ - * Unless otherwise specified, follow :pep:`8`. +* Unless otherwise specified, follow :pep:`8`. - You could use a tool like `pep8`_ to check for some problems in this - area, but remember that :pep:`8` is only a guide, so respect the style of - the surrounding code as a primary goal. + You could use a tool like `pep8`_ to check for some problems in this + area, but remember that :pep:`8` is only a guide, so respect the style of + the surrounding code as a primary goal. - * Use four spaces for indentation. +* Use four spaces for indentation. - * Use underscores, not camelCase, for variable, function and method names - (i.e. ``poll.get_unique_voters()``, not ``poll.getUniqueVoters``). +* 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). +* Use ``InitialCaps`` for class names (or for factory functions that + return classes). - * In docstrings, use "action words" such as:: +* In docstrings, use "action words" such as:: - def foo(): - """ - Calculates something and returns the result. - """ - pass + def foo(): + """ + Calculates something and returns the result. + """ + pass - Here's an example of what not to do:: + Here's an example of what not to do:: - def foo(): - """ - Calculate something and return the result. - """ - pass + def foo(): + """ + Calculate something and return the result. + """ + pass Template style -------------- - * In Django template code, put one (and only one) space between the curly - brackets and the tag contents. +* In Django template code, put one (and only one) space between the curly + brackets and the tag contents. - Do this: + Do this: - .. code-block:: html+django + .. code-block:: html+django - {{ foo }} + {{ foo }} - Don't do this: + Don't do this: - .. code-block:: html+django + .. code-block:: html+django - {{foo}} + {{foo}} View style ---------- - * In Django views, the first parameter in a view function should be called - ``request``. +* In Django views, the first parameter in a view function should be called + ``request``. - Do this:: + Do this:: - def my_view(request, foo): - # ... + def my_view(request, foo): + # ... - Don't do this:: + Don't do this:: - def my_view(req, foo): - # ... + def my_view(req, foo): + # ... Model style ----------- - * Field names should be all lowercase, using underscores instead of - camelCase. +* Field names should be all lowercase, using underscores instead of + camelCase. - Do this:: + Do this:: - class Person(models.Model): - first_name = models.CharField(max_length=20) - last_name = models.CharField(max_length=40) + class Person(models.Model): + first_name = models.CharField(max_length=20) + last_name = models.CharField(max_length=40) - Don't do this:: + Don't do this:: - class Person(models.Model): - FirstName = models.CharField(max_length=20) - Last_Name = models.CharField(max_length=40) + class Person(models.Model): + FirstName = models.CharField(max_length=20) + Last_Name = models.CharField(max_length=40) - * The ``class Meta`` should appear *after* the fields are defined, with - a single blank line separating the fields and the class definition. +* The ``class Meta`` should appear *after* the fields are defined, with + a single blank line separating the fields and the class definition. - Do this:: + Do this:: - class Person(models.Model): - first_name = models.CharField(max_length=20) - last_name = models.CharField(max_length=40) + class Person(models.Model): + first_name = models.CharField(max_length=20) + last_name = models.CharField(max_length=40) - class Meta: - verbose_name_plural = 'people' + class Meta: + verbose_name_plural = 'people' - Don't do this:: + Don't do this:: - class Person(models.Model): - first_name = models.CharField(max_length=20) - last_name = models.CharField(max_length=40) - class Meta: - verbose_name_plural = 'people' + class Person(models.Model): + first_name = models.CharField(max_length=20) + last_name = models.CharField(max_length=40) + class Meta: + verbose_name_plural = 'people' - Don't do this, either:: + Don't do this, either:: - class Person(models.Model): - class Meta: - verbose_name_plural = 'people' + class Person(models.Model): + class Meta: + verbose_name_plural = 'people' - first_name = models.CharField(max_length=20) - last_name = models.CharField(max_length=40) + first_name = models.CharField(max_length=20) + last_name = models.CharField(max_length=40) - * The order of model inner classes and standard methods should be as - follows (noting that these are not all required): +* The order of model inner classes and standard methods should be as + follows (noting that these are not all required): - * All database fields - * Custom manager attributes - * ``class Meta`` - * ``def __unicode__()`` - * ``def __str__()`` - * ``def save()`` - * ``def get_absolute_url()`` - * Any custom methods + * All database fields + * Custom manager attributes + * ``class Meta`` + * ``def __unicode__()`` + * ``def __str__()`` + * ``def save()`` + * ``def get_absolute_url()`` + * Any custom methods - * If ``choices`` is defined for a given model field, define the choices as - a tuple of tuples, with an all-uppercase name, either near the top of - the model module or just above the model class. Example:: +* If ``choices`` is defined for a given model field, define the choices as + a tuple of tuples, with an all-uppercase name, either near the top of + the model module or just above the model class. Example:: - GENDER_CHOICES = ( - ('M', 'Male'), - ('F', 'Female'), - ) + GENDER_CHOICES = ( + ('M', 'Male'), + ('F', 'Female'), + ) Use of ``django.conf.settings`` ------------------------------- @@ -178,26 +178,26 @@ as :class:`django.utils.functional.LazyObject`, Miscellaneous ------------- - * Mark all strings for internationalization; see the :doc:`i18n - documentation ` for details. - - * Remove ``import`` statements that are no longer used when you change code. - The most common tools for this task are `pyflakes`_ and `pylint`_. - - * Systematically remove all trailing whitespaces from your code as those - add unnecessary bytes, add visual clutter to the patches and can also - occasionally cause unnecessary merge conflicts. Some IDE's can be - configured to automatically remove them and most VCS tools can be set to - highlight them in diff outputs. Note, however, that patches which only - remove whitespace (or only make changes for nominal PEP 8 conformance) - are likely to be rejected, since they only introduce noise rather than - code improvement. Tidy up when you're next changing code in the area. - - * Please don't put your name in the code you contribute. Our policy is to - keep contributors' names in the ``AUTHORS`` file distributed with Django - -- not scattered throughout the codebase itself. Feel free to include a - change to the ``AUTHORS`` file in your patch if you make more than a - single trivial change. +* Mark all strings for internationalization; see the :doc:`i18n + documentation ` for details. + +* Remove ``import`` statements that are no longer used when you change code. + The most common tools for this task are `pyflakes`_ and `pylint`_. + +* Systematically remove all trailing whitespaces from your code as those + add unnecessary bytes, add visual clutter to the patches and can also + occasionally cause unnecessary merge conflicts. Some IDE's can be + configured to automatically remove them and most VCS tools can be set to + highlight them in diff outputs. Note, however, that patches which only + remove whitespace (or only make changes for nominal PEP 8 conformance) + are likely to be rejected, since they only introduce noise rather than + code improvement. Tidy up when you're next changing code in the area. + +* Please don't put your name in the code you contribute. Our policy is to + keep contributors' names in the ``AUTHORS`` file distributed with Django + -- not scattered throughout the codebase itself. Feel free to include a + change to the ``AUTHORS`` file in your patch if you make more than a + single trivial change. .. _pep8: http://pypi.python.org/pypi/pep8 .. _pyflakes: http://pypi.python.org/pypi/pyflakes -- cgit v1.3