27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer.

| by Alexander obidiegwu | Medium

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

50 Coding Laws That Would Make You A

Decent Programmer.
Follow these laws or get fired.

Alexander obidiegwu · Follow

23 min read · Mar 2, 2024

Listen Share

There are hundreds or probably thousands of Python best practices out there and
depending on who you ask, you would get some slight variation on a given practice.

The internet has given everyone the right to voice an opinion. Including even me.
But in this article, we will be dealing with 50 Python best practices that are set in
stone.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 1/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

These are practices that even God himself can’t tweak. These practices differentiate
the pro from the
You amateur andSign
are signed out. a lot of them
in with can also
your member be adapted for various
account
programming(mn__@p__.com)
languages. to view other member-only stories. Sign in

Most Python developers need somewhere to quickly test their code or debug errors. I
developed a website called python-fiddle.com which you can use to quickly test out a code
and it uses AI/LLMs to help find solutions to possible errors.

My Linkedln: https://www.linkedin.com/in/alexanderobidiegwu
LAW 1: 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.

Avoid comments at all costs.

In Law 14 and 15, you would learn when and when not to use a comment.

LAW 2: Do Not Use Type Attributes As A Name For Variables

Sometimes we want to specify that a particular variable is a string or an int. Some
developers would therefore name the variable like this: name_of_variable_str or
name_of_variable_int .

This can be quite redundant especially if the variable is intuitively a string. A name

variable, for instance, can never be an int type.

But when the variable type isn’t intuitive, rather than specifying the type when
naming the variable, the best way to do this is to use type annotations.
https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 2/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

name_of_variable:str = value instead of name_of_variable_str = value .

You are signed out. Sign in with your member account

This way, everyone can tell the
(mn__@p__.com) variable
to view is a stringstories.
other member-only whileSign
keeping
in the code neat &
concise.

LAW 3: Class Names Should Be Nouns.

It’s always best practice to keep your class names as nouns.

This is mostly because a class object is used to identify or represent a bunch of

characteristics and actions. Similar to how a goat represents some characteristics
like horns and actions like nod_nearby_humans .

It also makes the code very readable and less redundant. For example,
Goat.get_horn_length() instead of GetGoat.get_horn_length() .

LAW 4: Function Names Should Be Verbs

Functions are best named as verbs because they help the neighboring developer
clearly understand what actions they perform.

It also eradicates the need for comments and allows any developer to mentally
conceptualize without having to look at the raw code.

LAW 5: 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.

Bad Practice

Run code

Good Practice

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 3/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

Run code

LAW 6: A function Must Perform One Functionality Only

Junior devs are fond of breaking this rule. Having a function perform one function
is crucial because it helps expose where the bugs are located, enables reusability,
and does exactly what the function name says.

You don’t want to do something like this…

(Note that the methods and attributes are just for example purposes.)

Python fiddle

This checks if the address is valid and after checking returns the latitude and
longitude. The function does two things. Checks if the address is valid and returns
the geolocation of the address.

Here is a better way of doing this.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 4/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

https://python-fiddle.com/saved/bQD3sPFuC4BWeTx1gdLr

You are signed out. Sign in with your member account

The above functions do onlytoone
(mn__@p__.com) viewthing and nothing
other member-only more.
stories. SignAlthough
in it may seem
more verbose, it’s a lot more concise and readable.

Knowing exactly what is “one” functionality can be a bit difficult, especially for new
devs. You need to be very specific on what you want a function to do.

Usually, if you can extract or group some of the actions in a function as a whole
other function, then it’s probably doing more than one thing.

Another way you can tell is if it has more than one level of abstraction…

LAW 7: 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.

Good Practice

https://python-fiddle.com/saved/ezGiYtWK72HXiVm65azM?run=true

This function has statements that are of a low level of abstraction. Things like sum ,

len, etc.

Bad Practice

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 5/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

run code here

This function, for instance, has a bunch of levels of abstraction. get_numbers() is a

high level of abstraction, the list comprehension is an intermediate level of
abstraction, and sum is a low level of abstraction.

LAW 8: A Function and It’s Argument(s) Should Be Like Brothers And Sisters
A function name should be closely tied to its arguments. You don’t want to have a
function that seems to do one thing and the arguments passed do not correlate with
the function name.

Bad Practice

write(True)

Good Practice

write(name)

The second one is more descriptive of what exactly the function is doing. It is clear
to whoever reads this that we are writing a name.

The first one isn’t as explicit as the second. You have to make guesses and possibly
even have to view the entire function.

LAW 9: 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.
LAW 10: Avoid Noise/Redundant Words
There are times when devs use words that don’t provide any further clarification on
a variable or function’s meaning. Things like this:

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 6/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

https://python-fiddle.com/saved/BfPEC7YYSEHQhz2xgGTW

Without having prior knowledge of the function’s implementations, a developer

seeing this doesn’t know which function to use.

My Linkedln: https://www.linkedin.com/in/alexanderobidiegwu

LAW 11: Do Not Be A Dirty Programmer

Any senior dev would tell you he only feels clean when his codes are clean. This is
because a dirty code makes up a dirty programmer. A clean code encourages
everyone on the team to continue writing clean code. You must aim to always write
clean code.

But what is a clean code? A clean code is well structured and arranged.

A clean code doesn’t hide bugs. It exposes anywhere a bug could hide to the
programmer and makes room for an easy fix without complete refactoring.

LAW 12: 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.

Let’s take for instance, we have a class called address.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 7/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

https://python-fiddle.com/saved/6kfW6eccopYfotqaKlcR?run=true

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?

This is where OCP comes into play.

https://python-fiddle.com/saved/AEbfUZvVQ0k55RyHcypB

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 8/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

This is a more robust solution because now we don’t need to modify either the class
or its functions.
YouIfare
we everout.
signed wantSignto
in consider a country
with your member and its capital, we can simply
account
(mn__@p__.com) to view other member-only stories. Sign in
adjust our capital dictionary.

Another common example you would see is using class inheritance.

For example:

This is a wrong method because anytime we want to add a new payment method, we
would always need to modify the PaymentProcessor class.

A better way to do this is:

This way, whenever we need to add a new payment option, say crypto or paypal, we
wouldn’t need to edit or modify any class to achieve this. we could simply do this:
https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 9/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

LAW 13: Liskov Substitution Principle

If we look at the previous principle, when making payments using crypto, we don’t
exactly specify the cryptocurrency we are transferring. We only specify an amount.
So suppose we want to specify a cryptocurrency, we would usually do something
like this:

from abc import abstractmethod

class PaymentProcessor:

@abstractmethod
def pay_tax(amount, crypto):
pass

Then when calling each payment processor, we declare the crypto argument as a
None type or give it a default value to avoid passing in any argument if not needed.
Both cases fail to adhere to the Liskov Substitution Principle.

This is because the parent class or the abstract class, contains an argument that isn’t
relevant to most of our subclasses

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 10/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

The Liskov Substitution principle (LSP) states that “Objects of a superclass should be
replaceable with objects
You of its
are signed subclasses
out. Sign in withwithout affecting
your member the correctness of the program”.
account
(mn__@p__.com) to view other member-only stories. Sign in
To adhere to LSP, we would need to define the cryptocurrency within the
CryptoPaymentProcessor class to avoid any irrelevant clash with other subclasses.

class CryptoPaymentProcessor(PaymentProcessor):
def __init__(self, crypto):
self.crypto = crypto

def pay_tax(amount):
print(f'Your {self.crypto} wallet is being processed for tax payment')
print(f'You are to be charged {amount}')

LAW 14: Know When To Use A Comment

Every time you need to use a comment, be ashamed of your inability to express
yourself in code. But there are some situations whereby the use of comments can
actually help to express the underlying workings of a code than the code itself. Here
are 5 best examples of “good” comments.

Informative comments
Making comments informative can always help express the code to the reader. A
comment that highlights the return value of a function, for instance, would provide
more clarity. But comments like this can be made redundant through the use of
well-descriptive functions or variable names.

TODO comments
Comments like this help other programmers know that this is an unfinished
function/task or it requires modification. Maybe there’s a better way to implement a
certain function that wasn’t taken advantage of. Maybe the code fails periodically.

Regardless of your reason, comments like this provide more value than they take.
TODO comments are also less likely to be left untouched as the code changes or
improves because they are usually remembered to be removed once the task has
been completed or modified properly.

Warning of consequences
Sometimes, we want to tell other developers about potential landmines. Stepping on

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 11/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

these landmines could have some unforeseen consequences. And we want to all
survive through
Youthe day. Comments
are signed can
out. Sign in with save
your the day
member in this situation.
account
(mn__@p__.com) to view other member-only stories. Sign in
Suppose a certain code takes time or has the possibility of overloading certain
systems, a warning like #CONSUMES A LOT OF COMPUTING RESOURCES would be beneficial
to a reader or other programmers.

LAW 15: When Is A Comment Bad?

Noise comments
These are comments that reinstate the obvious. They provide no further
information and only increase the verbosity of the code. A lot of times, we skip
through comments like this when we see one. Examples of noise comments are:

# adds to animal list

animal.append(dog)

Non Local information

One mistake a lot of programmers make when using comments is giving
information about global information locally. When writing comments, ensure that
it remains relevant only to the function or statement it is referencing. Anything
outside of that should be pruned out.

Unobvious comments
We often write comments that seem obvious to us but not to someone else. The
connection between your comments and the function referenced must be clear.
They must both follow the same step or procedure at sync. You don’t want your
comment to need to have its comment as well.

Short Functions
Most likely we do not need a comment for a short function. The shorter/smaller the
function, the more likely it can be described with a good name. Hence, they are
usually self-descriptive.

LAW 16: Keep Source Files Short

A source file should be between 100–200 lines with 500 lines at most. Unless you
have very good reasons to choose otherwise. Keeping a source file short has various

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 12/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

obvious benefits such as reusability and readability. They are also easier to maintain
and update since wesigned
You are spend less
out. Signtime scrolling
in with andaccount
your member trying to connect the dots.
(mn__@p__.com) to view other member-only stories. Sign in
LAW 17: Know When To Use Blank Lines
Blank lines are a way to tell the reader we are progressing into a new and separate
concept. Each group of lines represents a complete thought. It helps readers
understand when a thought ends.
LAW 18: Keep Related Lines Of Code/Functions/Classes Close

Go where you are valued

Can you remember when you had to scroll all the way to the top of the script, just to
find out what a function does and how it relates to where it’s being called?

The worst part of this is you can’t understand the relation in one glance. It’s a back-
and-forth movement. Once you’ve experienced this, you’ll understand how valuable
it is to keep related code to each other.

A function/Variable should be as close to where it’s needed the most or has the most
importance. It should be furthest away from where it has the least importance.

LAW 19: Know When To Use White Spaces

We use white spaces to show that two things are not strongly related and no white
space to associate things that are strongly related. For instance when defining
functions…

def create(name):
print(name)

There exists no whitespace between the parenthesis between the function and the
name variable. If there was, it would look very disjointed and uncoordinated…

def create (name):

print (name)

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 13/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

Arguments passed into a function, should be separated to show that the arguments
are separate. You are signed out. Sign in with your member account
(mn__@p__.com) to view other member-only stories. Sign in
LAW 20: Obey Team Rules
Almost every developer has his/her style. From the way we name our files, to the
way we write print statements.

But when it comes to working with other devs, you want to dumb down those
personal preferences and adopt the team’s preferences. Not everyone might be able
to see beauty in your code the way you do.

LAW 21: 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
Open in app Sign up Sign in
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
Search
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 < 50; i++) ) and possibly many other places.

# Bad
SELECT TOP 50 * FROM orders

# Good
NUM_OF_ORDERS = 50
SELECT TOP NUM_OF_ORDERS * FROM orders

LAW 22: Avoid Deep Nesting

Limit the levels of nesting within loops, conditionals, or functions to improve
readability.

# Bad
if x:
if y:
do_something()

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 14/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

# Good
You are signed out. Sign in with your member account
if x and y:
(mn__@p__.com) to view other member-only stories. Sign in
do_something()

LAW 23: Avoid Temporary Variables

# Bad
temp_result = calculate(x, y)
final_result = temp_result * 2

# Good
final_result = calculate(x, y) * 2

LAW 24: Avoid Cryptic Abbreviations

Use descriptive names instead of cryptic abbreviations to enhance readability.

# Bad
def calc(x, y):
pass

# Good
def calculate_total_price(quantity, unit_price):
pass

LAW 25: Avoid Hardcoding Paths

Refrain from hardcoding file paths or URLs; use configuration files or environment
variables instead.

# Bad
file_path = "/path/to/file.txt"

# Good
import os
file_path = os.getenv("FILE_PATH")

LAW 26: Always use Try-Catch-Finally Statements

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 15/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

When writing code, it’s always best to include error handling also. This can help
speed up the debugging process
You are signed out. Signand increase
in with the account
your member sophistication of the code while
(mn__@p__.com) to view other member-only stories. Sign in
keeping it clean and manageable.

You want to use try-catch statements when a certain code is more likely to return an
error.

Things like API requests, file handling, etc tend to fail or raise errors due to one
reason or the other. Using try-catch statements for multiplication or division is just
uncalled for and creates more problems than it solves.

LAW 27: Provide Context with Exceptions

Whenever you catch an exception, it should provide enough context for anyone who
encounters it to know where the problem is from and debug accordingly.

Create informative error messages along with your exceptions which can be done
when printing the error. Mention the context in which the operation failed and the
type of failure.

Law 28: Avoid Using Multiple Exception Class

Have you ever seen a code like the one below…

try:
pass
except ValueError:
pass
except TypeError:
pass
except IndexError:
pass
except KeyError:
pass
except FileNotFoundError:
pass

This is extremely bogus and takes away (in verbosity, complexity, and maintenance)
the additional help it provides in error handling.

It’s often better to use a more general exception to catch any sort of error we might
come across. This type of exception, by default, includes the type of error we got.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 16/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

try: You are signed out. Sign in with your member account
pass (mn__@p__.com) to view other member-only stories. Sign in
except Exception:
pass

Only be specific about the type of error you want to catch, when you want all other
errors to pass through.

LAW 29: A function must either mutate or return something, but not both.
Whenever we are creating a function, we should keep in mind what exactly that
function is supposed to do. Does it mutate the arguments passed? Or does it need to
return something?

If the function mutates the argument(s) passed, we only need to do that in that
function and nothing else.

But what do I mean by mutation? If the function changes the contents of the
argument(s) or changes the data type of the arguments, it mutates.

def changed(array):
array.append('hello')

If the argument(s) is used to create another variable, then it doesn’t mutate. For
instance, if an argument called time was used to calculate a distance , then it
doesn’t mutate, which means distance can be returned in that function.

def calculate_distance(time, speed):

distance = speed * time
return distance

But there’s a way to get the best of both worlds. You can copy the argument(s) of the
function and perform mutation on those. This way we avoid any side effects.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 17/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

def changed(array):
You are signed out. Sign in with your member account
array_copy = array[:]
(mn__@p__.com) to view other member-only stories. Sign in
array_copy.append(4)
return array_copy

LAW 30: Not all function names should be verbs

Yes, I know. I previously said all function names should be verbs, which is true
generally, but there are times when a function name should take the form of a noun.
And knowing when it should take either is based on the previous law/ law 29.

If a function returns something without mutating its arguments, the function’s name
should be a noun. If a function mutates the arguments and returns none, it should
be a verb.

This is a common convention built into Python itself. Methods such as sort, and
append are verbs because they mutate the data type and return None while methods
like sorted, sum, product are all nouns because they don’t mutate any arguments
passed and return a new copy of the data.

There are obviously exceptions to this and whenever you feel you’ve encountered
one, feel free to fall back on using verbs.
LAW 31: 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.

LAW 32: Classes should have a small number of instance variables

Instance variables, in case you don’t know, are variables that are defined when the
class is defined or instantiated.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 18/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

class Animal:
You are signed out. Sign in with your member account
def __init__(self,
(mn__@p__.com) name):
to view other member-only stories. Sign in
self.name = name #instance variable

If all our functions are related to the class responsibility, there’s no reason why we
should have a lot of instance variables.

When we begin to have tons of instance variables, is when certain functions in the
classes deviate away from the core responsibility of the class.

These functions tend to come with their own variables that other functions in the
class do not need.

LAW 33: Your classes should be cohesive.

All the functions in your class should contain one or more of the instance variables.
The more your functions relate to or contain the instance variables in your class, the
more cohesive your class is.

LAW 34: Use the with Statement for Resource Management

Use the with statement to automatically manage resources like files or database
connections, ensuring they are properly closed or released.

# Bad
file = open("example.txt", "r")
data = file.read()
file.close()

# Good
with open("example.txt", "r") as file:
data = file.read()

LAW 35: Avoid Complex Ternary Expressions

Refrain from using overly complex ternary expressions; favor readability over
brevity to make code more understandable.

# Bad
result = "even" if number % 2 == 0 else "odd" if number % 3 == 0 else "neither"

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 19/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

# Good
if number % 2 == 0:
resultYou
= are signed out. Sign in with your member account
"even"
(mn__@p__.com)
elif number % 3 == 0: to view other member-only stories. Sign in
result = "odd"
else:
result = "neither"

LAW 36: Use ‘is’ and ‘is not’ for Identity Comparison
Most of the time, we use == to check the comparison between two variables. This is
usually okay for immutable data types like strings or integers because immutable
objects with the same value are usually stored in the same memory location, so a
memory location check is not needed.

But when dealing with mutable data types, such as list, dicts and custom objects,
it’s often better to use the is comparator because it checks the subtype of the
variable and the memory location.

The memory location of mutable objects are usually not the same due to the way
Python works. Python stores mutable objects in different memory locations because
they can be changed at any time and each of them must be independent of one
another even though.

Strings, tuples, and integers cannot be changed once created.

Run this using the link below:

https://python-fiddle.com/saved/nV6iEIyBuHm2mevD9Bhg

# Example 2: Checking if two lists refer to the same object

list1 = [1, 2, 3]
list2 = [1, 2, 3]

# Less preferred: Using ==

if list1 == list2:
print("Lists are equal in value")

# Preferred: Using is
if list1 is list2:
print("Lists are the same object")

# Note: In this case, list1 and list2 are different objects with the same value
# so using `is` would give a different result than `==`.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 20/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

LAW 37: Dependency Inversion Principle

The Dependency Inversion
You are Principle
signed out. Sign in with(DIP) is a fundamental
your member account principle of object-
(mn__@p__.com)
oriented design that promotesto view other
loose member-only
coupling stories.components
between Sign in and facilitates
easier maintenance and extension of software systems.

It states that high-level modules should not depend on low-level modules, but both
should depend on abstractions.

In other words, classes should depend on interfaces or abstract classes rather than
on concrete implementations.

# Bad
class Logger:
def log(self, message):
with open('log.txt', 'a') as f:
f.write(message + '\n')

class Calculator:
def __init__(self):
self.logger = Logger()

def add(self, x, y):

result = x + y
self.logger.log(f"Added {x} and {y}, result = {result}")
return result

In the example above, we define the class Logger and directly create a new instance
of it in our Calcuator class. This means that Calculator now depends on Logger

class and if for any reason we change Logger class, we now also have to modify
Calculator class.

And as you can see this also fails to adhere to the open closed principle (open for
extension, closed for modification).

This tight coupling makes the code harder to test because we can no longer simply
use a fake logger class when testing.

# good
from abc import ABC, abstractmethod

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 21/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

class LoggerInterface(ABC):
@abstractmethod
You are signed
def log(self, out. Sign in with your member account
message):
(mn__@p__.com) to view other member-only stories. Sign in
pass

class Logger(LoggerInterface):
def log(self, message):
with open('log.txt', 'a') as f:
f.write(message + '\n')

class Calculator:
def __init__(self, logger: LoggerInterface):
self.logger = logger

def add(self, x, y):

result = x + y
self.logger.log(f"Added {x} and {y}, result = {result}")
return result

This promotes modularity because changes to one component do not necessarily

require changes to other components as long as the interface remains consistent.

This modularity enables easier understanding, modification, and extension of the

codebase.
LAW 38: Avoid Using ‘assert’ for Data Validation
Use assert statements for debugging and development purposes only; avoid using
them for data validation in production code.

# Bad
assert x > 0, "x should be positive"

# Good
if x <= 0:
raise ValueError("x should be positive")

LAW 39: Avoid Hard-Coded Numbers

Use named constants instead of hard-coded values. Write constants with meaningful
names that convey their purpose. This improves clarity and makes it easier to
modify the code.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 22/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

def calculate_discount(price):
You are signed out. Sign in with your member account
discount = price * 0.1
(mn__@p__.com) # other
to view 10% discount
member-only stories. Sign in
return price - discount

The example below uses the hard-coded number 0.1 to represent a 10% discount.

This makes it difficult to understand the meaning of the number (without a

comment) and adjust the discount rate if needed in other parts of the function.

def calculate_discount(price):
TEN_PERCENT_DISCOUNT = 0.1
discount = price * TEN_PERCENT_DISCOUNT
return price - discount

The improved code replaces the hard-coded number with a named constant
TEN_PERCENT_DISCOUNT . The name instantly conveys the meaning of the value, making
the code more self-documenting.
LAW 40: Follow the DRY (Don’t Repeat Yourself) Principle
Avoid writing the same code more than once. Instead, reuse your code using
functions, classes, modules, libraries, or other abstractions. This makes your code
more efficient, consistent, and maintainable.

It also reduces the risk of errors and bugs as you only need to modify your code in
one place if you need to change or update it.

# Bad

def calculate_book_price(quantity, price):

return quantity * price
def calculate_laptop_price(quantity, price):
return quantity * price

# Good

def calculate_product_price(product_quantity, product_price):

return product_quantity * product_price

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 23/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

LAW 41: Follow Established Code-Writing Standards

It’s important You
to follow commonly
are signed accepted
out. Sign in with conventions
your member account in terms of spacing,
(mn__@p__.com)
comments, and naming. Most to view other member-only
programming stories. Sign
languages havein community-accepted
coding standards and style guides, for example, PEP 8 for Python

Some common conventions are:

Use snake_case for variable, function, and class names.

Use spaces over tabs for indentation.

Use 4 spaces per indentation level

Limit all lines to a maximum of 79 characters.

Break a line before a binary operator

LAW 42: Law of Demeter

The law of Demeter, in simple terms, means that a module/function/class can have
knowledge or make reference to another module/function/class immediate
neighbors but should not have any knowledge further than that.

By immediate neighbors, this means methods or functions or variables that can be

directly accessed.

An example should clear this up…

class Order:
def __init__(self, customer):
self.customer = customer

def get_customer_name(self):
# Violation: Order knows too much about the customer's structure
return self.customer.get_profile().get_name()

In this example, the Order class directly accesses the customer’s profile to retrieve
the customer’s name. This violates the Law of Demeter because Order is reaching
into the internal structure of the Customer object to access its profile and name.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 24/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

It has gone past an immediate neighbor and now knows too much about the
customer’s object.
You are signed out. Sign in with your member account
(mn__@p__.com) to view other member-only stories. Sign in

class Order:
def __init__(self, customer):
self.customer = customer

def get_customer_name(self):
# Adherence: Order only interacts with its immediate collaborator
return self.customer.get_name()

In this adherent example, the Order class only interacts with its immediate
collaborator, the Customer object, and calls a method directly on it to retrieve the
customer’s name.

It does not reach into the internal structure of the Customer object, thus following
the Law of Demeter.

LAW 43: Readability over conciseness

Code needs to work and be understood by the machine executing it. However, other
developers also need to be able to understand the code, especially if you are
working on a project with multiple people.

That is why the readability of code is always more important than its conciseness
when it comes to software development.

There is no point in writing concise code if other developers cannot understand it.

LAW 44: Keep Imports Clean

Import only the necessary modules and symbols to keep the import section clean
and improve readability. When we import everything (*) from a module, all
variables, functions, and classes are also imported which can make it very difficult
to know where a certain function/class originated from and can also be a pain when
using modern IDEs.

Imagine you want to write a function with the name get_file . You click g and your
IDE recommends you a list of functions/classes/variables that start with the letter g.

It can become quite chaotic.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 25/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

This becomes more of a pain when you want to call that function. Your function
name could beYou
lost
arein between
signed the
out. Sign recommendations
in with and now your IDE becomes
your member account
(mn__@p__.com)
more of a problem to view other
than an efficient member-only stories. Sign in
solution.

# Bad
from module import *

# Good
from module import symbol1, symbol2

LAW 45: Do Not Return Null/None

Usually, when we define functions, by default they return None if no return value is
specified. But when we explicitly return None , we are indirectly telling the reader
that the function can return something else except None .

And if this is not true, it can cause a lot of miscommunications.

LAW 46: Separate Construction From Its Use

Separation of concerns has been a very fundamental principle in software
engineering. We need to know how to separate the construction of our software
from how it’s being used.

This often means separating the startup process, — which is when our dependencies
and objects are wired together — , from the run time logic, — which is when the
logic of the application executes based on inputs from the user or other triggers — .

One common way to separate construction from its use is to construct the
application logic in a file/function/module called main .

The main function builds the objects necessary for the application to run smoothly.
This frees other modules from being tightly coupled to the application and
promotes reusability and modularity.
LAW 47: Simple Design Contains All These Rules
Runs all the tests: A system might have a perfect design on paper but if there’s no
way to verify that the system actually works as intended, then the design on paper
becomes questionable.

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 26/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

Contains no duplication: Duplication is the primary enemy of a well designed

system You are signed out. Sign in with your member account
(mn__@p__.com) to view other member-only stories. Sign in
Expresses the intent of the programmer

Minimizes the number of classes and methods

LAW 48: Avoid Nested Try-Except Blocks
Refrain from nesting try-except blocks excessively to prevent overly complex error
handling logic.

# Bad
try:
try:
# Code that might raise errors
pass
except ValueError:
# Handle ValueError
pass
except Exception as e:
# Handle any other unexpected errors
pass

# Good
try:
# Code that might raise errors
pass
except ValueError:
# Handle ValueError
pass
except Exception as e:
# Handle any other unexpected errors
pass

LAW 49: Use Concurrency Only When Needed

It’s very easy to write bad code when implementing concurrency functionality.

It’s also very easy to write clean code when implementing very faulty concurrency
functionality. Usually, you might not even be aware that it is faulty until a lot of
stress is put on the system.

You want to pick your battles very smartly.

There are multiple reasons why your concurrency code might fail. Here are some:
https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 27/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

Starvation: Starvation occurs when a thread or process is unable to gain access to a

shared resource
Youindefinitely, despite
are signed out. Sign attempting
in with your memberto do so. This can happen when
account
other threads (mn__@p__.com) to view other member-only
or processes continually acquire andstories.
holdSign
theinresource, preventing
the starving thread from making progress.

Deadlocks: Deadlocks occur when two or more threads or processes are blocked
indefinitely, waiting for each other to release resources that they need. This can
happen when each process holds one resource and waits for another resource held
by another process, creating a cyclic dependency.
LAW 50: Follow The 49 Rules
These laws are only there to guide you on your journey as a software engineer. You
should abide by them whenever needed.

But as you grow in experience and skills, you want to be able to decide when it’s best
to follow a certain rule and when it’s not.

This gut feeling/intuition only comes to those who have mastered their craft and if
you’re a newbie or you just started your career 2 years ago, it’s usually best you
follow these laws like it’s your only ticket to heaven.

Most Python developers need somewhere to quickly test their code or debug errors. I
developed a website called python-fiddle.com which you can use to quickly test out a code
and it uses AI/LLMs to help find solutions to possible errors.

Programming Python Software Engineering Clean Code Data Science

Follow

Written by Alexander obidiegwu

528 Followers

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 28/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

Explaining foundational concepts and principles of Python, SQL and Mathematics.

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

More from Alexander obidiegwu

Alexander obidiegwu

10 Hard Python Projects For Intermediates To Boost Your Python Skills &
Portfolio.
Timeline to finish each project — 1 month

5 min read · Dec 25, 2023

1K 6

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 29/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

Alexander obidiegwu

Basic REST API Principles That make you a 1% programmer.

And it only takes 10 minutes

11 min read · Jan 29, 2024

63

Alexander obidiegwu

3 Ways To Run A Python Function Asynchronously

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 30/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

You would most likely fail as a Python programmer without understanding this ground concept.
Asynchronous Programming.
You are signed out. Sign in with your member account
(mn__@p__.com) to view other member-only stories. Sign in
· 8 min read · Dec 15, 2023

381 1

Alexander obidiegwu

5 Concepts Every Python Engineer Should Know in 2024

In computer science, understanding how the hardware works hand in hand with software is
extremely critical, particularly for beginners.

· 7 min read · Dec 16, 2023

260 1

See all from Alexander obidiegwu

Recommended from Medium

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 31/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

You are signed out. Sign in with your member account

(mn__@p__.com) to view other member-only stories. Sign in

LORY

A basic question in security Interview: How do you store passwords in the

database?
Explained in 3 mins.

· 7 min read · May 12, 2024

2K 34

Kumar Devesh in Predict

You Need To Learn AI in 2024! (And Here Is Your Roadmap)

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 32/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

Photo by Maximalfocus on Unsplash

You are signed out. Sign in with your member account
6 min read · Jan 8, 2024
(mn__@p__.com) to view other member-only stories. Sign in

1.3K 31

Lists

Coding & Development

11 stories · 625 saves

Predictive Modeling w/ Python

20 stories · 1220 saves

General Coding Knowledge

20 stories · 1250 saves

Practical Guides to Machine Learning

10 stories · 1479 saves

Vinuki Vidhara in SoulSync

How I Tricked My Brain To Like Doing Hard Things [Dopamine Detox]

Why are some people more motivated to tackle difficult things? And is there a way to make
doing difficult things, easy?

9 min read · Jan 26, 2024

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 33/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

9.99K 128
You are signed out. Sign in with your member account
(mn__@p__.com) to view other member-only stories. Sign in

Jason Roell in Stackademic

Ultimate Python Cheat Sheet: Practical Python For Everyday Tasks

(My Other Ultimate Guides)

34 min read · Jan 29, 2024

4.8K 43

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 34/35
27/05/2024, 14:48 50 Coding Laws That Would Make You A Decent Programmer. | by Alexander obidiegwu | Medium

Alexander Nguyen in Level Up Coding

You are signed out. Sign in with your member account
Why I Keep Failing Candidates
(mn__@p__.com) During
to view other Google
member-only Interviews…
stories. Sign in

They don’t meet the bar.

4 min read · Apr 13, 2023

6.6K 186

Liu Zuo Lin

You’re Decent At Python If You Can Answer These 7 Questions Correctly

# No cheating pls!!

· 6 min read · Mar 6, 2024

4.2K 22

See more recommendations

https://medium.com/@alexobidiegwu/50-laws-of-best-practices-in-python-6942c7cafd56 35/35