From 62bfbf22dfd23cca3a2536476d92ccfa6e5f24f4 Mon Sep 17 00:00:00 2001 From: Keshava Bharadwaj Date: Wed, 16 Oct 2013 16:30:23 +0530 Subject: Cleanup and make HACKING.rst DRYer Reference the OpenStack hacking guide in HACKING.rst and remove duplicate entries. Adds placeholder section for neutron specific rules. Change-Id: I4bfbab50b77e7592178dda44c7f4f52edc7fdc21 --- HACKING.rst | 197 +++--------------------------------------------------------- 1 file changed, 7 insertions(+), 190 deletions(-) (limited to 'HACKING.rst') diff --git a/HACKING.rst b/HACKING.rst index 8801eea9e9..98c348affe 100644 --- a/HACKING.rst +++ b/HACKING.rst @@ -1,197 +1,14 @@ Neutron Style Commandments -========================== +======================= -- Step 1: Read http://www.python.org/dev/peps/pep-0008/ -- Step 2: Read http://www.python.org/dev/peps/pep-0008/ again -- Step 3: Read on +- Step 1: Read the OpenStack Style Commandments + https://github.com/openstack-dev/hacking/blob/master/doc/source/index.rst +- Step 2: Read on +Neutron Specific Commandments +-------------------------- -General -------- -- Put two newlines between top-level code (funcs, classes, etc) -- Put one newline between methods in classes and anywhere else -- Do not write "except:", use "except Exception:" at the very least -- Include your name with TODOs as in "#TODO(termie)" -- Do not shadow a built-in or reserved word. Example:: - - def list(): - return [1, 2, 3] - - mylist = list() # BAD, shadows `list` built-in - - class Foo(object): - def list(self): - return [1, 2, 3] - - mylist = Foo().list() # OKAY, does not shadow built-in - - -Imports -------- -- Do not make relative imports -- Order your imports by the full module path - -Example:: - - The following imports, - - from neutron.api import networks - from neutron import wsgi - - are considered equivalent for ordering purposes to - - import neutron.api.networks - import neutron.wsgi - -- Organize your imports according to the following template - -Example:: - - # vim: tabstop=4 shiftwidth=4 softtabstop=4 - {{stdlib imports in human alphabetical order}} - \n - {{third-party lib imports in human alphabetical order}} - \n - {{neutron imports in human alphabetical order}} - \n - \n - {{begin your code}} - - -Human Alphabetical Order Examples ---------------------------------- -Example:: - - import httplib - import random - import StringIO - import time - - import eventlet - import testtools - import webob.exc - - import neutron.api.networks - from neutron.api import ports - from neutron.db import models - from neutron.extensions import multiport - import neutron.manager - from neutron.openstack.common import log as logging - from neutron import service - - -Docstrings ----------- -Example:: - - """A one line docstring looks like this and ends in a period.""" - - - """A multiline docstring has a one-line summary, less than 80 characters. - - Then a new paragraph after a newline that explains in more detail any - general information about the function, class or method. Example usages - are also great to have here if it is a complex class for function. - - When writing the docstring for a class, an extra line should be placed - after the closing quotations. For more in-depth explanations for these - decisions see http://www.python.org/dev/peps/pep-0257/ - - If you are going to describe parameters and return values, use Sphinx, the - appropriate syntax is as follows. - - :param foo: the foo parameter - :param bar: the bar parameter - :returns: return_type -- description of the return value - :returns: description of the return value - :raises: AttributeError, KeyError - """ - - -Dictionaries/Lists ------------------- -If a dictionary (dict) or list object is longer than 80 characters, its items -should be split with newlines. Embedded iterables should have their items -indented. Additionally, the last item in the dictionary should have a trailing -comma. This increases readability and simplifies future diffs. - -Example:: - - my_dictionary = { - "image": { - "name": "Just a Snapshot", - "size": 2749573, - "properties": { - "user_id": 12, - "arch": "x86_64", - }, - "things": [ - "thing_one", - "thing_two", - ], - "status": "ACTIVE", - }, - } - - -Calling Methods ---------------- -Calls to methods 80 characters or longer should format each argument with -newlines. This is not a requirement, but a guideline:: - - unnecessarily_long_function_name('string one', - 'string two', - kwarg1=constants.ACTIVE, - kwarg2=['a', 'b', 'c']) - - -Rather than constructing parameters inline, it is better to break things up:: - - list_of_strings = [ - 'what_a_long_string', - 'not as long', - ] - - dict_of_numbers = { - 'one': 1, - 'two': 2, - 'twenty four': 24, - } - - object_one.call_a_method('string three', - 'string four', - kwarg1=list_of_strings, - kwarg2=dict_of_numbers) - - -Internationalization (i18n) Strings ------------------------------------ -In order to support multiple languages, we have a mechanism to support -automatic translations of exception and log strings. - -Example:: - - msg = _("An error occurred") - raise HTTPBadRequest(explanation=msg) - -If you have a variable to place within the string, first internationalize the -template string then do the replacement. - -Example:: - - msg = _("Missing parameter: %s") % ("flavor",) - LOG.error(msg) - -If you have multiple variables to place in the string, use keyword parameters. -This helps our translators reorder parameters when needed. - -Example:: - - msg = _("The server with id %(s_id)s has no key %(m_key)s") - LOG.error(msg % {"s_id": "1234", "m_key": "imageId"}) - -Please do not use locals() for string substitutions. - +None so far Creating Unit Tests ------------------- -- cgit v1.2.1