Readability

00:00 Quality code is readable, meaning another developer (or future you) can look at it and quickly understand the logic and purpose.

00:10 Look at this function, for example: you have a function called f, it takes three parameters a, b, and c, and then it does something to them and gives you a calculation of some sort.

00:23 Okay, but what are a, b, and c? And what is this function even accomplishing? You can’t really tell, can you? You’d have to give it to an LLM, or you can try to understand it from the surrounding context. So, is this a readability issue?

00:39 Yes it is, it is a readability issue. So what can you do? You can use descriptive argument names and docstrings to solve this issue, as you can see here. That docstring alone tells you what the function is accomplishing.

00:57 It calculates the final price of an item after applying a discount and tax. And then you can clearly see that a, b, and c from before were actually base_price, discount_percent, and tax_percent.

01:09 Okay, so using descriptive argument names and docstrings solve a lot of your issues. But then you have to pay attention to something else. It’s very important to remember that code that doesn’t follow PEP 8 may look very unusual and be harder to read for experienced Python developers.

01:29 PEP 8 is Python’s official style guide for writing clean, readable, and consistent Python code. You can check it out at Python’s official website.

01:38 Okay, so what does that mean? Let’s see an example. You have two functions that do exactly the same thing. They take in two numbers, and then they return their sum.

01:49 But the first function is quite different from the second one. At least it looks quite different from the second one. The first function violates a few readability rules from PEP 8.

01:58 For example, look at the function name. Function names should use snake case, not camel case. Camel case is used for classes. And with the input variables that the function is getting, x and y, there should be a space after the comma.

02:15 So it should be x comma space y. Also, the function body should usually go on a new indented line, so after colon, you should have a new indented line.

02:26 And with the return statement, you have x plus y, but binary operators should have space around them. So it should be x space plus space y.

02:37 You can see that the second function looks a lot more clean. Now you know that quality code is readable, meaning another developer or future you can look at it and right off the bat understand the logic and purpose. Next up, you have efficiency.