| ... | ... | @@ -13,14 +13,15 @@ Trust me, coding conventions are not just rules, they're your passport to becomi |
|
|
|
So I guess it's okay if we have a few guidelines. The [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html) is a very good reference, and here's the gist of it:
|
|
|
|
|
|
|
|
### Code layout
|
|
|
|
- Limit line length to 80 characters.
|
|
|
|
- Limit line length to 80 characters, when possible.
|
|
|
|
- Use spaces around operators and after commas.
|
|
|
|
- Add a space before and after inline comments.
|
|
|
|
- Add a space before inline comments.
|
|
|
|
- Use `is` and `is not` for identity comparison, not `==` and `!=`.
|
|
|
|
|
|
|
|
### Naming conventions
|
|
|
|
- Use descriptive names for variables, functions, and modules.
|
|
|
|
- Use lowercase letters with underscores for module names.
|
|
|
|
- Use CapWords (capitalized words with no underscores) for class names.
|
|
|
|
- Use `lowercase` letters with underscores for module names.
|
|
|
|
- Use `CapWords` (capitalized words with no underscores) for class names.
|
|
|
|
- Use lowercase letters with underscores for function and variable names.
|
|
|
|
- Avoid using single lowercase letters, except for simple counters or iterators.
|
|
|
|
|
| ... | ... | @@ -28,7 +29,3 @@ So I guess it's okay if we have a few guidelines. The [Google Python Style Guide |
|
|
|
- Use comments to explain complex code.
|
|
|
|
- Use docstrings to document modules, classes, and functions.
|
|
|
|
- Follow the "Google Style" for docstrings (reStructuredText format). |
|
|
|
|
|
|
|
### Statements
|
|
|
|
- Use a space after a comma and around operators.
|
|
|
|
- Use is and is not for identity comparison, not == and !=. |
