With countless Python best practices circulating online, opinions on each can vary depending on who you ask. The internet has democratized expertise, allowing anyone — including myself — to share their views. However, in this article, we’ll focus on 10 timeless Python best practices that have achieved widespread consensus and are widely regarded as fundamental.

Pandas Cheatsheet

Git Commands cheatsheet

Top 50 SQL Interview Questions

Tip 1: Functions Should Specify The Parameter And Return Type
When defining a function, you want to always specify what the arguments’ types are and also what data type the result of the function returns. This would help both you and the devs in your team know what to expect without always having to use print statements to get a visual understanding.

Tip 2: Functions Should Be At The Same Level Of Abstraction
When we talk about functions being at the same level of abstraction, we’re referring to the idea that a function should perform a single, well-defined task. That task should be at a consistent level of abstraction throughout the function. In other words, the function should focus on a specific level of detail or complexity, and all the functions’ operations should operate at that same level.

Tip 3: Functions Should Be Small
A function is meant to be reusable. And the bigger the function gets, the less likely it is to be reusable. This also correlates to why a function should do only one thing. If it does only one thing, there’s a high chance it’s going to be small.

Tip 4: Open Closed Principles
The open-closed principle (OCP) states that a class, method, or function must be open for extension but not modification. This means that any class, method, or function defined can be easily reused or extended for multiple instances without changing its code.
This fails to adhere to OCP because whenever there’s a new country, we would need to write a new if statement to complement that. This might seem simple now but imagine we have 100 or more countries to take into account. How would that look?

Tip 5: Avoid Comments At All Cost
Comments have a way of being falsely true. They deviate the mind of the reader from what the code is actually doing to what someone else says it’s doing.

This can become very problematic as time passes and the code receives updates or changes. At some point, the comment becomes a lie and everyone now has to observe the truth through the lens of the lie.

Comments must be avoided at all costs. A comment forces the reader to inherit your thinking which at best is in the past. When a function or class changes, most likely, its comments do not change along with it. Most likely, they block the reader from thinking forward.

A comment signifies that the writer was mentally incapable of providing a well-descriptive class, function, or variable name. It exposes the lackluster attitude of the programmer and forces the team to inherit such an attitude.

Tip 6: Avoid Magic Numbers
A Magic Number is a hard-coded value that may change at a later stage, but that can be therefore hard to update.

For example, let’s say you have a Page that displays the last 50 Orders in a “Your Orders” Overview Page. 50 is the Magic Number here because it’s not set through standard or convention, it’s a number that you made up for reasons outlined in the spec.

Now, what you do is you have the 50 in different places — your SQL script (SELECT TOP 50 * FROM orders), your Website (Your Last 50 Orders), your order login (for (i = 0; i

Tip 7: Avoid Deep Nesting
Limit the levels of nesting within loops, conditionals, or functions to improve readability.

Tip 8: Avoid Hardcoding Paths
Refrain from hardcoding file paths or URLs; use configuration files or environment variables instead.

Tip 9: Classes should be small
Yep! Classes should be as small as possible. Just like functions.

The only difference is that in functions, size is determined by the number of lines in that function while in classes, it is determined by the number of responsibilities in that class.

Usually, a class name represents the kind of responsibilities it might possess but when the name is ambiguous or too general, most likely we are giving it too much responsibility.

This takes us back to SRP (single responsibility principle) which states that a class should only have one reason — one responsibility — to change.

Tip 10: Avoid Complex Ternary Expressions
Refrain from using overly complex ternary expressions; favor readability over brevity to make code more understandable.