styleguide.rst

Translate Styleguide

The Translate styleguide is the styleguide for all Translate projects, including Translate Toolkit, Pootle, Virtaal and others. Patches are required to follow these guidelines.

This Styleguide follows 8 with some clarifications. It is based almost verbatim on the Flask Styleguide.

General

Indentation:

4 real spaces, no tabs. Exceptions, modules that have copied into the source that don't follow this guideline.

Maximum line length:

79 characters with a soft limit for 84 if absolutely necessary. Try to avoid too nested code by cleverly placing break, continue and return statements.

Continuing long statements:

To continue a statement you can use backslashes (preceeded by a space) in which case you should align the next line with the last dot or equal sign, or indent four spaces:

MyModel.query.filter(MyModel.scalar > 120) \
             .order_by(MyModel.name.desc()) \
             .limit(10)

my_long_assignment = MyModel.query.filter(MyModel.scalar > 120) \
                     .order_by(MyModel.name.desc()) \
                     .limit(10)

this_is_a_very_long(function_call, 'with many parameters') \
    .that_returns_an_object_with_an_attribute

If you break in a statement with parentheses or braces, align to the braces:

this_is_a_very_long(function_call, 'with many parameters',
                    23, 42, 'and even more')

For lists or tuples with many items, break immediately after the opening brace:

items = [
    'this is the first', 'set of items', 'with more items',
    'to come in this line', 'like this'
]

Blank lines:

Top level functions and classes are separated by two lines, everything else by one. Do not use too many blank lines to separate logical segments in code. Example:

def hello(name):
    print 'Hello %s!' % name


def goodbye(name):
    print 'See you %s.' % name


class MyClass(object):
    """This is a simple docstring"""

    def __init__(self, name):
        self.name = name

    def get_annoying_name(self):
        return self.name.upper() + '!!!!111'

Expressions and Statements

General whitespace rules:

• No whitespace for unary operators that are not words (e.g.: -, ~ etc.) as well on the inner side of parentheses.
• Whitespace is placed between binary operators.

Good:

exp = -1.05
value = (item_value / item_count) * offset / exp
value = my_list[index]
value = my_dict['key']

Bad:

exp = - 1.05
value = ( item_value / item_count ) * offset / exp
value = (item_value/item_count)*offset/exp
value=( item_value/item_count ) * offset/exp
value = my_list[ index ]
value = my_dict ['key']

Slice notation:

While 8 calls for spaces around operators a = b + c this results in flags when you use a[b+1:c-1] but would allow the rather unreadable a[b + 1:c - 1] to pass. 8 is rather quiet on slice notation.

• Don't use spaces with simple variables or numbers
• Use brackets for expressions with spaces between binary operators

Good:

a[1:2]
a[start:end]
a[(start - 1):(end + var + 2)]  # Brackets help group things and don't hide the slice
a[-1:(end + 1)]

Bad:

a[start: end]  # No spaces around :
a[start-1:end+var+2]  # Insanely hard to read, especially when your expressions are more complex
a[start - 1:end + 2]  # You lose sight of the fact that it is a slice
a[- 1:end]  # -1 is unary, no space

Note

String slice formating is still under discussion.

Comparisons:

• against arbitrary types: == and !=
• against singletons with is and is not (eg: foo is not None)
• never compare something with True or False (for example never do foo == False, do not foo instead)

Negated containment checks:

use foo not in bar instead of not foo in bar

Instance checks:

isinstance(a, C) instead of type(A) is C, but try to avoid instance checks in general. Check for features.

If statements:

• Use () brackets around complex if statements to allow easy wrapping, don't use backslash to wrap an if statements.
• Wrap between and, or, etc.
• Keep not with the expression
• Use () alignment between expressions
• Use extra () to eliminate abiguity, don't rely on an understanding of Python operator precedent rules.

Good:

if length >= (upper + 2)

if (length >= 25 and
    string != "Something" and
    not careful):
    do_something()

Bad:

if length >= upper + 2:

if (length...
    and string !=...

Naming Conventions

Note

This has not been implemented or discussed. The Translate code is not at all consistent with these conventions.

• Class names: CamelCase, with acronyms kept uppercase (HTTPWriter and not HttpWriter)
• Variable names: lowercase_with_underscores
• Method and function names: lowercase_with_underscores
• Constants: UPPERCASE_WITH_UNDERSCORES
• precompiled regular expressions: name_re

Protected members are prefixed with a single underscore. Double underscores are reserved for mixin classes.

On classes with keywords, trailing underscores are appended. Clashes with builtins are allowed and must not be resolved by appending an underline to the variable name. If the function needs to access a shadowed builtin, rebind the builtin to a different name instead.

Function and method arguments:

• class methods: cls as first parameter
• instance methods: self as first parameter
• lambdas for properties might have the first parameter replaced with x like in display_name = property(lambda x: x.real_name or x.username)

Documentation

Docstrings

We use Sphinx to generate our API documentation. Read the reStructuredText primer and Sphinx documentation as needed.

Docstring conventions:

All docstrings are formatted with reStructuredText as understood by Sphinx. Depending on the number of lines in the docstring, they are laid out differently. If it's just one line, the closing triple quote is on the same line as the opening, otherwise the text is on the same line as the opening quote and the triple quote that closes the string on its own line:

def foo():
    """This is a simple docstring."""


def bar():
    """This is a longer docstring with so much information in there
    that it spans three lines.  In this case the closing triple quote
    is on its own line.
    """

Please read 257 (Docstring Conventions) for a general overview, the important parts though are:

• A docstring should have a brief one-line summary, ending with a period.
• If there are more details there should be a blank line between the one-line summary and the rest of the text. Use pragraphs and formating as needed.
• Use reST field lists to describe the input parameters and/or return types as the last part of the docstring.
• Use proper capitalisation and punctuation.
• Don't restate things that would appear in parameter descriptions.

def foo(bar):
    """One line description.

    Further explanations that might be needed.

    :param bar: Parameter descriptions.
    """

def addunit(self, unit):
    """Appends the given unit to the object's list of units.

    This method should always be used rather than trying to modify the
    list manually.

    :type unit: TranslationUnit
    :param unit: Any object that inherits from :class:`TranslationUnit`.
    """
    self.units.append(unit)

Parameter documentation:

Document parameters using reST field lists as follows:

def foo(bar):
    """Simple docstring

    :param bar: Something
    :type bar: Some type
    :return: Returns something
    :rtype: Return type 
    """

Cross refencing code:

When talking about other objects, methods, functions and variables it is good practice to cross-reference them with Sphinx's Python cross-referencing.

Other directives:

Use paragraph-level markup when needed.

Note

We still Need to gather the useful ones that we want you to use and how to use then. E.g. how to talk about a paramter in the docstring. How to reference classes in the module. How to reference other modules, etc.

Module header:

The module header consists of an utf-8 encoding declaration, copyright attribution, license block and a standard docstring:

# -*- coding: utf-8 -*-
#
... LICENSE BLOCK...

"""A brief description"""

"""

Comments

General:

• The # symbol (pound or hash) is used to start comments.
• A space must follow the # between any written text.
• Line length must be observed.
• Inline comments are preceeded by two spaces.
• Write sentences correctly: proper capitalisation and punctuation.

Good:

# Good comment with space before and full sentence.
statement  # Good comment with two spaces

Bad:

#Bad comment no space before
statement # Bad comment, needs two spaces

Docstring comments:

Rules for comments are similar to docstrings. Both are formatted with reStructuredText. If a comment is used to document an attribute, put a colon after the opening pound sign (#):

class User(object):
    #: the name of the user as unicode string
    name = Column(String)
    #: the sha1 hash of the password + inline salt
    pw_hash = Column(String)