- Link: medium.com
- Author: Alexander obidiegwu
- Publication date: March 2, 2024
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.
These are practices that even God himself can’t tweak. These practices differentiate the pro from the amateur and a lot of them can also be adapted for various programming languages.
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.
I plan to start posting content on linkedln too so if you’re interested: 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.
name_of_variable:str = value instead of name_of_variable_str = value.
This way, everyone can tell the variable is a string while keeping 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 ofGetGoat.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
Good Practice
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.)
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.
The above functions do only one thing and nothing more. Although 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
This function has statements that are of a low level of abstraction. Things like sum, len, etc.
Bad Practice
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.
Basic REST API Principles That make you a 1% programmer.
And it only takes 10 minutes
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.
I plan to start posting content on linkedln too. so if you’re interested: My Linkedln: https://www.linkedin.com/in/alexanderobidiegwu
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:
Without having prior knowledge of the function’s implementations, a developer seeing this doesn’t know which function to use.
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.
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.
This is a more robust solution because now we don’t need to modify either the class or its functions. If we ever want to consider a country and its capital, we can simply 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:
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
The Liskov Substitution principle (LSP) states that “Objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program”.
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 these landmines could have some unforeseen consequences. And we want to all survive through the day. Comments can save the day in this situation.
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.
3 Ways To Run A Python Function Asynchronously
You would most likely fail as a Python programmer without understanding this ground concept. Asynchronous Programming.
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 obvious benefits such as reusability and readability. They are also easier to maintain and update since we spend less time scrolling and trying to connect the dots.
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)
Arguments passed into a function, should be separated to show that the arguments are separate.
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 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 < 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()
# Good
if x and y:
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")
10+ Scalability Laws To Follow In Your Next Project.
Don’t Touch your keyboard without understanding this
LAW 26: Always use Try-Catch-Finally Statements
When writing code, it’s always best to include error handling also. This can help speed up the debugging process and increase the sophistication of the code while 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.
try:
pass
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.
def changed(array):
array_copy = array[:]
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.
class Animal:
def __init__(self, name):
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"
# Good
if number % 2 == 0:
result = "even"
elif number % 3 == 0:
result = "odd"
else:
result = "neither"
10 Hard Python Projects For Intermediates To Boost Your Python Skills & Portfolio.
Timeline to finish each project — 1 month
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 `==`.
LAW 37: Dependency Inversion Principle
The Dependency Inversion Principle (DIP) is a fundamental principle of object-oriented design that promotes loose coupling between components 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
class LoggerInterface(ABC):
@abstractmethod
def log(self, message):
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.
def calculate_discount(price):
discount = price * 0.1 # 10% discount
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
LAW 41: Follow Established Code-Writing Standards
It’s important to follow commonly accepted conventions in terms of spacing, comments, and naming. Most programming languages have 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.
It has gone past an immediate neighbor and now knows too much about the customer’s object.
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.
This becomes more of a pain when you want to call that function. Your function name could be lost in between the recommendations and now your IDE becomes more of a problem than an efficient 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.
Contains no duplication: Duplication is the primary enemy of a well designed system
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:
Starvation: Starvation occurs when a thread or process is unable to gain access to a shared resource indefinitely, despite attempting to do so. This can happen when other threads or processes continually acquire and hold the resource, 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.
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…
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.