Version 19 (modified by bro, 9 years ago) (diff) |
---|
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:
- CKAN Python coding standards
- Google Python Style Guide
- Best of the Best Practices Guide for Python
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