mirror of
https://github.com/codex-storage/deluge.git
synced 2025-01-09 11:12:06 +00:00
83 lines
3.4 KiB
Plaintext
83 lines
3.4 KiB
Plaintext
[[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.
|