From 5eeb2d56d50dc7b280cd11267add8cf2da5f26a3 Mon Sep 17 00:00:00 2001 From: Julien Phalip Date: Fri, 26 Aug 2011 02:43:33 +0000 Subject: [PATCH] Added some tips to the contributor docs, namely about removing trailing whitespaces and about mentioning relevant ticket numbers in tests. git-svn-id: http://code.djangoproject.com/svn/django/trunk@16688 bcc190cf-cafb-0310-a4f2-bffc1f526a37 --- docs/internals/contributing/writing-code/coding-style.txt | 6 ++++++ .../contributing/writing-code/submitting-patches.txt | 7 +++++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt index 7a07735616..34eef100c7 100644 --- a/docs/internals/contributing/writing-code/coding-style.txt +++ b/docs/internals/contributing/writing-code/coding-style.txt @@ -184,6 +184,12 @@ Miscellaneous * 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. + * 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 diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt index 8190206106..85e81ab9b0 100644 --- a/docs/internals/contributing/writing-code/submitting-patches.txt +++ b/docs/internals/contributing/writing-code/submitting-patches.txt @@ -101,8 +101,11 @@ Patch style * The code required to fix a problem or add a feature is an essential part of a patch, but it is not the only part. A good patch should also - include a regression test to validate the behavior that has been fixed, - to prevent the problem from arising again. + include a regression test to validate the behavior that has been fixed + and to prevent the problem from arising again. Also, if some tickets are + relevant to the code that you've written, mention the ticket numbers in + some comments in the test so that one can easily trace back the relevant + discussions after your patch gets committed and the tickets get closed. * If the code associated with a patch adds a new feature, or modifies behavior of an existing feature, the patch should also contain