Programming Style Guide

Documentation > Contributor Guides

Code committed into the MyPaint project repos follows consistent style rules to improve readability for other contributors. In general, please follow the coding conventions of the files you are editing. New Python code should follow this style guide

Summary Of Rules

Document your code
All contributed program code should be wrapped at 78 columns regardless of language.
Python docstrings should be wrapped at 72 columns.
Use four spaces per indent level for Python, C, C++, and shell
Use two spaces per level for XML code.
Don’t use visual indendation
Use str.format
Write localisable python

Python Rules

PEP 8 applies, with a few exceptions, documented in setup.cfg. Please use flake8 to check over your changes before sending a PR.
Please try to follow the Google Python Style Guide. It’s well thought out and thorough, while not being onerous.

Make your code pretty and readable! Brandon Rhodes’s A Python Æsthetic is a great place to start.

Don’t commit dead code

Guides

Constantine Lignos’s Anti-Patterns in Python Programming covers some common coding pitfalls.

Specific Rules

Visual Indentation

Visual indentation makes it hard to maintain things, and also ends up making things really cramped.

# (don't do this)
x = run_function_with_really_long_name(argument1,

For functions that take a lot of arguments, prefer:

# (this is better)
x = wow_this_sure_is_a_pretty_complicated_function(
    arg1, arg2,
    really_long_argument,
    named_arg = "something",
)

This is also recommended for long array/tuple/etc literals:

x = [
    "something",
    "another thing",
    "etc",
]

Strings

We now prefer str.format (and unicode.format) over C-style "%s" interpolation. It’s much easier to read, and far friendlier to our translators.

The exception to this rule is for hard-coded status messages sent to the program’s log output(s). The standard logging module requires C-style formatting, so please use %r there for interpolated objects.