Before making any contributions, be sure your code does not violate any of the following conventions:
Unwritten style rules
There are some rules that PyLint does not check for that should be obeyed
- Use only
'for strings except in DocStrings.
PyLint exclusions
When specifying PyLint exclusions, use the human readable string format for the rule rather than the number value.
A correct example:
# pylint: disable=too-few-public-methods
If you don't know the human readable value, you can run the following command in your virtual environment, which returns a list of error codes, their human readable formats, and their error messages.
pylint --list-msgs
Spell check
Run a form of spell checker over command names and comments. If using VS Code it is recommended, you install the Code Spell Checker extension.
History and version updates
When making any code change, be sure to update the release history accordingly
in the README file located at src\README.rst. Any new changes should be
added to a new version called unreleased.
At the time of releasing a new CLI version, the code owners change
the README.rst file to represent the released code version.
Code ownership
When adding new command groups and files, be sure to update the
CODEOWNERS file at the root of the repository. For more information, see the
GitHub documentation
on code owners.
Supporting Python 2.7 and 3.6
The Service Fabric CLI supports the latest versions of both Python 2 and 3. Be sure that your code runs in both 2.7 and 3.6. The test suites should be run in virtual environments for both supported versions.
Command naming
When creating new commands, follow these guidelines when picking a command syntax and name:
- Simpler is better
- Do not try to match PS names
- Try to match API names
- If complex actions are necessary, concatenate verbs with
- - Do not use extraneous verbs like
getandsetas actions - Match Unix and Linux conventions
- Development
- How-To
- Details
- Service Fabric Developers