Lesson 16. Python Programming Standards
I’m a pretty chill person. It’s hard to harsh my mellow. One thing that does send me into a blinding rage is poorly formatted hard to read code.
Software engineers don’t just work in teams simultaneously. They also work as a relay team. Engineers come and go, but the code base of an organization may be around for decades.
When an engineer moves on, somebody will be brought in to replace that person. That person is going to have to pick up where the last engineer left off. Once you start working as a software engineer, you will discover very quickly that trying to read other people’s code is a special kind of hell rivaled only by you trying to read your own code from a few days ago.
Getting everybody on the same page in terms of how to write code helps with this problem. If you work at a large enough organization, they might have a coding style guide that you will be expected to adhere to. The style guide will tell you how to name things and how your code should look. It may seem trivial but having a document and code review processes that demand things like having x number of spaces between lines of code can be the difference between being appropriately productive and mad chaos.
Corporate style guides are great, but they are specific to that organization. Python has a style guide built into its interpreter that ensures there is something of a universal standard in how your code looks.
As a new person, the main things you need to be concerned about is spaces between code blocks and indenting.
If you are using JuypterLab, space between code blocks will not be that big a deal. If you are using PyCharm to develop with, PyCharm will bark at you if you have more than 2 lines of white space between code blocks.
Indenting is another matter. The number of lines of space between code isn’t a deal breaker. Improperly indented code will blow your script.
Indenting is how the interpreter figures out what belongs to what. For example, take a look at this while code.
while i < 10:
i += 1
See how line 2 and 3 are tabbed over? That tells the interpreter that line 2 and 3 belong to that while loop. Let’s look at an example of something that is nested for more clarity.
i = 2
upward_bound = 50
print('Here are all prime numbers between 2 and ' + str(upward_bound))
while i <= upward_bound:
x = i - 1
if i == 2:
i += 1
while i > x > 1:
#print('x = ' + str(x))
if i % x == 0:
elif x == 2:
x -= 1
i += 1
Here is our old friend the prime number finder again. This is a good example that illustrates how indenting defines what executes when.
Lines 7 – 22 all belong to the while loop defined at line 6.
Lines 13 – 21 all belong to the else portion of the if else statement.
Lines 14 – 21 are what get looped over defined by the while at line 13 while the else portion of the if else statement is executing.
If you took line 22 and tabbed it over one more, it would break the script. It would still run, but it would not work properly because i would not get incremented when it was supposed to. Go ahead and move line 22 over one and run it to see what happens.
Universal Style Guide
PEP8 is basically the bible on how to write good Python code. You should spend a few hours studying this document so you can get the basic techniques memorized so you will not have to constantly reference it as you’re jamming out writing code. If you’re in the flow, you certainly don’t want to have to stop to look something up.
On Being Pythonic
Python isn’t just a programming language. It’s a way of life bro. I’m not even going to TRY to explain what being Pythonic is all about. Imma just let my boy Tim Peters explain it.
Don't copy and past. Type the code yourself!