-
Notifications
You must be signed in to change notification settings - Fork 1
Style Analysis: Python
This table contains the mapping of coding style elements vs. source code elements that this project currently examines for Python projects. Below the table are in-depth explanations about the methods of analysis and the official PEP 8 style guide recommendations for each element. Each section also lists PEP 8 error codes being checked by the Pycodestyle API for that particular analysis. Read more about those error codes and their corresponding error messages in the Pycodestyle documentation.
A general note: This analysis does not endeavor to cover every dark corner of Python style; rather, it focuses on main points. The documentation for each specific element will discuss exactly what is considered and what is not. Currently source code is compared to the PEP 8 style guide and Google Python style guide.
Click on any of the x's in the table to jump to the corresponding section, or simply scroll down.
| Classes | Constants | Variables | Methods & Functions | Control Statements | Import Statements | Files | |
|---|---|---|---|---|---|---|---|
| Naming | x | x | x | x | x | ||
| Indentation | x | x | x | ||||
| Tabs vs. spaces | x | x | x | x | x | ||
| Line length | x | x | x | x | x | x | |
| Blank lines | x | x | |||||
| Imports | x | ||||||
| File encoding | x |
Both the PEP 8 and Google style guides favor the CapWords naming convention for classes. Though both guides allow some leeway for special cases, this project strictly requires the CapWords style.
Implementation still pending.
Implementation still pending.
Both the PEP 8 and Google style guides favor the lower_snake_case naming convention for methods and functions. Though both guides allow some leeway for special cases, this project strictly requires the lower_snake_case style.
Implementation still pending.
The style checks for naming are custom-implemented, so there are no PEP 8 errors to report.
All lines (except comments) are expected to follow either hanging or visual indent rules. Google further specifies that lines should be indented with 4 spaces.
PEP 8 Errors: E111-E116, E121-E129, E131, E133
The Google style guide prohibits the use of tabs. PEP 8 is slightly more lenient - "Spaces are the preferred indentation method. Tabs should be used solely to remain consistent with code that is already indented with tabs." Because it is difficult to tell when tabs are included for backward compliance or for personal preference, this project considers the inclusion of any tabs non-compliant for both styles.
PEP 8 Errors: E101, E223, E224, E242, E273, E274, W191
For this analysis, all lines in a file (code and comments alike) must be 79 characters or fewer to comply with PEP 8. Although PEP 8 further specifies that docstrings or comments should be limited to 72 characters per line, this project allows them to be up to 79 characters.
Google allows lines of up to 80 characters, with exceptions allowed for longer lines containing lengthy import statements, constant names, or comments. However, because of limitations with the Pycodestyle API used to run the checks, this analysis is currently not being run. All lines are currently expected to be 79 characters or fewer.
PEP 8 Errors: E501
Both PEP 8 and Google agree on all of the following recommendations: Use two blank lines separating top-level functions and class definitions. Method definitions within a class should be separating by one blank line. Additional blank lines may be optionally and sparsely included for organizational purposes.
PEP 8 Errors: E301, E302, E303, E304, E305, E306
For the scope of this project, to be considered compliant with both PEP 8 and Google, imports must be on separate lines, and all imports must be at the top of the file. Import ordering, grouping, type (absolute vs. explicit relative), and wildcards are not considered in this analysis.
PEP 8 Errors: E401, E402
Implementation still pending.