\n\n\n\n
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.<\/p>\n\n\n\n
The internet has given everyone the right to voice an opinion. Including even me<\/a>. But in this article, we will be dealing with 50 Python best practices that are set in stone.<\/p>\n\n\n\n These are practices that even God himself can\u2019t tweak. These practices differentiate the pro from the amateur and a lot of them can also be adapted for various programming languages.<\/p>\n\n\n\n Most Python developers need somewhere to quickly test their code or debug errors. I developed a website called <\/em>python-fiddle.com<\/em><\/a> which you can use to quickly test out a code and it uses AI\/LLMs to help find solutions to possible errors.<\/em><\/p>\n\n\n\n I plan to start posting content on linkedln too so if you\u2019re interested: My Linkedln: https:\/\/www.linkedin.com\/in\/alexanderobidiegwu<\/strong><\/p>\n<\/blockquote>\n\n\n\n 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\u2019s doing.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Avoid comments at all costs.<\/p>\n\n\n\n In Law 14 and 15, you would learn when and when not to use a comment.<\/p>\n\n\n\n Sometimes we want to specify that a particular variable is a string or an int. Some developers would therefore name the variable like this: This can be quite redundant especially if the variable is intuitively a string. A But when the variable type isn\u2019t intuitive, rather than specifying the type when naming the variable, the best way to do this is to use type annotations.<\/p>\n\n\n\n This way, everyone can tell the variable is a string while keeping the code neat & concise.<\/p>\n\n\n\n It\u2019s always best practice to keep your class names as nouns.<\/p>\n\n\n\n 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 It also makes the code very readable and less redundant. For example, Functions are best named as verbs because they help the neighboring developer clearly understand what actions they perform.<\/p>\n\n\n\n It also eradicates the need for comments and allows any developer to mentally conceptualize without having to look at the raw code.<\/p>\n\n\n\n When defining a function, you want to always specify what the arguments\u2019 types are and also what data type the result of the function returns.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Bad Practice<\/p>\n<\/blockquote>\n\n\n\n Good Practice<\/p>\n<\/blockquote>\n\n\n\n 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.<\/p>\n\n\n\n You don\u2019t want to do something like this\u2026<\/p>\n\n\n\n (Note that the methods and attributes are just for example purposes.)<\/p>\n<\/blockquote>\n\n\n\n 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.<\/p>\n\n\n\n Here is a better way of doing this.<\/p>\n\n\n\n The above functions do only one thing and nothing more. Although it may seem more verbose, it\u2019s a lot more concise and readable.<\/p>\n\n\n\n Knowing exactly what is \u201cone\u201d functionality can be a bit difficult, especially for new devs. You need to be very specific on what you want a function to do.<\/p>\n\n\n\n Usually, if you can extract or group some of the actions in a function as a whole other function, then it\u2019s probably doing more than one thing.<\/p>\n\n\n\n Another way you can tell is if it has more than one level of abstraction\u2026<\/p>\n\n\n\n When we talk about functions being at the same level of abstraction, we\u2019re 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.<\/p>\n\n\n\n In other words, the function should focus on a specific level of detail or complexity, and all the functions\u2019 operations should operate at that same level.<\/p>\n\n\n\n Good Practice<\/p>\n<\/blockquote>\n\n\n\n This function has statements that are of a low level of abstraction. Things like Bad Practice<\/p>\n<\/blockquote>\n\n\n\n This function, for instance, has a bunch of levels of abstraction. <\/a><\/p>\n\n\n\n medium.com<\/a><\/p>\n\n\n\n A function name should be closely tied to its arguments. You don\u2019t want to have a function that seems to do one thing and the arguments passed do not correlate with the function name.<\/p>\n\n\n\n Bad Practice<\/p>\n<\/blockquote>\n\n\n\n Good Practice<\/p>\n<\/blockquote>\n\n\n\n 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.<\/p>\n\n\n\n The first one isn\u2019t as explicit as the second. You have to make guesses and possibly even have to view the entire function.<\/p>\n\n\n\n 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\u2019s a high chance it\u2019s going to be small.<\/p>\n\n\n\n I plan to start posting content on linkedln too. so if you\u2019re interested: My Linkedln: https:\/\/www.linkedin.com\/in\/alexanderobidiegwu<\/strong><\/p>\n<\/blockquote>\n\n\n\n There are times when devs use words that don\u2019t provide any further clarification on a variable or function\u2019s meaning. Things like this:<\/p>\n\n\n\n Without having prior knowledge of the function\u2019s implementations, a developer seeing this doesn\u2019t know which function to use.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n But what is a clean code? A clean code is well structured and arranged.<\/p>\n\n\n\n A clean code doesn\u2019t hide bugs. It exposes anywhere a bug could hide to the programmer and makes room for an easy fix without complete refactoring.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Let\u2019s take for instance, we have a class called address.<\/p>\n\n\n\n This fails to adhere to OCP because whenever there\u2019s a new country, we would need to write a new This is where OCP comes into play.<\/p>\n\n\n\n This is a more robust solution because now we don\u2019t 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 Another common example you would see is using class inheritance.<\/p>\n\n\n\n For example:<\/p>\n\n\n\n This is a wrong method because anytime we want to add a new payment method, we would always need to modify the A better way to do this is:<\/p>\n\n\n\n This way, whenever we need to add a new payment option, say crypto or paypal, we wouldn\u2019t need to edit or modify any class to achieve this. we could simply do this:<\/p>\n\n\n\n If we look at the previous principle, when making payments using crypto, we don\u2019t 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:<\/p>\n\n\n\n Then when calling each payment processor, we declare the crypto argument as a This is because the parent class or the abstract class, contains an argument that isn\u2019t relevant to most of our subclasses<\/p>\n\n\n\n The Liskov Substitution principle (LSP)<\/strong> states that \u201cObjects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program\u201d<\/em>.<\/p>\n\n\n\n To adhere to LSP, we would need to define the cryptocurrency within the 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 \u201cgood\u201d comments.<\/p>\n\n\n\n Informative comments TODO comments Regardless of your reason, comments like this provide more value than they take. Warning of consequences Suppose a certain code takes time or has the possibility of overloading certain systems, a warning like Noise comments<\/strong> Non Local information<\/strong> Unobvious comments<\/strong> Short Functions<\/strong> <\/a><\/p>\n\n\n\n medium.com<\/a><\/p>\n\n\n\n A source file should be between 100\u2013200 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Go where you are valued<\/p>\n<\/blockquote>\n\n\n\n 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\u2019s being called?<\/p>\n\n\n\n The worst part of this is you can\u2019t understand the relation in one glance. It\u2019s a back-and-forth movement. Once you\u2019ve experienced this, you\u2019ll understand how valuable it is to keep related code to each other.<\/p>\n\n\n\n A function\/Variable should be as close to where it\u2019s needed the most or has the most importance. It should be furthest away from where it has the least importance.<\/p>\n\n\n\n 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\u2026<\/p>\n\n\n\n There exists no whitespace between the parenthesis between the function and the name variable. If there was, it would look very disjointed and uncoordinated\u2026<\/p>\n\n\n\n Arguments passed into a function, should be separated to show that the arguments are separate.<\/p>\n\n\n\n Almost every developer has his\/her style. From the way we name our files, to the way we write print statements.<\/p>\n\n\n\n But when it comes to working with other devs, you want to dumb down those personal preferences and adopt the team\u2019s preferences. Not everyone might be able to see beauty in your code the way you do.<\/p>\n\n\n\n A Magic Number is a hard-coded value that may change at a later stage, but that can be therefore hard to update.<\/p>\n\n\n\n For example, let\u2019s say you have a Page that displays the last 50 Orders in a \u201cYour Orders\u201d Overview Page. 50 is the Magic Number here because it\u2019s not set through standard or convention, it\u2019s a number that you made up for reasons outlined in the spec.<\/p>\n\n\n\n Now, what you do is you have the 50 in different places \u2014 your SQL script ( Limit the levels of nesting within loops, conditionals, or functions to improve readability.<\/p>\n\n\n\n Use descriptive names instead of cryptic abbreviations to enhance readability.<\/p>\n\n\n\n Refrain from hardcoding file paths or URLs; use configuration files or environment variables instead.<\/p>\n\n\n\n <\/a><\/p>\n\n\n\n medium.com<\/a><\/p>\n\n\n\n When writing code, it\u2019s 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.<\/p>\n\n\n\n You want to use try-catch statements when a certain code is more likely to return an error.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Have you ever seen a code like the one below\u2026<\/p>\n\n\n\n This is extremely bogus and takes away (in verbosity, complexity, and maintenance) the additional help it provides in error handling.<\/p>\n\n\n\n It\u2019s 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.<\/p>\n\n\n\n Only be specific about the type of error you want to catch, when you want all other errors to pass through.<\/p>\n\n\n\n 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?<\/p>\n\n\n\n If the function mutates the argument(s) passed, we only need to do that in that function and nothing else.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n If the argument(s) is used to create another variable, then it doesn\u2019t mutate. For instance, if an argument called But there\u2019s 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n If a function returns something without mutating its arguments, the function\u2019s name should be a noun. If a function mutates the arguments and returns none, it should be a verb.<\/p>\n\n\n\n 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 There are obviously exceptions to this and whenever you feel you\u2019ve encountered one, feel free to fall back on using verbs.<\/p>\n\n\n\n Yep! Classes should be as small as possible. Just like functions.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n This takes us back to SRP (single responsibility principle) which states that a class should only have one reason \u2014 one responsibility \u2014 to change.<\/p>\n\n\n\n Instance variables, in case you don\u2019t know, are variables that are defined when the class is defined or instantiated.<\/p>\n\n\n\n If all our functions are related to the class responsibility, there\u2019s no reason why we should have a lot of instance variables.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n These functions tend to come with their own variables that other functions in the class do not need.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Use the Refrain from using overly complex ternary expressions; favor readability over brevity to make code<\/a> more understandable.<\/p>\n\n\n\n <\/a><\/p>\n\n\n\n medium.com<\/a><\/p>\n\n\n\n Most of the time, we use But when dealing with mutable data types, such as 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.<\/p>\n\n\n\n Strings, tuples, and integers cannot be changed once created.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n It states that high-level modules should not depend on low-level modules, but both should depend on abstractions.<\/p>\n\n\n\n In other words, classes should depend on interfaces or abstract classes rather than on concrete implementations.<\/p>\n\n\n\n In the example above, we define the class And as you can see this also fails to adhere to the open closed principle (open for extension, closed for modification).<\/p>\n\n\n\n This tight coupling makes the code harder to test because we can no longer simply use a fake logger class when testing.<\/p>\n\n\n\n This promotes modularity because changes to one component do not necessarily require changes to other components as long as the interface remains consistent.<\/p>\n\n\n\n This modularity enables easier understanding, modification, and extension of the codebase.<\/p>\n\n\n\n Use 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.<\/p>\n\n\n\n The example below uses the hard-coded number 0.1 to represent a 10% discount.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The improved code replaces the hard-coded number with a named constant 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n It\u2019s 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<\/a><\/p>\n\n\n\n Some common conventions are:<\/p>\n\n\n\n The law of Demeter, in simple terms, means that a By immediate neighbors, this means methods or functions or variables that can be directly accessed.<\/p>\n\n\n\n An example should clear this up\u2026<\/p>\n\n\n\n In this example, the It has gone past an immediate neighbor and now knows too much about the customer\u2019s object.<\/p>\n\n\n\n In this adherent example, the It does not reach into the internal structure of the Code needs to work and be understood by the machine executing it. However, other developers also need to be able to understand the code<\/strong>, especially if you are working on a project with multiple people.<\/p>\n\n\n\n That is why the readability of code is always more important than its conciseness when it comes to software development.<\/p>\n\n\n\n There is no point in writing concise code if other developers cannot understand it.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Imagine you want to write a function with the name \n
LAW 1: Avoid Comments At All Cost<\/h2>\n\n\n\n
LAW 2: Do Not Use Type Attributes As A Name For Variables<\/h2>\n\n\n\n
name_of_variable_str<\/code> or name_of_variable_int<\/code>.<\/p>\n\n\n\nname<\/code> variable, for instance, can never be an int<\/code> type.<\/p>\n\n\n\nname_of_variable:str = value<\/code> instead of name_of_variable_str = value<\/code>.<\/p>\n\n\n\nLAW 3: Class Names Should Be Nouns.<\/h2>\n\n\n\n
horns<\/code> and actions like nod_nearby_humans<\/code>.<\/p>\n\n\n\nGoat.get_horn_length()<\/code> instead ofGetGoat.get_horn_length()<\/code> .<\/p>\n\n\n\nLAW 4: Function Names Should Be Verbs<\/h2>\n\n\n\n
LAW 5: Functions Should Specify The Parameter And Return Type<\/h2>\n\n\n\n
\n
![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:963\/1*zB-VmY10b1sW6-0HxupT2A.png\")
\n
![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:913\/1*9KDNNZH-xGwK7ZcdtUEMnw.png\")
LAW 6: A function Must Perform One Functionality Only<\/h2>\n\n\n\n
\n
![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:967\/1*ZuWHaYKcmZ41lWkW_3q0TQ.png\")
![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:893\/1*mxOdYOlU5ojDsKRmBN76aA.png\")
LAW 7: Functions Should Be At The Same Level Of Abstraction<\/mark><\/h2>\n\n\n\n
\n
![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:724\/1*qggU6SP1MqB4UXvxvXgEzQ.png\")
sum<\/code>, len,<\/code> etc.<\/p>\n\n\n\n\n
![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:1103\/1*vEnd7ouHN4dTO8LOGB2bNA.png\")
get_numbers()<\/code> is a high level of abstraction, the list comprehension is an intermediate level of abstraction, and sum<\/code> is a low level of abstraction.<\/p>\n\n\n\nBasic REST API Principles That make you a 1% programmer.<\/a><\/h2>\n\n\n\n
And it only takes 10 minutes<\/a><\/h3>\n\n\n\n
LAW 8: A Function and It\u2019s Argument(s) Should Be Like Brothers And Sisters<\/h2>\n\n\n\n
\n
write(True)<\/code><\/p>\n\n\n\n\n
write(name)<\/code><\/p>\n\n\n\nLAW 9: Functions Should Be Small<\/h2>\n\n\n\n
\n
LAW 10: Avoid Noise\/Redundant Words<\/h2>\n\n\n\n
![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:670\/1*N4x1Fw0U_zsjdu4f-JKq_Q.png\")
LAW 11: Do Not Be A Dirty Programmer<\/h2>\n\n\n\n
LAW 12: Open Closed Principles<\/h2>\n\n\n\n
![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:1193\/1*GENI8yqWOC_lplpDGe0OjQ.png\")
if<\/code> 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?<\/p>\n\n\n\n![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:1260\/1*I5MglDAyqDeIfPqceEYymg.png\")
capital<\/code> dictionary.<\/p>\n\n\n\n![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:1260\/1*HNehsIzSEbBV6ujfrwpe0Q.png\")
<\/figure>\n\n\n\nPaymentProcessor<\/code> class.<\/p>\n\n\n\n![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:1260\/1*uQZDRkmLFSBPnxiuSmOAng.png\")
<\/figure>\n\n\n\n![\"\"\/](\"https:\/\/miro.medium.com\/v2\/resize:fit:1260\/1*N5V-GsG7dBYefF3zg2Qlfg.png\")
<\/figure>\n\n\n\nLAW 13: Liskov Substitution Principle<\/h2>\n\n\n\n
from abc import abstractmethod
class PaymentProcessor:
@abstractmethod
def pay_tax(amount, crypto):
pass<\/pre>\n\n\n\nNone<\/code> 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.<\/p>\n\n\n\nCryptoPaymentProcessor<\/code> class to avoid any irrelevant clash with other subclasses.<\/p>\n\n\n\nclass 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}')<\/pre>\n\n\n\nLAW 14: Know When To Use A Comment<\/h2>\n\n\n\n
<\/strong>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.<\/p>\n\n\n\n
<\/strong>Comments like this help other programmers know that this is an unfinished function\/task or it requires modification. Maybe there\u2019s a better way to implement a certain function that wasn\u2019t taken advantage of. Maybe the code fails periodically.<\/p>\n\n\n\nTODO comments<\/code> 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.<\/p>\n\n\n\n
<\/strong>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.<\/p>\n\n\n\n#CONSUMES A LOT OF COMPUTING RESOURCES<\/code> would be beneficial to a reader or other programmers.<\/p>\n\n\n\nLAW 15: When Is A Comment Bad?<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n# adds to animal list
animal.append(dog)<\/pre>\n\n\n\n
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.<\/p>\n\n\n\n
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\u2019t want your comment to need to have its comment as well.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n3 Ways To Run A Python Function Asynchronously<\/a><\/h2>\n\n\n\n
You would most likely fail as a Python programmer without understanding this ground concept. Asynchronous Programming.<\/a><\/h3>\n\n\n\n
LAW 16: Keep Source Files Short<\/h2>\n\n\n\n
LAW 17: Know When To Use Blank Lines<\/h2>\n\n\n\n
LAW 18: Keep Related Lines Of Code\/Functions\/Classes Close<\/h2>\n\n\n\n
\n
LAW 19: Know When To Use White Spaces<\/h2>\n\n\n\n
def create(name):
print(name)<\/pre>\n\n\n\ndef create (name):
print (name)<\/pre>\n\n\n\nLAW 20: Obey Team Rules<\/h2>\n\n\n\n
LAW 21: Avoid Magic Numbers<\/h2>\n\n\n\n
SELECT TOP 50 * FROM orders<\/code>), your Website (Your Last 50 Orders), your order login (for (i = 0; i < 50; i++)<\/code>) and possibly many other places.<\/p>\n\n\n\n# Bad
SELECT TOP 50 * FROM orders
# Good
NUM_OF_ORDERS = 50
SELECT TOP NUM_OF_ORDERS * FROM orders<\/pre>\n\n\n\nLAW 22: Avoid Deep Nesting<\/h2>\n\n\n\n
# Bad
if x:
if y:
do_something()
# Good
if x and y:
do_something()<\/pre>\n\n\n\nLAW 23: Avoid Temporary Variables<\/h2>\n\n\n\n
# Bad
temp_result = calculate(x, y)
final_result = temp_result * 2
# Good
final_result = calculate(x, y) * 2<\/pre>\n\n\n\nLAW 24: Avoid Cryptic Abbreviations<\/h2>\n\n\n\n
# Bad
def calc(x, y):
pass
# Good
def calculate_total_price(quantity, unit_price):
pass<\/pre>\n\n\n\nLAW 25: Avoid Hardcoding Paths<\/h2>\n\n\n\n
# Bad
file_path = \"\/path\/to\/file.txt\"
# Good
import os
file_path = os.getenv(\"FILE_PATH\")<\/pre>\n\n\n\n10+ Scalability Laws To Follow In Your Next Project.<\/a><\/h2>\n\n\n\n
Don\u2019t Touch your keyboard without understanding this<\/a><\/h3>\n\n\n\n
LAW 26: Always use Try-Catch-Finally Statements<\/h2>\n\n\n\n
LAW 27: Provide Context with Exceptions<\/h2>\n\n\n\n
Law 28: Avoid Using Multiple Exception Class<\/h2>\n\n\n\n
try:
pass
except ValueError:
pass
except TypeError:
pass
except IndexError:
pass
except KeyError:
pass
except FileNotFoundError:
pass<\/pre>\n\n\n\ntry:
pass
except Exception:
pass<\/pre>\n\n\n\nLAW 29: A function must either mutate or return something, but not both.<\/h2>\n\n\n\n
def changed(array):
array.append('hello')<\/pre>\n\n\n\ntime<\/code> was used to calculate a distance<\/code>, then it doesn\u2019t mutate, which means distance can be returned in that function.<\/p>\n\n\n\ndef calculate_distance(time, speed):
distance = speed * time
return distance<\/pre>\n\n\n\ndef changed(array):
array_copy = array[:]
array_copy.append(4)
return array_copy<\/pre>\n\n\n\nLAW 30: Not all function names should be verbs<\/h2>\n\n\n\n
None<\/code> while methods like sorted, sum, product<\/code> are all nouns because they don\u2019t mutate any arguments passed and return a new copy of the data.<\/p>\n\n\n\nLAW 31: Classes should be small<\/h2>\n\n\n\n
LAW 32: Classes should have a small number of instance variables<\/h2>\n\n\n\n
class Animal:
def __init__(self, name):
self.name = name #instance variable<\/pre>\n\n\n\nLAW 33: Your classes should be cohesive.<\/h2>\n\n\n\n
LAW 34: Use the with Statement for Resource Management<\/h2>\n\n\n\n
with<\/code> statement to automatically manage resources like files or database connections, ensuring they are properly closed or released.<\/p>\n\n\n\n# Bad
file = open(\"example.txt\", \"r\")
data = file.read()
file.close()
# Good
with open(\"example.txt\", \"r\") as file:
data = file.read()<\/pre>\n\n\n\nLAW 35: Avoid Complex Ternary Expressions<\/h2>\n\n\n\n
# 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\"<\/pre>\n\n\n\n10 Hard Python Projects For Intermediates To Boost Your Python Skills & Portfolio.<\/a><\/h2>\n\n\n\n
Timeline to finish each project \u2014 1 month<\/a><\/h3>\n\n\n\n
LAW 36: Use \u2018is\u2019 and \u2018is not\u2019 for Identity Comparison<\/h2>\n\n\n\n
==<\/code> 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.<\/p>\n\n\n\nlist, dicts <\/code>and custom objects, it\u2019s often better to use the is<\/code> comparator because it checks the subtype of the variable and the memory location.<\/p>\n\n\n\nRun 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 `==`.<\/pre>\n\n\n\nLAW 37: Dependency Inversion Principle<\/h2>\n\n\n\n
# 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<\/pre>\n\n\n\nLogger<\/code> and directly create a new instance of it in our Calcuator<\/code> class. This means that Calculator<\/code> now depends on Logger<\/code> class and if for any reason we change Logger<\/code> class, we now also have to modify Calculator<\/code> class.<\/p>\n\n\n\n# 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<\/pre>\n\n\n\nLAW 38: Avoid Using \u2018assert\u2019 for Data Validation<\/h2>\n\n\n\n
assert<\/code> statements for debugging and development purposes only; avoid using them for data validation in production code<\/a>.<\/p>\n\n\n\n# Bad
assert x > 0, \"x should be positive\"
# Good
if x <= 0:
raise ValueError(\"x should be positive\")<\/pre>\n\n\n\nLAW 39: Avoid Hard-Coded Numbers<\/h2>\n\n\n\n
def calculate_discount(price):
discount = price * 0.1 # 10% discount
return price - discount<\/pre>\n\n\n\ndef calculate_discount(price):
TEN_PERCENT_DISCOUNT = 0.1
discount = price * TEN_PERCENT_DISCOUNT
return price - discount<\/pre>\n\n\n\nTEN_PERCENT_DISCOUNT<\/code>. The name instantly conveys the meaning of the value, making the code more self-documenting.<\/p>\n\n\n\nLAW 40: Follow the DRY (Don\u2019t Repeat Yourself) Principle<\/h2>\n\n\n\n
# 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<\/pre>\n\n\n\nLAW 41: Follow Established Code-Writing Standards<\/h2>\n\n\n\n
\n
LAW 42: Law of Demeter<\/h2>\n\n\n\n
module\/function\/class<\/code> can have knowledge or make reference to another module\/function\/class<\/code> immediate neighbors but should not have any knowledge further than that.<\/p>\n\n\n\nclass 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()<\/pre>\n\n\n\nOrder<\/code> class directly accesses the customer\u2019s profile to retrieve the customer\u2019s name. This violates the Law of Demeter because Order<\/code> is reaching into the internal structure of the Customer<\/code> object to access its profile and name.<\/p>\n\n\n\nclass 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()<\/pre>\n\n\n\nOrder<\/code> class only interacts with its immediate collaborator, the Customer<\/code> object, and calls a method directly on it to retrieve the customer\u2019s name.<\/p>\n\n\n\nCustomer<\/code> object, thus following the Law of Demeter.<\/p>\n\n\n\nLAW 43: Readability over conciseness<\/h2>\n\n\n\n
LAW 44: Keep Imports Clean<\/h2>\n\n\n\n
get_file<\/code>. You click g<\/code> and your IDE recommends you a list of functions\/classes\/variables that start with the letter g<\/code>. It can become quite chaotic.<\/p>\n\n\n\n