Write Python Code Properly!

Key Takeaways

[Music] hello everybody and welcome to another youtube video so in today's video i'm going to show you the proper way to write python code and when i say that what i mean is i'm going to show you the proper python conventions and go through the most important parts of the python style guide which is known as pep8 now pep8 is a very large python style guide i'll leave a link in the description to it it's written by guido who is the inventor and creator of python well there's just a ton of things in there obviously i can't cover everything but i'll show you kind of the things that i see people making the mistake on most commonly and what i consider to be the most important things that you kind of need to know from that guideline with that said if you don't follow that guideline it's not necessarily incorrect your code is not wrong it just doesn't adhere to it in some people if you're working in maybe a large organization for example may be a little bit upset that you're not being consistent with how python code should be written so that said let's go ahead and get into the video after a quick word from our sponsor before we get started i need to thank harperdb for sponsoring this video harperdb is a hybrid sql slash nosql database that is accessed via a single rest api endpoint harperdb provides a scalable and flexible database that improves your app's performance with the ability to run sql on json data you no longer have to pick a database based on the structure of your data harperdb will run anywhere and ingest any type of data at scale with harperdb you can perform all crud database operations using only one single endpoint you can execute sql on json data and insert data via json csv or sql queries harper db also removes the headache of database connectivity and setup by providing a geo-distributed database that improves speed performance and latency harperdb is incredibly fast allowing one single node to handle up to a hundred thousand requests per second it can also globally replicate data at the speed of the internet to put this into perspective harperdb benchmarks at speeds 37 times faster than mongodb if you need any help along the way harperdb has detailed documentation and tons of customizability for more advanced developers thanks again to harperdb for sponsoring this video spin up a free forever instance today by clicking the link in the description all right so let's go ahead and get started in front of me here you can see i have pep 8 the style guide for python code this is available on the python website it's written by guido and i just quickly wanted to show you what the table of contents looked like so you can see how much stuff is actually in here so obviously i won't go through all of this as i mentioned i'm probably covering you know 10 of what's actually in this document but a lot of the stuff in here is just really nitpicky and something that you probably don't really need to know anyways there you go that is the guide so what i'm going to do now is go to vs code which is the ide i'm going to use for this video and the first thing i want to show you is just how to make your life a little bit easier if you're trying to write code according to the pep 8 style guideline so one of the main things in the pep8 style guideline is any line cannot exceed 80 characters in python so to give you an example take a look at this i have this long function name with long arguments obviously this is just an example and if we go here and look at the bottom we can see this has 116 characters so really what the pep 8 guideline wants us to do is split this line up such that it only has max 80 characters on the first line so we could do something simple like this right and then kind of get the indentation correct here and then that would be fun however if we don't want to have to do this ourself what we can do is actually use a formatter an auto formatter where when we save our file it will automatically fix a ton of formatting issues for us so i'm just going to show you how to set that up quickly such that you don't have to automatically format and change the line length and do all that kind of stuff so if you're working in vs code then what you can do is start by installing an auto formatter using pip which is called black now black is probably the most popular formatter for python but the way you do this is pip install and then black now i'm not going to exactly go through what pip is if you're not familiar with that but try this command if it doesn't work you can try pip 3 pip 3 should work if you're on mac or linux and then if that doesn't work you can do python hyphen m pip install and if that doesn't work python 3 hyphen m pip install black all right so once you've installed the auto formatter with pip then if you're working in vs code what you're going to need to do is go to settings so i'm going to go to settings settings and then you're going to go for the python and this should be the format provider like that so if you look up python format provider then what you're going to do is select black here by default you have auto pep 8 doesn't work as well as black so i'm going to select black and now if you go to format here and you check the format on save so format a file on save so automatically format it whenever you save the file what's going to happen when i save this file is it's going to auto format this line for me so you can see it's made it such that this line here is exactly 80 characters long i just want to show that to you because that saves you a lot of time when you're actually trying to write code according to the pep 8 style guideline and it will fix other things for you as well not just line length alright so now that i've covered the auto formatter we'll start getting into the pep 8 guideline more specifically so the first thing you saw is that the maximum line length is 80 characters so as soon as you get to 80 characters you should go down to the next line technically the maximum line length is 79 characters but the last character on the line where you go down to the next one is the 80th character right and then the next important rule in the pep8 style guideline is the indentation should be using spaces and you should be using four spaces for all of your indentations you can see down here i have spaces and i have four and i'm using spaces so just make sure you indent using spaces and four spaces a lot of editors actually indent using tab it's fine if you indent using tab but it can cause some issues and you can get some weird errors so it's always preferable to use spaces and four spaces all right now moving forward the rest of the rules that i'm going to show you here are typically considered the best practice and what you should use however there's always exceptions to these rules and if they make your code less readable or they don't make sense to implement then it's always fine to kind of ignore them and go with whatever style that you're using really the most important thing when you're writing any code not even just python code is whatever style you go with it's consistent so if you use single quotation marks for strings always use single quotation marks for strings if you're doing a space around your operators always use a space around your operators just make sure that whatever you're doing is consistent that's way more important than following the strict rules that i'm going to show you here all right so now what i want to do is get into name all right so let's start with the naming convention for variables so the naming convention for your just typical variables in python is to use snake case or word underscore word convention case whatever you want to call it so what i mean by that is if you have a variable that is two words sorry this should be lowercase then what you want is something like this hello world as opposed to something like this this would be the incorrect case this is camel case instead you want to use snake case this is probably the most common error i see in python uh people use camo case when they should really be using snake case for their variables now some people also do something like this this is known as pascal case this is also incorrect you don't want to do that for variables now if you add a third word here same thing you would just separate again with another underscore there you go simple that's all you need to know for the naming convention for variables now the naming convention for constants is to do all uppercases and then snake case there's probably a name for this but it looks something like this so let's say you had a constant variable you would name it like this notice it's highlighting in a different color now a constant variable is a variable that stores a value that you do not expect to change in the program and that really should not change in the program at all so an example of a constant might be something like a color that you're going to use to for styling your website or styling a game or something that's never going to change in this case again you do it in all capitals and then you would you know put whatever the value of the constant is and then this variable should never have its value changed it should only ever just be used in the program as a constant now there's not really a way to enforce that this is not going to be changed in other programming languages there is but regardless when you have a constant you normally want to put this at the very top of the program below any import statements and then have it in all capitals now if you had two words you could do something like this bg underscore color this would be correct standing for background color you do it with an underscore in all capitals and again this goes at the top of your program below any import statements okay so that is the naming convention for constants now the naming convention for modules that would be the actual python file itself is to have it all in lowercase so you usually want one word all lowercase but if you do need to have multiple words then you want to separate that with underscores so just like you would name a variable that's how you name your modules except it's preferred that you just have one word and you don't have you know multiple words if you do have multiple words separate them with underscores now the naming convention for functions is the same as for variables so if i have my hello oops underscore world function this is correct you do not want to name a function hello world like that again this isn't really incorrect you can do it there's nothing wrong with doing that it just doesn't follow the python convention okay so that is functions now lastly we need to go over classes and exceptions so when you name a class you want this to be in pascal case that means an upper case on the first word uppercase on the second word and you're having them kind of in camel case notation so let me just type it out and you'll see what i mean let's name this base class or something this is what you want so you want a capital on the first word no no underscore and a capital on the second word and that's how you name a class okay pretty straightforward and then if you just had one word you would just do it like that now whenever you name an exception same thing you want it to be in pascal case now the reason for that is an exception is a class in python and so it should have the same naming convention so if you were to create an exception let's just say you know this is called base exception or something i think that that's actually a built-in class in python let's just call this x exception then you would name it like this hopefully that makes sense but that's really all of the important naming conventions in python that you need to know alright so the next thing that i want to cover here is just some parameter naming conventions related to methods in classes so let's say we have a class we can call this class test and let's say we have a test method and this method is an instance method then the first parameter for this method should be named self so a lot of people know this and they probably actually think you have to name this self but technically i could name this s i could name this inst or something whatever you name that whatever i want it will still work it will still hold the instance the method was called on but by convention it should always be named self so again the first parameter in an instance method should always be named self now in the same way if you have a class method so let's go at class method like that and then we define i don't know let's go cls underscore method the first parameter here should be named cls so again a convention first parameter of any class method should be named cls standing for class there you go simple enough okay so that was all i need to cover for this just make sure you use self and cls as your four first parameter values for class and for instance methods alright so the next convention i have for you has to do with spacing out classes methods and functions again people mess this up all of the time even if you decide not to follow these rules just make sure you stay consistent with how you decide to space these out so let's define a few classes here and functions and methods so i can show you what i mean so let's have a our class foo and let's define an init okay and we can just do a pass in here let's define a i don't know foo method and let's do a pass inside of here okay let's define a function we'll call this bar and let's do a pass all right so this is what i have right here now any top level functions or classes should be separated by two white spaces or sorry two blank lines so what i mean by that is that this is correct you want to separate your classes with two spaces here and two blank lines and then same thing here with the function now the reason for this is these are in the top level top level meaning kind of furthest left indentation level these are all global to this file and so that means you space them out with two blank lines however methods inside of the classes are spaced out with one blank line so that's really all you need to know here just make sure all of your functions and all of your classes let's just do another one here have two lines in between them if they're in the top level if they're nested inside of something then that might change and if you have methods here inside of a class you separate them with one line all right so next i'm going to talk about imports now imports should always go at the very top of your file unless there's some specific exception and some reason why you can't import something at the very top of your file but you always want all of your imports at the top of the file and they're just on the next line from each other so let me show you what i mean you have something like import os import sys this is correct you've imported things properly now you can actually import things on the same line so import os and import sys but this is not the python convention and 8 says you should not do this so i should not import two distinct modules on the same line i should split them into two lines like this and again top of your program now the exception is that if you're going to be importing things from a module you can import multiple of them on the same line so maybe i say from os import path and import i don't know stat or something i don't know what other thing i would import from os but you get the idea this is fine because i'm importing two things from one individual module and so i can import them on one line that is okay you don't need to do something like from os import if i can type this stat like that okay so that is kind of the basic rules with import now one more important thing is you should not use the wildcard import so what i mean by that is you shouldn't do something like from os import asterix that is incorrect you shouldn't do that this is just not good to use because this will import everything and it doesn't clearly define what parts of os you're actually going to be using in your program so just avoid this if you can alright so one more important note here the only time when you're not going to have your import statements and let me change this to a proper import statement at the top of your program is if you have a module docstring so if you have a module docstring this is a string that describes what's in this python module then your imports can go after that otherwise they're going to go at the very top of the program and then after your imports you're usually going to have any of your globally defined variables and constants and then any of your top level functions and classes all right so now i'm going to cover strings and specifically what type of quotation marks you can use so this is a big issue in python as well and i'm very guilty of doing this but in python the single and double quotation marks are completely equivalent and there actually is no preference on whether you use the single or the double quotation marks the only rule is if you use double quotation marks you should always use double quotation marks and if you use single quotation marks you should always use single quotation marks the only exception to that would be if you need to actually embed a single or double quotation mark inside of a string so it's preferential if you want to put a double quotation mark inside of a string that you wrap the string in single quotation mark so if i actually wanted to say something like hello double quotation mark for some reason then i would put that inside of single quotation marks and in the other way around if i wanted to use a single quotation mark then i would wrap that inside of double quotation marks now that is opposed to doing this so you can actually use an escape character in python to escape this quote such that this string is maintained but it's preferred to just wrap with the opposite quotation marks rather than using an escape character although sometimes you do need to use the escape character so that's kind of the rule with quotation marks just be consistent on whatever set you decide to use doesn't matter if you single or double there is no preference in at the style guideline however when you are writing a doc string or a triple quoted string like this you should always use uh double quotation marks don't know why that's a thing i would have imagined you could use single or double as long as you're consistent but it says you should always use double quotation marks whenever you're writing a triple quoted string all right so next i'm going to talk about the incorrect usage of white spaces so i'm just going to paste a bunch of examples here and then show you what i mean on the incorrect usage of white spaces so let's look at this one for example we have some functions spam ham indexing 1 and then we're creating some dictionary here this is correct you do not want to have white spaces between a bracket brace parentheses whatever it may be and whatever comes after that so looking at this this would be incorrect you do not want to have spaces like this you can see all of the white spaces showing up just don't do that make everything look like this all right the next example is this you do not want to have white spaces between a trailing comma and a closing parenthesis so if you have something like this you want to leave it like this right you don't want to have a space between the trailing comma and the closing parenthesis the next situation in which you do not want to have a white space is right here so you do not want to have a white space in between a function call or in between something and an opening parenthesis followed by arguments to some call so whether this is a function whether this is a class it doesn't matter you don't want to have this so don't separate your arguments from the actual call that you're making this is the correct way that you should call a function initialize a class whatever it may be alright so this is the next example of white space usage that you want to know the first thing to note here is when you're declaring a variable you always want to have at least one space on each side of the equal sign so this is correct notice this is incorrect right because we don't have any spaces on each side of the equal sign like that now another thing is when you're using a operator like the plus sign or the minus sign typically you are going to want to have spaces on either side of this operator the only time in which you shouldn't have that is when you're trying to show the precedence of operators then you can actually kind of jam the operands together with the operator seems a little bit weird but have a look at this example right here so in this situation it's fine to have a plus b and a minus b because they're trying to show these happen before the multiplication so that's the only time when it's okay to kind of mess with the spacing here is when you're going to try to show the precedence of operators now when you're using the multiplication sign same thing it's fine to have two things squished together here because we're trying to show that these are going to happen before the addition operation okay when you're using something like plus equals or minus equals you want one space on each side of this operator and when you are using any operation you want the same amount of space on each side of the operator so something like this is no good because i have no space here and one space here so whatever you do just make sure it's consistent you should always have the same number of spaces on the left and right hand side of any operand now if you're looking at this this is considered incorrect first of all because you don't have the same number of spaces and you should always have one space here this one is considered incorrect because you're not properly showing the precedence of operators i make this mistake all the time but you should do x times two minus one same thing here you're not correctly showing the presence of operators so you should do that and that and then this one you could argue whether it's incorrect or not but again it wants you to do this to show the precedence of the operators all right so the next example here kind of contradicts what i just showed you but this is specific to white spaces in the default value for parameters in a function or for arguments so this is correct the reason this is correct is because you do not want any white spaces on the left or right hand side of the equal sign when you're defining the default value of a parameter same thing when you are calling a function with default values or sorry you're assigning keyword arguments that's what i meant to say you want to make sure you don't have any space so you can see why this is incorrect here we would need to remove the spaces and all of these for this to now follow the pep8 style guide all right so now i'm going to talk to you about inline comments this is super simple but these are things again that people mess up a lot i'm just going to paste in an example here so you can see this is correct and this is incorrect so an inline comment is a comment that goes on the same line as some expression variable whatever in this case this is correct because we have at least two spaces between the line and the comment the comment has at least one space between the pound sign and what the actual content of the comment is and the comment starts with an uppercase so that is kind of the rules for an inline comment at least two spaces between it and whatever the expression is on that line one space after the pound sign and then you want it to start with a capital unless it doesn't make sense have it start with a comp now this is wrong because we only have one space here we don't have a space between the pound sign and then if we want to be even more wrong we could do this this would need to be a capital to make this correct we need it to look like this so again these rules aren't super super strict but just make sure you're consistent with however you're doing your inline comments if you only do one white space that's fine but just make sure you always only do one white space all right so the next convention i have for you is a quick one but this has to do with checking if a value is none so a lot of times what people will do to check if some variable is none is they'll do the following if x like that now this is fine this will actually tell you if x is equal to none but it will also tell you if x is false so this is why you want to be explicit if you're checking if a variable is equal to none because if i do something like x equals false this if statement will still trigger if i do something like x equals zero it will still trigger if i do something like x is equal to an empty string this will still trigger and so if you only want to check if the value of x is equal to none then you should say if x is none like that now it's important that you do is none and not double equals none this is just another rule you want to make sure you're never checking if something is equal to none using double equal signs you want to use is so that's kind of the only rule here when you're checking equivalence with none be explicit and use is none as opposed to double equals none alright so the next convention here is pretty simple but if you are trying to check if the value of something is not something then you want to use is not not not is now this is not specific to checking the value none you could check you know let's just say like x this would be the exact same thing and let me just make sure i use the same quotation marks here you want to make sure using is not not not is now these will actually give you the exact same result it's just the convention to use is not now the reason i'm saying that it'll give you the same result even though it looks like it won't is because the not is going to be applied to foo is x not tofu so it's not going to negate foo and then check not foo is x so it won't do this what it will actually do is this okay so it is the same result but you just want to make sure you're using is not alright so the next convention here is really simple has to do with a try and accept block and really the only thing you need to know here is you should always accept a specific exception a lot of people don't do this i don't do this all the time in fact all of the rules i've said here i've broken at some point in time but you always want to make sure you're accepting a specific exception not doing an empty accept block like this there's a bunch of different reasons why that's the case i won't really get into them but just make sure you're almost always accepting a specific exception and if you need to accept multiple specific exceptions then do another except like this don't just do an empty except block like that all right so this is actually our last convention or rule right here and this is if you were trying to check if a string starts with or ends with something you should use the dot starts with or dot ends with as opposed using a string slice so these are just better these are apparently supposed to be more accurate and more performant than using a slice and so that's the reason why you're supposed to use them this is weird i didn't know about this at all this is one of the main things i was like whoa okay that's interesting i hadn't heard that before so just check or not check use starts with or ends with as opposed to using a string slice when you want to check the prefix or suffix of a string so with that said that's pretty much going to wrap up this video again i only covered a small subset of the pep8 guideline just wanted to go through what i thought was kind of the most interesting most important and commonly mistaken stuff in python hopefully you guys found some value from this video if you did make sure to leave a like subscribe to the channel and i will see you in another one [Music] you