Version 20 (modified by Cas, 5 years ago) (diff)

--

  1. Common
  2. Python
    1. Docstrings
    2. Single or Double Quotes
    3. Python References
  3. Javascript
    1. Single or Double Quotes
  4. Git Commit Messages
    1. Tags / Labels

Coding Styles

Common

  • Line length: Maximum of 119 rather than usual 79. That said, where possible keep to 79.
  • Indent: 4 spaces, no tabs.

Python

Mostly follow PEP8 and Python Code Style with the following exceptions:

  • Line length (see above)
  • All byte arrays (byte strings, str) should be decoded to strings (unicode strings, unicode) on input and encoded back to byte arrays on output. From Stackoverflow:
    >>> b"abcde"
    b'abcde'
    >>> b"abcde".decode("utf-8")
    'abcde'
    

Note: PyGTK/GTK+ will accept str (utf8 encoded) or unicode but will only return str. See GTK+ Unicode docs.

  • 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 reStructuredText and newer, easier to read, Sphinx Napoleon format.

Going forward the Napoleon Google Style will be used for all new doctrings and eventually convert over the rest.

Single or Double Quotes

The python code base should be "double quotes".

Python References

Useful links to style guides from other projects:

Javascript

Using 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.

Single or Double Quotes

For the javascript code use 'single quotes'.

Git Commit Messages

Mainly based on git commit guidelines.

Example commit message:

Short summary of changes (preferably 50 characters or less)

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so. The first line can be considered as the subject of an
email and the rest of the text as the body. The blank line separating
the summary from the body is critical, unless you omit the body entirely.

Further paragraphs come after blank lines.

  - Bullet points are okay, too

  - Typically a hyphen or asterisk is used for the bullet, preceded by a
    single space, with blank lines in between, but conventions vary here

A general guideline on writing a good commit message is to provide information that is not already provided from the commit diff, which in essence is "the why, not the how".

  • Explain why the change is necessary

After reading the commit message it should should be apparent why the changes were made.

  • Explain how the issue is adressed in broad terms

It is not necessary to explain how the changes are made in detail as that can be seen from the commit diff.

Tags / Labels

To differentiate commit changes at a glance, the subject of commits for specific components should be prefixed with relevant tags/labels, such as

Core, WebUI, GTKUI, Tests, win32, Packaging, Console, Blocklist etc.

[GTKUI] Make Add Dialog torrent name editable

If the commit fix/closes a ticket, include the number:

[#1001] Add support for magnet uris

A limited number of tags may be combined, such as

[#1002] [GTKUI] Fix the files tab context menu not being displayed

[#2250] [Core] [GTKUI] Added method remove_torrents to core