[[PageOutline(2-4,,inline)]]

= Coding Styles =

== Common ==
 * Line length: Maximum of `119` rather than usual `79`. That said, where possible keep it between `79-99` to keep it readable.
 * Indent: `4 spaces`, no tabs.
 * All code should use `'single quotes'`.

== Python ==
 Deluge follows [http://www.python.org/dev/peps/pep-0008/ PEP8] and [http://docs.python-guide.org/en/latest/writing/style/ Python Code Style] with line length the only exception.

 * Code '''must''' pass [https://pypi.python.org/pypi/flake8 flake8] (w/[https://pypi.python.org/pypi/flake8-quotes flake8-quotes]), [https://pypi.python.org/pypi/isort isort] and [http://www.pylint.org/ Pylint] source code checkers.
{{{
flake8 deluge
isort -rc -df deluge
pylint deluge 
pylint deluge/plugins/*/deluge/
}}}

 * Using the [http://pre-commit.com/ pre-common] app can aid in picking up issues before creating git commits.

 * All byte strings (`str`) should be decoded to strings (unicode strings, `unicode`) on input and encoded back to byte strings on output. [http://stackoverflow.com/a/606199/175584 From Stackoverflow:]
{{{
>>> b"abcde"
b'abcde'
>>> b"abcde".decode("utf-8")
'abcde'
}}}
  ''Notes:''
   * ''PyGTK/GTK+ will accept `str` (utf8 encoded) or `unicode` but will only return `str`. See [http://python-gtk-3-tutorial.readthedocs.org/en/latest/unicode.html GTK+ Unicode] docs. ''[[br]]
   * ''There is also a `bytearray` type which enables in-place modification of a string. See [http://stackoverflow.com/a/9099337/175584 Python Bytearrays] ''[[br]]
   * ''For reference Python 3 renames `unicode` to `str` type and byte strings become `bytes` type. ''[[br]]

 * All relative path separators used within code should be converted to posix format `/`, so should not contain `\` or `\\`. This is to prevent confusion when dealing with cross-platform clients and servers.

=== Docstrings ===

You will find a mix of the older [http://docutils.sourceforge.net/docs/user/rst/quickref.html reStructuredText] and newer, easier to read, [http://sphinxcontrib-napoleon.readthedocs.org/en/latest/ Sphinx Napoleon] format.

Going forward the Napoleon [http://sphinxcontrib-napoleon.readthedocs.org/en/latest/example_google.html Google Style] will be used for all new doctrings and eventually convert over the rest.

Google Style short example:
{{{
def func(arg):
   """Function purpose.

   Args:
       arg (type): Description.

   Returns:
      type: Description. If the line is too, long indent next
         line with three spaces.

   """
}}}

Most common sections are `Args` and `Returns`. See complete list of [https://sphinxcontrib-napoleon.readthedocs.io/en/latest/#docstring-sections supported headers].

Verify that the documentation parses correctly with:
{{{
python setup.py build_docs
}}}

=== Python References ===

Useful links to style guides from other projects:

 * [http://docs.ckan.org/en/latest/contributing/python.html CKAN Python coding standards]
 * [http://google-styleguide.googlecode.com/svn/trunk/pyguide.html Google Python Style Guide]
 * [https://gist.github.com/sloria/7001839 Best of the Best Practices Guide for Python]

== Javascript ==

Using [https://github.com/jedmao/codepainter codepainter] with `hautelook` style will ensure a consistent coding style. 
{{{
codepaint xform -p hautelook "file.js"
}}}

 * Classes should follow the Ext coding style.
 * Class names should be in !CamelCase
 * Instances of classes should use camelCase.