#pep8

it's always:

"why did you name it like that" "this isn't PEP8 code" "your comments aren't helpful"

never:

"wow you're so creative" "thank you for expanding my mind" "you code really well"

Quiz Time!

Do you know what PEP 8 is in Python?

👉 Choose the right answer from the options below!

1️⃣ Version of Python 2️⃣ Third-party library 3️⃣ Testing framework 4️⃣ Python code style guide 

PEP 8 helps Python developers write clean and readable code. It’s a must-know for every Python programmer!

#python

Python PEP8

Python Enhancement Proposal 8, or PEP 8, is a style guide for Python code. In 2001, Guido van Rossum, Barry Warsaw, and Nick Coghlan created PEP 8 to help Python programmers write consistent and readable code. The style guide may not always apply to your work, but it’s an important and useful tool that will elevate your code-writing process.  

Functions of PEP8 in Python

In general, Pep8 is a tool where you can check your Python code conventions with the conventions in the documentation of Pep8. Let us see a few features of Pep8 documentation:

Indentation

This is one of the most important features for writing the codes and for reading the codes in Python. It is also known as the 4 space rule, and this rule is not as mandatory as it can be overruled for the continuation of the line. Indentation also helps to know which code belongs to which function as we use braces in other programming languages in Python; this is done by following the rules of indentation.In Pep8, the rules are use spaces in place of tabs, as the name of the rule use 4 consecutive spaces for indentation. If both these rules are used at once then this causes an error that issues a warning by the interpreter.ExampleCode:n = 10if n> 5:print “n is greater”

Naming Conventions

Programming Recommendations

There are many implementations of Python code should work across all of them. Code should not be written in a way that disadvantages other implementations.

Compariasons to singletons like None should be done with `is` or `is not`, never the equality operator(Okay I'm doing this wrong). Remember the difference between `if x` and `if x is not None`. Use `is not` not `not ... is`. These all are geared to readability.

If you implement comparisons implement all 6 operations: __eq__ , __ne__ , __lt__ , __le__ , __gt__ , __ge__. functools.total_ordering decorator provides a tool to generate missing comparisons. Python may use reflexivity rules and swap operators and argument orders.

Use a def statement not an assignment to generate a lambda `def f(x): return 2*x`. This means the function object is f, which is useful for tracebacks.

Derive exceptions from Exception not BaseException. Direct inheritance from BaseException isreserved for Exceptions which are not expected to be caught. Design exceptions to answer "What went wrong?" not based on the locations exceptions are raised. Exceptions used for non-local flow control do not need the sufix Error. Catch specific exceptions. Only silence a specific error, do not catch all errors. `except:` will catch BaseException classes which include control-c. If you must catch all use `except Exception:`. Use explicit binding when you name exceptions in the except statement(`as`). Limit code in the try close to the minimal amount necessary.

Use with when a resource (connection, file) is only necessary locally to ensure clean up.

Return statements should be consistent. This is a huge pet peeve of mine. Either everything returns an expression or nothing does. If an expression is returned then other should `return None` and there should be an explicit return at the end of the function. Also, while not mentioned. Don't return multiple types. If you return strings return strings. Don't return a string or an int or a boolean.

Use string methods instead of the string module. Use startswith and endswith instead of slice. Object type comparisons should use isinstance instead of comparing types directly.

Use the fact that empty sequences are false. Do not use string literals that depend on trailing whitespace. Don't compare boolean values to True or False.

Function Annotations

Naming Conventions

So naming in Python is kind of a mess. Unittest uses camel case. Other libraries use snake case. Although there are standards for new libraries moving forward. But if you find yourself editing unittest, be consistent.

Overriding Principle Descriptive: Naming Styles Prescriptive: Naming Conventions Public and internal interfaces

Overriding Principle

Publicly visible names should reflect usage not implmentation. This is something to think about with names and comments. What code in your library does is less important than how it's meant to be used, so focus on what's important.

Descriptive: Naming Styles

This section includes a list of all possible variable combinations. You can read it in the pep8.

There are some interesting rules around underscores. A leading underscore designates a protected method and won't be imported by import *. A trailing underscore is used to distinguish from words with meaning in Python like type_. A double leading underscore invokes name mangling. Then we have the magic methods which start and end with a double underscore. These should never be invented, use the ones that curerntly exist.

Prescriptive: Naming Conventions

Names to Avoid Package and Module Names Class Names Type variable names Exception Names Global Variable Names Function Names Function and method arguments Method Names and Instance Variables Constants Designing for inheritance

Names to Avoid

We should avoid letters that may be confusing in context. Capital O. Lowercase L. Uppercase I. Especially as single characters.

Package and Module Names

Modules should have short, snakecase names. In package names pep discourages the use of underscores, but the names should be all lowercase. I question this for longer package names and tend to still use underscores for readability. An accompanying C module should have a leading underscore.

Class Names

Class names should be in camelcase.

Type variable names

Type variables are also in camelcase. They use the suffix _co or _contra to indicate covariance.

Exception Names

Exceptions should follow the class naming convention with the suffix "Error".

Global Variable Names

Global variables should be at most module level. And modules with globals should either use __all__ to avoid exporting globals, or they should prefix globals with _ to avoid them being imported with import *.

Function Names

Unless there is a consitency consideration. Functions should be snakecase.

Function and Method Arguments

The default argument to a function should always be either self or cls depending on the function type. If an argument clashes with a keyword append a trailing underscore rather than abbreviations. A synonym maybe better.

Method Names and Instance Variables

This section is mostly just repeating things stated above. You can skip it.

Constants

Define on a module level(as stated in the globals above). They are all caps with underscores for readability.

Desigining for Inheritance

If you don't know if something should be public or non-public make it non-public. The main difference is that public attributes are expected to maintain backwards compatibility. There is no guarantee that non-public methods won't change.

For simple public data attributes it is best to expose just the attribute name. Keep functional behavior side-effect free(excluding caching). Do not do expensive operations in properties. The caller expects properties to be cheap.

If you intend for you class to be subclassed and you have attributes you do not want overridden consider appending a double underscore.

Public and internal interfaces

Comments Block Comments Inline Comments Documentation Strings

The most important thing to remember about comments is that they aren't for you. Well they are not for you today. Today you know the code. They are for someone else or for you in 6 months. Because of this there are some requirements. They need to be clear, readable, useful and decipherable. I've been coding a long time and there are some comments that are not helpful: "doesn't work", "also called in some_file.py", "from some_file.py", "TODO...". So if something doesn't work why is it in the code? This is similar to TODO. No one is planning their sprints based on comments in the code so don't leave a TODO there either fix it or make a real ticket. The also called comment people will debate the usefulness of. the main problem with this comment is that it is almost never going to be up to date is that the only place it's called? Is it still called there? I have to do just as much to fact check this comment as I would have to do if it's not there, so don't leave it. Don't tell me where I imported something from. That's already in the code. You are muddling the code with information that I can already get from the imports list. There are more useless comments but these are the ones I particularly dislike.

The worst comments? Comments that are out of date. When you edit code edit comments. It's difficult to determine what is going on if a comment doesn't match the code. Is the code broken, was it purposfully changed? Does it need to be changed to match the comment?

Comments should be full sentences.

Block Comments

Block comments should apply to the code that follows them. They start with a # and in between paragraphs there should be a blank line that starts with a #. They should be indented to the same level as the code.

Inline Comments

I would like to vote that you don't use inline comments. I find them difficult to read and more annoying than useful. Pep will let you use them sparingly if code needs context. But you could also put it on the line above the code. Do that, make me happy.

Documentation Stings