Python Coding Conventions You Really Should Follow

[Music] what is going on guys welcome back in today's video i'm going to talk about python coding conventions that you should follow to make your code more professional more beautiful and more readable so let's get right into it now before we get into the actual tutorial i would like to mention that this video was sponsored by oxylabs and as always don't skip this part because i never promote something unless i think it's useful and interesting to my audience and oxy labs offers something very interesting for those of you who are interested in web scraping and gathering large amounts of data on the internet they offer proxy servers professional proxy servers that can save you a lot of hours of dealing with technical issues with networking issues if you've ever done web scraping in the past large scale web scraping you probably noticed that you have constantly some ip blocking some captchas some servers being down and so on you can solve these problems with oxy labs because they offer you reliable servers ip addresses that are legit that are actually registered by isps or at isps for real users so they're not suspicious you can use them without having to constantly prove that you're a human and so on so you can actually focus on the work uh that you want to do on the web scraping on the data signs whatever you're web scraping for you can focus on that uh they have a success rate of average 99.2 percent and the residential proxies uh offer as i said 100 million plus legit ips from 195 countries you can also take a look at the quick start you can use this with curl with a command line tool on linux on windows you can use it for php and probably most interesting for you guys you can use it with python as well you can you can look at the tutorial here to see how it's done you can specify a server you can also specify the country the city you can do all this manually and these are legitimate ip addresses reliable service the company is very reliable if you go to reddit and you look for uh best proxy servers that you can use for web scraping you're going to see oxy labs maybe with one or two competitors but they're actually at the top of this business uh you can see java c-sharp ruby and so on a very interesting company very interesting products and if you are into large-scale data gathering on the web if you are into large-scale web scraping this is definitely worth a try worth a look they have a free trial and for this video specifically you have a link in description down below with a coupon code with a neural nine coupon code that you can use to check their products out so take a look i think it's very interesting so the conventions and styling guidelines that i present to you in this video are taken from the pep 8 style guide for python code you could say that this is the central thing that developers agree on the central resource that you want to look at if you want to make your python code more readable and more professional now of course some companies like google have their own styling guidelines which makes sense if you have a big team of developers on different projects working on different projects you want to have your own custom guidelines but in general the pep 8 is what you want to follow if you want to make your code more readable now before we get into the actual individual points here i want to talk about some general guidelines and the first thing you need to get into your mind into your head is that the primary goal here the north star is readability you want to make your code more readable you don't want to make it fancy you don't want to follow some rules foolishly you don't want to have foolish consistency you want to make your code more readable which means that if in your project certain guidelines lead to less readability you ignore those if breaking the rules one or two times leads to more readability you do it you just want to make your code as professional and as readable as possible you don't want to make a religion out of following these guidelines here they have the goal of making your code more professional and more readable if they don't do that you don't follow them it's as simple as that um also all these guidelines here are just styling guidelines so nothing is going to improve about your code in general so you're not going to have more functionality or more efficiency or anything like that it's just going to make it easier for developers including yourself to understand the code and to refactor the code and to read the code it's not going to change anything about the program itself and one thing that you might want to follow here is you can go into your python idle and just type import this this is the zen of python those are just some general soft guidelines not nothing specific nothing like line length or characters to use just some basic guidelines like beautiful is better than ugly explicit is better than implicit simple is better than complex and so on because oftentimes we have these lead coders that have like the perfect line of code one line of code that does a thousand things but no one can understand it that is not good code this might help you in some coding competitions when it's about writing the shortest code possible but it's not going to help you in actual programming you want to keep things simple and readable not fancy and lead coder like alright so let us get right into the first big category of guidelines related to aesthetics and layout and we're going to start with some very basic stuff first the tab width or tabs in general the guideline recommends to have a tap width to use a tab with off4 which means that you don't want to use two you don't want to use eight the guideline says use four and it also says that spaces are preferred over tap so i'm not sure if my editor if pycharm here does it actually but it says that it's better to use one two three four spaces than one tab character i think actually pycharm uses uh tabs in this case um but this is one thing that you might want to change because spaces are actually um more concrete they're not ambiguous tabs can be four characters long two characters long and so on so spaces are concrete you have four spaces and this means the code is indented so it's recommended to use spaces over tabs another thing is you wanna keep track of the maximum line length so recommended maximum line length is 79 characters why because usually that's the kind of length that you can use if you have a normal default font size which is not the case for me right now because i'm recording but if you have 79 characters in the line you can use split view without causing the text to wrap so without causing line wrapping you can have two um two buffers open with code and 79 characters is usually what you have what is acceptable here to have the maximum line length of course you can also choose a different maximum line length for your company if you have a team of developers it's important to have a convention because then you can know that if this is the maximum line length i can have two windows side by side without causing line wrapping and for long blocks of text for example for multi-line comments that are large you want to have 72 as a recommended guideline here now this is interesting here we have seen this in my tutorials quite often you want to have when you define a class for example when you define class my class it's the convention that you have two blank lines above that um and i think also below that and also the same goes for um top level functions so let me show you here if i have i don't know my function inside of the class here the convention says i'm going to just pass for now the convention says that if you have functions inside of a class you want to separate them by by one blank line so if i have my function 2 here and i pass here as well this is fine you you don't want to have two blank lines in here as you can see if i hover here now it says pep8 which is the guideline that we talked about too many blank lines this should not be the case so also if i have something else here for example i say a equals 10 then i'm going to have the problem here pep8 expected two blank lines found one this is not according to the convention if i add an additional blank line here everything is fine again also as far as i know this is also true for comments so if i have a comment here no in this case it's not but i think the difference is if i have a equals 10 here yeah then it's a problem because i don't have two blank lines i have a statement then the comments are ignored and i have one blank line so you want to have two blank lines when you define a class or when you define a top level function so if i say here special [Music] and then i pass you want to have two blank lines before that as well now inside of the class as i already said you want to have only one blank line between the functions however the guideline says that it's allowed to use extra blank lines sparingly so not too often to separate certain categories of functions so if you have for example a huge class with 100 functions and then you have like 15 mathematical functions 15 string processing functions uh 15 graphical processing functions whatever reason you have these functions you can use an extra blank line so if you have these two functions here for example then two blank lines to uh start a new block of functions this is allowed this is recommended but don't do it too often and also what's also useful is if you have a function inside of that function you want to have um the statements separated by blank lines into logical uh uh into logical sections so for example if we're working with sockens sockets we might want to have a section where we initialize the socket we bind to socket we start listening then we want to have a separate section for accepting a connection handling a connection and then you want to have a separate section that closes the connection cleans up the resources and so on and these sections we can call them section one here oh we're in python section one then you have section two and so on these sections should be separated by blank lines because they have logical a logical reason to be separated so that's it for the blank lines and classes and functions now another thing is no unnecessary white spaces i think this is something that's quite intuitive um you don't want to have white spaces when there's no reason to have them i don't know for example if i have my list is some array here some list one two three four um it doesn't make a lot of sense to call a function i know my function onto that list and then i say my list and then space here again um space here one space and maybe pass something else here these blank lines here uh these these white spaces here they don't make sense and as you can see here pep 8 says white space after a opening opening bracket doesn't make a lot of sense in here as well it doesn't make sense to use white spaces in this case what does make sense is and i think it's even yeah as you can see here here i should have white spaces if i have one two three four this is recommended to have white spaces here it depends on the context if you want to know all the details i recommend reading the guidelines or just using something like pycharm that tells you if you violate the convention what is acceptable here for example is if you use a slicing operator so if you have something like my list it is okay to slice so if you have like slice and then i don't know some some function that returns something some number and then slice again some other number and so on this is fine usually um but again if you want to know all the details you want to read the guideline the pep 8 guideline uh but in general don't use spaces unnecessarily so if you have certain i don't know if you just call a function there's no reason to add surrounding uh white spaces for no reason but i think this is quite intuitive you don't do do that unnecessarily now you also want to have between operators um did i actually oh there you go between operators you want to have white spaces but you don't want to have them um you don't want to have white spaces if you have certain priorities so for example if i have the calculation c equals 10 plus 20 plus 30 there should be spaces i should not do it like that this is not conventional i'm not sure if it's going to underline it here no it doesn't say anything but this is actually not according to the convention what is according to the convention however is if i have certain blocks so for example if i say c equals and then i have x to the power of 2 plus y to the power of 3 and so on this is conventional it's even recommended then to group these together without white spaces and to only add the white spaces here so this is also a conventional thing to follow um then also if you have a function this is important uh if you have a function def my function and you have some parameter here some keyword parameter maybe you have x y and then you have some other thing and this some other thing has a certain default value when you just when you assign a default value you want to use a white space here so you want to have this being none for example this is conventional to do it like that let's just pass for now but when you call the function so when i call my function for example and i enter 10 20 when i now assign some other thing manually like that as a keyword argument then we don't use white spaces so if i say 10 here for example you don't want to use white spaces now i think we have some other problem here yeah we need two blank lines but this here is also against the guideline as you can see unexpected spaces around keyword parameter equals this is not recommended um then we have two more things if you define a tuple with one element so if i say my tuple equals now if i have multiple elements it's easy i just do that of course with spaces but if i have just one element i don't do it like that i do it like that this is the recommended way to assign a one value tuple and last but not least the files you use should have the encoding utf-8 so utf-8 alright so let's move on to the next category the import guidelines and this is actually something that i think is quite interesting because i often times ask myself in the past how do i properly import stuff how do i do this professionally because you don't want to mix everything up you want to have a certain structure in order and the guidelines have a section on that as well so first of all a no-brainer don't import multiple modules in the same line it just it just doesn't look good so if you want to import for example the math module the os module and the sys module you don't want to do it like that you don't want to say import math os and cis this is not recommended you don't want to do that what you want to do is you want to import them in separate lines so you want to say import math import os import sys this is how you want to do it also if you have the same module you want to do it in the same line so if you say for example from sklearn dot pre-processing if i want to import something from pre-processing i don't start a new line for each thing i import so for example what do we have um standard scalar for example if i want to import the standard scalar and i also want to import something else like the min max scaler i'm going to do it like that in one line of code i'm not going to say from sklearn preprocessing import standard scalar and then again in the next line from sklearn dot pre-processing import min max scalar and so on this doesn't make a lot of sense it's the same module however if i say from sklearn i mean this is obviously something i need to do but if i do model selection for example then i start a new line but i import everything in the same line so from model selection i say for example train test split uh maybe grid search cv and so on i do all of this in the same line and one important thing we want to avoid wild card imports what are wildcard imports this is something like from sklearn.preprocessing.preprocessing import everything because this then imports everything of course which is you know pleasant because i can just then use everything without specifying that i want to use it but the problem is that it makes unclear which names are present in the namespace and sometimes this is problematic because in pillow for example we have an image then we also have an image in cv2 we have an image in tk inter i'm not sure where we have an image but you don't know what's important now and maybe you don't even need the image from a certain library but you have imported or you imported it because you did a wild card import so you want to avoid those and the last thing that is actually quite interesting is the order of the code how you write it now if you write professional code what you usually do is you start with docstring so you say something like author equals uh whatever you are so i actually think i should have here somewhere uh the vid stream module where i actually did it not perfectly but you can at least see the docs string so you can see here i have a dark string with um this module implements the main functionality of bitstream author floor and data from neural nine and so on youtube channel and all that then these uh variables representing my contacts and and all that contact information uh you wanna have this first in your in your modules in your scripts then you want to have the imports and when you do the imports you want to have three sections first of all you want to have all the imports that are from the standard library stuff like import os um import os import sys import math and so on and of course also stuff like from math import sqrt and all that whatever you want to have you have it in one section here and once you have that you start a new section separated by a blank line and you import all the third-party uh imports so for example import numpy snp import matplotlib dot pi plot splt and so on and then in case you need it you have a third section with your local implementation so for example um as you can see in bitstream i have too fast if in the streaming file i want to use the audio.py what i do is i have to import it as well so i can say import audio whatever so i have to import my own things my own local implementations last here i have the third party modules and here i have the core python modules this is important after that we have the globals and constants but this is important when it comes to the imports now the third category is about commenting guidelines how do we write proper comments and i want to mention right away that all this here is not proper commenting this is just those are just notes for this video here they're violating the guidelines this is just for me right now for making this video um but one major thing that you want to keep in mind when you're working with comments is you always want to keep them up to date i think this is a no-brainer this is obvious but you never want your comments to contradict your code you always want to have them up to date because oftentimes we change the code real quick we add something we remove something we change something but we don't update the comments and this is really really bad because when someone looks at the code they're going to see a comment that says this code does xyz but the code does abc and it's not good you don't want to have that you always want to keep your comments up to date also less intuitive you want to comment in complete sentences so when you write comments you want to have complete sentences with a capitalized beginning now important when we say capitalized beginning we don't want to alter the case of identifier so for example if i have something like def my function and i don't know i have a parameter param um and this function does something if i write some comment here i don't know uh param das xyz it's important that i don't capitalize param because param is an identifier it has this name i'm not going to change the p to an uppercase p if we refer to certain keywords function names class names uh parameter names whatever we want to keep the case but otherwise you want to use full sentences and you want to use um a capitalized beginning now when it comes to blog comments we want to have one or more paragraphs of full sentences and important when you write comments always write them in english unless you're 100 sure that the people you're working with are the only people that will ever see this code you're never going to use it for anything else it's only going to be used by five german speakers or five french speakers then write in your language if you want to but always use english because you're going to need this to be compatible also in general in computer science english is the language i'm also not a native speaker my native language is german but still i always use english because english is the language of the internet and the language of computer science when you are a computer scientist english is a must-have skill it doesn't matter which language you're born in uh born with you should know english and you should use english when commenting when naming your functions and so on doesn't mean that your messages your error messages and so on can't be in your language but the code should be written in english and also the comments obviously um now inline comments are a thing that should be used sparingly according to the guidelines you should not use inline comments too much what are inline comments when you have my function here and i have this pass statement here and i have this inline comment this does nothing for example first of all you don't want to use them too often second of all you want to use two spaces at least this is the convention you want to use two spaces in between uh the statement and the comment i don't know why i don't think this is intuitive but yeah the guideline says this is how you do it and also i saw that python or pycharm tells me pep8 at least two spaces before inline comment uh and i think this is also important don't state the obvious don't write comments that are unnecessary for example this year pass this does nothing okay we know it does nothing or if i have something like x equals y to the power of 2 and then my comment is square y and save it to x this is stupid right you don't want to do this but of course if there's a reason to write an inline comment like this statement trigger something that is not obvious to the reader to the user to the coder then you might want to use inline comments to just mention okay this function has something that you don't see right away and i want to mention this here so next up we have the dog string conventions and for this we actually have an own set of uh guidelines which is the pep257 the docstring conventions here if you want to read into that feel free to do so in this video i'm only going to mention the most important stuff you want to document uh you want to write documentation for all public modules functions methods uh classes and so on and the comments should come after the def keyword so if i have a function def my function uh the the documentation string should come after this so i don't want to document like in java where you have javadocs you would do it up here no you want to do it after the function definition so in here you want to have a docs string you can see that it already automatically generates the format in pycharm so if i have x and y and then i use this you can see i have param return and this is the convention that you have it have it after the def keyword and the three quotation marks at the end um should not be on the same line unless it's a one-liner but here we want to have the same line so my function does something so here we want to start in the same line here we don't want to do this so this is always on a separate line and that's all i want to mention here for the docs string conventions because that is that could be a whole video in and of itself how to write proper documentation actually i have a video on docstrings already you might want to check that out but this is the basic thing you want to document everything that's public and you want to do it like that you want to do it after the def keyword here you want to have in the same line uh the start and this is on a separate line this is how you write dog strings all right so now we get into something that is interesting and very important naming conventions how do we properly name variables functions classes modules packages and so on it's very important to follow these guidelines because if you don't follow these guidelines people are going to notice right away that you're not very experienced as a python programmer or that you're just ignorant both is not good you want to follow these guidelines because if you start using camel case for your functions people are going to notice that you're really not a good programmer and you probably are not if you're doing it unless you have a certain reason to do that of course but let's start with a very basic uh simple principle first you don't want to use function names that are indistinguishable from numbers like zero and one so for example uppercase i lowercase l or uppercase o are letters that are oftentimes indistinguishable from one and zero in my font that i'm using here it's not the case because if i type 0 you can see that there's a dot and 0 there's not a dot in o but in some fonts this is not the case and some fonts these things are indistinguishable and it's just about a bad practice to use these names so just avoid them where you can now let's get to the actual naming conventions when we talk about modules like vidstream for example you want to use or actually modules are something like pre-processing from sklearn and sklearn is the package so in both cases you want to use lowercase short names with modules you can also use underscores if it improves the readability so if you have a very long module name you might want to use underscores in packages so bitstream for example you don't want to use underscores it's not recommended to do so it's better to just pick in an all lowercase short name for the modules if necessary if it improves readability also use underscores so if we have for example i don't know my new package this could be your package name and from my new package dot i don't know special math tools this could be a module that you use in order to import something so this is fine but in the package name itself you should not have underscores this is discouraged at least now classes should go with camel case or cap words um basically meaning that if you have for example inside of your package a class you want to call it my new class like that you don't want to call it my new class in mixed case so you don't want to have a lowercase m in the beginning you don't want to have in general lowercase or all uppercase you want to have this camel case where you start with a capital character and the individual words here are always started with uh with an uppercase character so this is the convention for classes so if you have a package module and a class name which you want to use you want to say from my package dot special math module for example import math calculator for example this is how it would look like if you follow the conventions um so for type names this is a thing that i haven't talked about on this channel so i'm not going to talk about it too much now but if you have types that you define so you can say something like um if you define types you want to also have this suffix with a code for covariant or contra for contra variant so you have this type var again i'm not going to talk about this too much but when you define a type bar you can define a certain name and you can set covariant to true or contravariant to true and then you also want to have this suffix in the end to indicate that this is the case just if you know what this is just use this otherwise i'm going to make a video maybe on it in the future exceptions are actually like classes because exceptions are classes but you want to add a suffix error so you can say for example my new math error for example you want to end this with error if it is an error but essentially the naming convention is the same as with classes now functions and variables should all be underscore should all be lowercase separated by underscores so if i have uh the function i don't know def iterative fibonacci solution this is how i should do it i should not go with mixed case or camel case unless of course uh the style is already present in the project obviously this is always the case if you are in an ecosystem where there are other conventions you need to follow those obviously but you don't want to do something like fibonacci iterative or something like that you don't want to do this because that is not the python convention in python we use lowercase with underscores for variables and for functions now when you have a class my class and you have some function in there my function you want to use self if it is a um an instance method so if it is something related to the actual object and you want to use cls if it's uh for the class so this is just a convention here also this is very important this is something that that i didn't do if an argument name clashes with certain reserved keywords so if you want to pass something like class for example but class is already a python keyword or maybe if or for or wow then it is better to go with a trailing underscore instead of abbreviations so class underscore is a better name than clss for example this is just more readable you should go with that if you have to use something it's better to avoid it in the first place but if you have to use class go with class underscore also private and protected resources should be indicated with underscore and double underscore in classes so if i have again class my class and in the init function here i want to have a certain variable i can say okay my name equals whatever so this is a private attribute and so on you can look at vidstream i i do it there as well so you want to just indicate that this is actually also important for the ide because it's going to notice that certain things are protected and others not and obviously i think this is the same for all languages java c c plus c sharp python constants are in all capital letters in python separated by underscores so if i have for example uh pi equals 3.141 and so on this is a constant or my port or we can say port underscore number is four nines for example this is how you define constants in python all right and last but not least we're going to talk about some general programming recommendations just two of them that i want to mention here because one thing that beginners oftentimes do is they have a boolean for example i don't know condition and this condition is somehow calculated and it's then true or false so let's say it's true what they oftentimes do is they say okay if condition equals true then do something right first of all you can see here right away that um pycharm says this is not efficient this can be replaced by condition so you can just say if condition why because an if statement needs a boolean you don't need to compare it to a boolean because it's already a boolean so if the condition is true you can just say if condition also same goes for a function that returns a boolean if you have a function my function and this function does some calculations and it then has some result and this result is true you don't have to say if result equals true or if result then return true you can just say return result and this is fine as well just some basic stuff here and another thing the last thing i want to talk about today is if you want to compare if you want to see if something is none or not um you can do it in multiple ways when it comes to the functionality it doesn't really change but it's not a best practice to do it like that if you have some x and x is equal to none you don't want to check by saying if x is not none this is not good because what happens here is you ask if the variable x is the negation of none you don't want to do that this is a bad practice what you want to do is you want to check if not if it's not true that x is none this is just what you want to do here so just a basic tip on the side and that's it for the python coding conventions this is how you can write more professional and more readable code in python so that's it for today's video hope you enjoyed hope you learned something if so let me know by hitting a like button and leaving a comment in the comment section down below also don't forget to check out the link in the description down below and the coupon code of the sponsor of today's video labs and as always hit the subscribe button hit the notification bell to not miss a single future video for free other than that thank you much for watching see you next video and bye [Music] you

Channel: NeuralNine

Views: 19,847

Keywords: python coding guidelines, python guidelines, python pep8, python pep8 guidelines, python best practices, python conventions, python coding conventions, python coding best practices, python tips and tricks, python pep8 conventions, python pylint conventions, python conventions names, python cases

Id: U2vDWc5sce0

Length: 34min 31sec (2071 seconds)

Published: Sun Jan 09 2022