Good practices, programming style and conventions

Good practices, programming style and conventions#

Python is a very versatile programming language, and it has a very flexible syntax. Therefore, it is also very easy to write ugly code in python. This chapter reviews a number of guidelines and conventions widely accepted by the community. At this stage of the lecture we will not go into each of these points in depth, but try to keep them in mind while writing your assignments.

Use PEP 8#

PEP 8 is a style guide for python code. It introduces new rules where the syntax leaves them open. As an example:

# Syntax OK but not PEP8 compliant 
x=2+1
x= x * 2-1
# Syntax OK *and* PEP8 compliant
x = 2 + 1
x = x * 2 - 1

PEP8 gives guidelines, not strict rules. It is your choice to comply with them or not. As a matter of fact, however, many open source projects have adopted PEP8 and require to use it if you want to contribute. If you want to use it too, a good choice is to turn on PEP8 checking in your favorite IDE (in Spyder: Tools -> Preferences -> Completion and linting -> Code style -> Tick Enable code style linting for PEP8 style analysis).

Give meaningful names to variables and functions#

The text space that code is taking up is less important than your time. Give meaningful names to your variables and functions, even if it makes them quite long! For example, prefer:

def fahrenheit_to_celsius(temp_fahrenheit):

to the shorter but less explicit:

def f2c(tf):

The same rule applies for variables. Prefer language over l and area over a.

Prefer writing many small functions instead of monolithic code blocks#

Separation of concerns is an important design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. This increases the code readability and facilitates unit testing (as we will see).

For example, a scientific script can often be organized in well defined steps:

  • data input (read a file)

  • data pre-processing (filtering missing data, discarding useless variables)

  • data processing (actual computation)

  • output (writing the processed data to a file for later use)

  • data visualization (producing a plot)

Each of these steps and sub-steps should be separated into different functions, maybe even into different scripts.

Document your code#

Write comments in your code, and document the functions with docstrings. We will have a full lecture about it, but it is good to start early. Here again, there are some conventions that I recommend to follow.

Note that this is useful even if you do not plan to share your code. At the very least there is one person reading your code: yourself! And it is always a good idea to be nice to yourself!

The Zen of Python#

import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Contents