“Code is read more often than it is written” – Guido van Rossum

While my first Code review, my senior told me to enable PEP-8 and set it as error and resolve PEP-8 error in code. And then first thing I thought was… “What is PEP-8?”

PEP are the documents that establish standard within the Python community. Most PEP describe new features in Python or Python standard library but few of them are more nebulous PEP-8 is one of those. It is a Pythonic way to write code.

PEP-8 tells us what the python community considers to be well written readable code. This style guide evolves over time as language evolves. Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guidelines take precedence for that project.

The PEP-8 is the Style Guide for Python Code, and it covers:

• formatting
• comments
• naming conventions

Here are some rules we should follow while writing a Python code:

• Formatting
  1. Indentation:
     • While programming in Python, indentation is something that you will definitely use. However, you should be careful with it, as it can lead to syntax errors. The recommendation is therefore to use 4 spaces for indentation.
     • While working on any python code you must know what existing developers are using for indentation to avoid syntax errors.
     • Note that Python 3 doesn’t allow mixing tabs and spaces for indentation. That’s why, you should choose one of the two and stick with it!
  2. Maximum Line Length: Generally, it’s good to aim for a line length of 79 characters in your Python code. Following this target number has many advantages, such as:
     • It is possible to open files side by side to compare.
     • You can view the whole expression without scrolling horizontally which adds to better readability and understanding of the code.
  3. Blank Lines:
     • Surround top-level function and class definitions with two blank lines.
     • Method definitions inside a class are surrounded by a single blank line.
     • Extra blank lines may be used (sparingly) to separate groups of related functions. Blank lines may be omitted between bunches of related one-liners (e.g. a set of dummy implementations).
  4. Imports:
  1. • Adding library or package, We should follow below order:
       1. Standard library imports.
       2. Related third-party imports.
       3. Local application/library specific imports.
     • We should not import multiple packages or library in single line
       1. Avoid wildcard import
          • Example: from os import *
• Comments
  • Comments are used for in-code documentation in Python. They add to the understanding of the code. Comments should be more verbose so that someone reads the code, the person would get the proper understanding of the code.
  • Some IDE provides plugins which will show commented document on UI. For example: spyder.
  • You use block comments to explain code that is more complex or unfamiliar to others.
  • Take a look at scikit-learn to understand what these comments look alike.
• Naming Conventions
  1. If you’re not sure what naming styles are out there, consider the following ones:
     • b or a single lowercase letter;
     • B or a single uppercase letter;
     • lowercase
     • UPPERCASE
     • lower_case_with_underscores
     • UPPER_CASE_WITH_UNDERSCORES
     • CapitalizedWords, which is also known as CapWords, CamelCase or StudlyCaps.
     • mixedCase
     • Capitalized_Words_With_Underscores
     • _single_leading_underscore: weak “internal use” so we cannot access those functions when access through wildcard import.
       1. Example: from A import *, we cannot access _single_leading_underscore defined inside A.
     • single_trailing_underscore_: used by convention to avoid conflicts with Python keyword, for example, Tkinter.Toplevel(master, class_=’ClassName’)
     • __double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo).
     • __double_leading_and_trailing_underscore__: “magic” objects or attributes that live in user-controlled namespaces. For example, __init__, __import__ or __file__. You should never invent such names, but only use them as documented.
  2. Generally, it’s good to use short names if possible. In some cases, you can use underscores to improve readability.
  3. The following table shows you some general guidelines on how to name your identifiers:

How to check code is PEP-8 Compliant?
After learning more about PEP-8, you’re probably wondering how you can check whether or not your code actually complies with these PEP-8

1. Many Python IDE comes with plugins, which will show us PEP-8 warnings
2. Python pep8 Package
   • pip install pep8
   • pep8 –show-source –show-pep8

PEP-8 is the most popular code style guide for Python. It’s widely known and used by the Python community. If you’re looking for formatting advice on your Python code, look no further. It’s a good time investment to spend a few hours reading through PEP-8 and learning how to apply its recommendation to your own projects.

Conclusion:

While using Python, you sometimes do not care about the code quality due to anxiety of releasing features faster. However, the practices that were described in this blog – and many more that weren’t covered here – should be part of your dev-staging-test-deploy cycle. This benefits everyone working on the project to understand code. If you are working on an open-source project, your contributors would find PEP-8 a bliss and would understand your code better as this is the universal standard, each Python developer follows this.

Reference:

• https://www.python.org/dev/peps/pep-0008/
• http://pep8.org/
• https://www.datacamp.com/community/tutorials/pep8-tutorial-python-code

The post PEP-8 : Python Enhancement Proposals-8 appeared first on DevOpsTech Solutions.