From 5bf505e822242912e547cb9511796b1bef19067e Mon Sep 17 00:00:00 2001 From: Dave Page Date: Fri, 4 Mar 2016 13:17:13 +0000 Subject: [PATCH] Add file missing from previous commit. --- docs/en_US/code-review.rst | 55 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 docs/en_US/code-review.rst diff --git a/docs/en_US/code-review.rst b/docs/en_US/code-review.rst new file mode 100644 index 000000000..daea05e76 --- /dev/null +++ b/docs/en_US/code-review.rst @@ -0,0 +1,55 @@ +Code Review Notes +================= + +This document lists a number of standard items that will be checked during the +review process for any patches submitted for inclusion in pgAdmin. + +* Ensure all code follows the pgAdmin :doc:`coding-standards`. + +* Copyright years must be correct and properly formatted (to make it easy to make + bulk updates every year). The start date should always be 2013, and the end year + the current year, e.g. + + Copyright (C) 2013 - 2016, The pgAdmin Development Team + +* Ensure there's a blank line immediately following any copyright headers. + +* Include PyDoc comments for functions, classes and modules. Node modules should + be """Implements the XXXX node""". + +* Ensure that any generated SQL does not have any leading or trailing blank lines + and consistently uses 4 space indents for nice formatting. + +* Don't special-case any Slony objects. pgAdmin 4 will have no direct knowledge + of Slony, unlike pgAdmin 3. + +* If you copy/paste modules, please ensure any comments are properly updated. + +* Read all comments, and ensure they make sense and provide useful commentary on + the code. + +* Ensure that field labels both use PostgreSQL parlance, but also are descriptive. + A good example is the "Init" field on an FTS Template - Init is the PG term, but + adding the word "Function" after it makes it much more descriptive. + +* Re-use code whereever possible, but factor it out into a suitably central + location - don't copy and paste it unless modifications are required! + +* Format code nicely to make it readable. Break up logical chunks of code with + blank lines, and comment well to describe what different sections of code are + for or pertain to. + +* Ensure that form validation works correctly and is consistent with other + dialogues in the way errors are displayed. + +* On dialogues with Schema or Owner fields, pre-set the default values to the + current schema/user as appropriate. In general, if there are common or sensible + default values available, put them in the fields for the user. + +* 1 patch == 1 feature. If you need to fix/update existing infrastructure in + your patch, it's usually easier if it's in a separate patch. Patches containing + multiple new features or unrelated changes are likely to be rejected. + +* Ensure the patch is fully functional, and works! If a patch is being sent as + a work in progress, not intended for commit, clearly state that it's a WIP, + and note what does or does not yet work. \ No newline at end of file