Development:Coding Standards

From OpenLP

(Redirected from Coding Standards)
Jump to: navigation, search

Contents

Introduction

Any programming project needs coding standards, so that everyone knows what their code needs to look like and can read everyone elses' code easily. Python is a very nice language from this perspective, as it forces the developer to stick to some coding standards by way of indentation and lack of braces. However, this is not all there is to coding standards.

The coding standards we're using in openlp.org 2.0 are based on Python's PEP 8, and a little on Qt's coding standards.

Syntax

Code Layout

Indentation

The most popular way of indenting Python is with 4 spaces, and no tabs. For new projects, spaces-only are strongly recommended over tabs, so we will be using spaces.

Maximum Line Length

Limit all lines to a maximum of 79 80 characters. Wrap lines if necessary.

The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. If necessary, you can add an extra pair of parentheses around an expression, but sometimes using a backslash looks better. Make sure to indent the continued line appropriately. Indentation is only 1 level, i.e. 4 spaces. The preferred place to break around a binary operator is *after* the operator, not before it. 

  1. self.addToolbarButton(translate('SongMediaItem', 'New Song'),
  2.     translate('SongMediaItem', 'Add a new song'),
  3.     ':/songs/song_new.png', self.onSongNewClick, 'SongNewItem')
  4. if one == 1 and two == 2 and three == 3 and \
  5.     four == 4 and five == 5:
  6.     six = 6

Blank Lines

Separate top-level function and class definitions with two blank lines. Method definitions inside a class are separated by a single blank line.

Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines may be omitted between a bunch of related one-liners (e.g. a set of dummy implementations).

Try not to use blank lines in functions, unless you want to specifically indicate logical sections. Use them sparingly.

Encodings

We use UTF-8 in all our files. All code should be in the traditional English alphabet. Use the following comment at the top of every file: 

  1. # -*- coding: utf-8 -*-

Line endings

Line endings must conform to the UNIX standard ('\n') not the Windows standard ('\r\n').

Many Windows programming text editors/IDE's have a setting to configure this. There are also command line utilities available to convert them (e.g. tofrodos).

In addition, each source file should end with a single blank/empty line.

Imports

Imports should usually be on separate lines, e.g.: 

  1. # Yes:
  2. import os
  3. import sys
  4.  
  5. # No:
  6. import sys, os


It's okay to import more than one object from the same module, however: 

  1. from subprocess import Popen, PIPE


Imports should be grouped in the following order:

  1. standard library imports
  2. related third party imports
  3. local application/library specific imports

You should put a blank line between each group of imports. Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants. Put any relevant __all__ specification after the imports.

Relative imports for intra-package imports are highly discouraged. Always use the absolute package path for all imports.

When importing a class from a class-containing module, it's usually okay to do this: 

  1. from myclass import MyClass
  2. from foo.bar.yourclass import YourClass
  3. a = MyClass()
  4. b = YourClass()


If this causes local name clashes, then do the following: 

  1. import myclass
  2. import foo.bar.yourclass
  3. a = myclass.MyClass()
  4. b = foo.bar.yourclass.YourClass()


Whitespace

Avoid extraneous whitespace in the following situations:

Immediately inside parentheses, brackets or braces. 

  1. # Yes:
  2. spam(ham[1], {eggs: 2})
  3.  
  4. # No:
  5. spam( ham[ 1 ], { eggs: 2 } )


Immediately before a comma, semicolon, or colon: 

  1. # Yes:
  2. if x == 4: print x, y; x, y = y, x
  3.  
  4. # No:
  5. if x == 4 : print x , y ; x , y = y , x


Immediately before the open parenthesis that starts the argument list of a function call: 

  1. # Yes:
  2. spam(1)
  3.  
  4. # No:
  5. spam (1)


Immediately before the open parenthesis that starts an indexing or slicing: 

  1. # Yes:
  2. dict['key'] = list[index]
  3.  
  4. # No:
  5. dict ['key'] = list [index]


More than one space around an assignment (or other) operator to align it with another. 

  1. # Yes:
  2. x = 1
  3. y = 2
  4. long_variable = 3
  5.  
  6. # No:
  7. x             = 1
  8. y             = 2
  9. long_variable = 3


Always surround these binary operators with a single space on either side: assignment (=), augmented assignment (+=, -= etc.), comparisons (==, <, >, !=, <>, <=, >=, in, not in, is, is not), Booleans (and, or, not).

Use spaces around arithmetic operators: 

  1. # Yes:
  2. i = i + 1
  3. submitted += 1
  4. x = x * 2 - 1
  5. hypot2 = x * x + y * y
  6. c = (a + b) * (a - b)
  7.  
  8. # No:
  9. i=i+1
  10. submitted +=1
  11. x = x*2 - 1
  12. hypot2 = x*x + y*y
  13. c = (a+b) * (a-b)


Don't use spaces around the '=' sign when used to indicate a keyword argument or a default parameter value. 

  1. # Yes:
  2. def complex(real, imag=0.0):
  3.     return magic(r=real, i=imag)
  4.  
  5. # No:
  6. def complex(real, imag = 0.0):
  7.     return magic(r = real, i = imag)


Compound statements (multiple statements on the same line) should not be used. 

  1. # Yes:
  2. if foo == 'blah':
  3.     do_blah_thing()
  4. do_one()
  5. do_two()
  6. do_three()
  7.  
  8. # No:
  9. if foo == 'blah': do_blah_thing()
  10.   do_one(); do_two(); do_three()


While sometimes it's okay to put an if/for/while with a small body on the same line, never do this for multi-clause statements. Also avoid folding such long lines! 

  1. # Rather not:
  2. if foo == 'blah': do_blah_thing()
  3. for x in lst: total += x
  4. while t < 10: t = delay()
  5.  
  6. # Definitely not:
  7. if foo == 'blah': do_blah_thing()
  8. else: do_non_blah_thing()
  9.  
  10. try: something()
  11. finally: cleanup()
  12.  
  13. do_one(); do_two(); do_three(long, argument,
  14.                              list, like, this)
  15.  
  16. if foo == 'blah': one(); two(); three()


Comments

Comments that contradict the code are worse than no comments. Always make a priority of keeping the comments up-to-date when the code changes!

Comments should be complete sentences. If a comment is a phrase or sentence, its first word should be capitalized, unless it is an identifier that begins with a lower case letter (never alter the case of identifiers!).

If a comment is short, the period at the end can be omitted. Block comments generally consist of one or more paragraphs built out of complete sentences, and each sentence should end in a period.

Python coders from non-English speaking countries: please write your comments in English, unless you are 120% sure that the code will never be read by people who don't speak your language.

Block Comments

Block comments generally apply to some (or all) code that follows them, and are indented to the same level as that code. Each line of a block comment starts with a # and a single space (unless it is indented text inside the comment).

Paragraphs inside a block comment are separated by a line containing a single #.

Inline Comments

Use inline comments sparingly.

An inline comment is a comment on the same line as a statement. Inline comments should be separated by at least two spaces from the statement. They should start with a # and a single space.

Inline comments are unnecessary and in fact distracting if they state the obvious. Don't do this: 

  1. x = x + 1                 # Increment x


But sometimes, this is useful: 

  1. x = x + 1                 # Compensate for border


Naming Conventions

Names to Avoid

Never use the characters 'l' (lowercase letter el), 'O' (uppercase letter oh), or 'I' (uppercase letter eye) as single character variable names. In some fonts, these characters are indistinguishable from the numerals one and zero. When tempted to use 'l', use 'L' instead.

Package & Module Names

Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability. Python packages should also have short, all-lowercase names, although the use of underscores is discouraged.

Since module names are mapped to file names, and some file systems are case insensitive and truncate long names, it is important that module names be chosen to be fairly short -- this won't be a problem on Unix, but it may be a problem when the code is transported to older Mac or Windows versions, or DOS.

When an extension module written in C or C++ has an accompanying Python module that provides a higher level (e.g. more object oriented) interface, the C/C++ module has a leading underscore (e.g. _socket).

Classes

Almost without exception, class names use the CapWords convention. Classes for internal use have a leading underscore in addition.

Pure Python

All pure Python classes should use the above class naming convention.

Qt/Python Hybrid

All hybrid classes (MediaManagerItem, for example) should use Qt's naming convention, except without the leading Q. All methods within these hybrid classes should also follow Qt's naming convention (def getIcon(), for instance).

Exception Names

Because exceptions should be classes, the class naming convention applies here. However, you should use the suffix "Error" on your exception names (if the exception actually is an error).

Functions & Methods

What's the difference?

In short, when "function" is used, it refers to functions outside of classes, and when "method" is used, it refers to function inside of classes.

Naming Conventions

Function and method names should be lowercase, with words separated by underscores as necessary to improve readability. However, Qt-derived classes use camelCase for their method names, without exception. Use one leading underscore only for non-public methods.

Arguments

If a function or method argument's name clashes with a reserved keyword, it is generally better to append a single trailing underscore rather than use an abbreviation or spelling corruption. Thus "print_" is better than "prnt". (Perhaps better is to avoid such clashes by using a synonym.)

Method-specific Arguments

Always use 'self' for the first argument to instance methods and 'cls' for the first argument to class methods.

Instance Variables

Use the function (not method) naming rules: lowercase with words separated by underscores as necessary to improve readability.

Constants

Constants are usually declared on a module level and written in all capital letters with underscores separating words. Examples include MAX_OVERFLOW and TOTAL.

Global Variable Names

The conventions are about the same as those for functions.

Modules that are designed for use via "from M import *" should use the __all__ mechanism to prevent exporting globals, or use the older convention of prefixing such globals with an underscore (which you might want to do to indicate these globals are "module non-public").

Designing for inheritance

Always decide whether a class's methods and instance variables (collectively: "attributes") should be public or non-public. If in doubt, choose non-public; it's easier to make it public later than to make a public attribute non-public.

Public attributes are those that you expect unrelated clients of your class to use, with your commitment to avoid backward incompatible changes. Non-public attributes are those that are not intended to be used by third parties; you make no guarantees that non-public attributes won't change or even be removed.

We don't use the term "private" here, since no attribute is really private in Python (without a generally unnecessary amount of work).

Another category of attributes are those that are part of the "subclass API" (often called "protected" in other languages). Some classes are designed to be inherited from, either to extend or modify aspects of the class's behavior. When designing such a class, take care to make explicit decisions about which attributes are public, which are part of the subclass API, and which are truly only to be used by your base class.

With this in mind, here are the Pythonic guidelines:

Retrieved from "http://wiki.openlp.org/Development:Coding_Standards"
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox