From 32bc2b4fc1cd63e3011fcfd36012daf24c650838 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 10 Dec 2014 13:11:43 +0000 Subject: update codestyle based on debate on #matrix-dev --- docs/code_style.rst | 37 ++++++++++++++++++++++++++++++++++--- 1 file changed, 34 insertions(+), 3 deletions(-) (limited to 'docs/code_style.rst') diff --git a/docs/code_style.rst b/docs/code_style.rst index d7e2d5e69e..6e53f3eb09 100644 --- a/docs/code_style.rst +++ b/docs/code_style.rst @@ -1,10 +1,14 @@ Basically, PEP8 -- Max line width: 80 chars. +- NEVER tabs. 4 spaces to indent. +- Max line width: 79 chars (with flexibility to overflow by a "few chars" if + the overflowing content is not semantically significant and avoids an + explosion of vertical whitespace). - Use camel case for class and type names - Use underscores for functions and variables. - Use double quotes. -- Use parentheses instead of '\' for line continuation where ever possible (which is pretty much everywhere) +- Use parentheses instead of '\\' for line continuation where ever possible + (which is pretty much everywhere) - There should be max a single new line between: - statements - functions in a class @@ -14,5 +18,32 @@ Basically, PEP8 - a single space after a comma - a single space before and after for '=' when used as assignment - no spaces before and after for '=' for default values and keyword arguments. +- Indenting must follow PEP8; either hanging indent or multiline-visual indent + depending on the size and shape of the arguments and what makes more sense to + the author. In other words, both this:: -Comments should follow the google code style. This is so that we can generate documentation with sphinx (http://sphinxcontrib-napoleon.readthedocs.org/en/latest/) + print("I am a fish %s", "moo") + + and this:: + + print("I am a fish %s", + "moo") + + and this:: + + print( + "I am a fish %s", + "moo" + ) + + ...are valid, although given each one takes up 2x more vertical space than + the previous, it's up to the author's discretion as to which layout makes most + sense for their function invocation. (e.g. if they want to add comments + per-argument, or put expressions in the arguments, or group related arguments + together, or want to deliberately extend or preserve vertical/horizontal + space) + +Comments should follow the google code style. This is so that we can generate +documentation with sphinx (http://sphinxcontrib-napoleon.readthedocs.org/en/latest/) + +Code should pass pep8 --max-line-length=100 without any warnings. -- cgit 1.4.1 From 8ffbb52eeea4827220fc851189d95ebed824285a Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 10 Dec 2014 13:43:34 +0000 Subject: oops --- docs/code_style.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'docs/code_style.rst') diff --git a/docs/code_style.rst b/docs/code_style.rst index 6e53f3eb09..dc40a7ab7b 100644 --- a/docs/code_style.rst +++ b/docs/code_style.rst @@ -22,17 +22,17 @@ Basically, PEP8 depending on the size and shape of the arguments and what makes more sense to the author. In other words, both this:: - print("I am a fish %s", "moo") + print("I am a fish %s" % "moo") and this:: - print("I am a fish %s", + print("I am a fish %s" % "moo") and this:: print( - "I am a fish %s", + "I am a fish %s" % "moo" ) -- cgit 1.4.1