Demonstrating Practical Advice

00:00 You’re probably wondering how this poem can help you with your Python code. In this lesson, I’ll show you several examples of practical advice from the poem which you can start applying immediately,

00:12 starting with “Beautiful is better than ugly”. To be able to start applying this to your code, it would be helpful to have a definition of what might be meant by the word “beautiful” when referring to code.

00:23 Raymond Hettinger provides some insight with this phrase from one of his talks: “Pythonic means coding beautifully in harmony with the language to get the maximum benefits from Python.”

00:36 So beautiful code leverages the language to maximal effect.

00:40 Here’s an example of a simple program which calculates the sum of the first ten square numbers. An empty list is created, called results, then a for loop iterates over the numbers 1 to 10.

00:53 Each number is squared and added to the results list. Finally, the sum() function is used to calculate the sum of the list. While this code does what it sets out to do, how can it be coded, as Raymond Hettinger would say, in harmony with the language?

01:10 The answer is to use a generator expression inside the sum() function.

01:15 Generator expressions, and the similar list comprehensions, allow some for loops to be compressed onto one line. In this code, the numbers 1 to 10 are still iterated over, their squares are calculated and Python automatically keeps track of them, the sum of these values can still be calculated in the same way.

01:34 This final code is simpler and uses the language much more effectively and is therefore more beautiful.

01:41 The next piece of practical advice is, “Explicit is better than implicit”. To understand what this line is suggesting, take a look at the following example.

01:52 A color is defined as a tuple of three integers, the first value of that tuple is then accessed. The code works perfectly, but it’s unclear what the first value of the color tuple represents.

02:03 In fact, what do any of the values represent? Does that tuple store hue, saturation, and luminosity? Or red, green, and blue values? Or perhaps another system of storing color?

02:13 The code is currently implicit. To make the code explicit, you can use the namedtuple from the collections library. Then you can create a Color type by providing names for the three values, in this case clarifying that you are storing red, green, and blue values.

02:30 Now it’s much clearer what those values represent, and it’s easy to access individual values, for example, my_color.red. This code is slightly more verbose, but it’s much more explicit.

02:45 The next piece of advice turns its attention to structure. Flat is better than nested. Here is an example of a nested piece of code. Inside the edit_important_document() function, three things are checked.

03:00 If the file exists, if the user is an admin, and if the document is editable. However, the deeper the nesting, the harder the code is to read, not to mention the harder it is to puzzle out the logic of the function.

03:13 This is only exacerbated by else clauses in bigger functions. Here is an alternative version of that function. The three checks remain, but are now flattened.

03:24 This is accomplished by inverting the question. Instead of checking if the file does exist, the function checks if it doesn’t exist, and if so, just exits early.

03:34 This is easier to read, and makes it trivial to add a new check or change a current one. Choosing flat over nested has improved the code.

03:44 Similarly, in regards to structure, the next piece of advice states, “Sparse is better than dense”.

03:51 Python being such an incredible language, it is often possible to get lots done on a single line. For example, this monster of a function which supposedly checks if a list of candidates contains any anagrams of a given word.

04:04 Unfortunately, the line is so long it isn’t readable and is difficult to edit. It is dense.

04:10 A sparser version of this program would involve removing the anagram checking code into a separate function, called is_anagram().

04:18 Now, the original function is much clearer, and almost reads like English. It’s worth remembering that just because something can be done in a small number of lines, doesn’t mean it should.

04:29 The last piece of advice to explore in this lesson is, “Readability counts”.

04:35 Code is read far more than it is written, and so your code should be as readable as possible to help future you and your colleagues.

04:43 This is a function call that draws a rectangle. It has been passed many parameters. Unfortunately, it is unclear what those parameters do. Which one of these numbers should a developer change to move the rectangle?

04:56 The readability of this program can be improved by being more explicit. By providing keyword arguments, the purpose of each value is clear and easy to update.

05:06 Keyword arguments aren’t always required, but can passively boost the readability of your code, especially when a lot of parameters are being passed.

05:15 Hopefully those pieces of advice can already help you with your code and point you in the direction of more readable, maintainable, and even beautiful code.

05:22 That said, the poem does contain some phrases that seem to contradict each other, which makes the advice harder to follow. These contradictions will be explored in the next lesson.