RidgeRun Developer Manual - Coding Styles - Python

RidgeRun Developer Manual
Coding Styles
C C++ Python Javascript
Development Tools
Editors
Emacs Vi Visual Studio Code Atom
Debugging Tools
GDB Valgrind
Methodologies
Git Hooks Gitflow Code Reviews Project Cycles Driver Release
Design Patterns
Hexagonal Architecture
Testing
Build Systems
Contact Us

Introduction to 'Python' Coding Styles

When writing Python code, RidgeRun tries to follow PEP8 - Style Guide for Python Code. Following we present some of the rules presented in this standard. For more information please visit PEP8.

Good practices

Here is some recommendations when writing new code. See programming recommendations for additional information.

Be consistent with your code

In general, if you are adding code to an existent code, be consistent with the coding standard already being used. If no standard is used then follow this guide.

Code Layout

Indentation

Use 4 spaces per indentation level. See indentation for more information.

Maximum line length

Limit all lines to a maximum of 79 characters. See maximum line length for more information.

Imports

• Imports should usually be on separate lines

# Correct:
import os
import sys

# Wrong:
import sys, os

• Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
• 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.

For more information see imports

Naming

Package and 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. See package and module names for more information.

Class names

Class names should normally use the CapWords convention. See class-names for more information.

Function and Variable Names

Functions and variable names should use snake_case.

Global variables

Global variables should follow the same convention as functions.

Function and Method Arguments

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

Method Names and Instance Variables

• Use the function naming rules: lowercase with words separated by underscores as necessary to improve readability.
• Use one leading underscore only for non-public methods and instance variables.

Constants

Constants are usually defined on a module level and written in all capital letters with underscores separating words.

Comments

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

Avoid using inline comments.

x = x + 1                 # Inline comment, don't do it

# Do this instead
x = x + 1

Documentation Strings

Conventions for writing good documentation strings (a.k.a. "docstrings") are immortalized in PEP 257.

• Write docstrings for all public modules, functions, classes, and methods. Docstrings are not necessary for non-public methods, but you should have a comment that describes what the method does.
• The """ that ends a multiline docstring should be on a line by itself:

"""Return a foobang

Optional plotz says to frobnicate the bizbaz first.
"""

• For one liner docstrings, please keep the closing """ on the same line:

"""Return an ex-parrot."""