Style Guide

Repetition

In general, don't repeat yourself (DRY). It wastes space and can be computationally inefficient.

Complex expressions

Do not repeat complex expressions:

if a + b - 3 * h / 2 % 47 == 4:
    total += a + b - 3 * h / 2 % 47
    return total

Instead, store the expression in a variable:

turn_score = a + b - 3 * h / 2 % 47
if turn_score == 4:
    total += turn_score
    return total

This will also make your code more readable.

Computation-heavy function calls

Don't repeat computationally-heavy function calls:

if takes_one_minute_to_run(x) != ():
    first = takes_one_minute_to_run(x)[0]
    second = takes_one_minute_to_run(x)[1]
    third = takes_one_minute_to_run(x)[2]

Instead, store the expression in a variable:

result = takes_one_minute_to_run(x)
if result != ():
    first = result[0]
    second = result[1]
    third = result[2]

if/else conditions

DON'T have the same code in both the if and the else clause of a conditional:

if pred:            # bad!
    print('stuff')
    x += 1
    return x
else:
    x += 1
    return x

Instead, pull the line(s) out of the conditional:

if pred:            # good!
    print('stuff')
x += 1
return x

Comments

Recall that Python comments begin with the # sign. Keep in mind that the triple-quotes are technically strings, not comments. Comments can be helpful for explaining ambiguous code, but there are some guidelines for when to use them.

Docstrings

: Put docstrings only at the top of functions. Docstrings are denoted by triple-quotes at the beginning of a function or class:

def average(fn, samples):
    """Calls a 0-argument function SAMPLES times, and takes
    the average of the outcome.
    """

You should not put docstrings in the middle of the function — only put them at the beginning.

Remove commented-out code

Remove commented-out code from final version. You can comment lines out when you are debugging. When you are turning in your project, take all commented lines out (including TODOs) — this makes it easier for readers to read your code.

Unnecessary comments

Don't write unnecessary comments. For example, the following is bad:

def example(y):
    x += 1            # increments x by 1
    return square(x)  # returns the square of x

Your actual code should be self-documenting — try to make it as obvious as possible what you are doing without resorting to comments. Only use comments if something is not obvious or needs to be explicitly emphasized

Control Structures

Boolean comparisons

Don't compare a boolean variable to True or False:

if pred == True:   # bad!
    ...
if pred == False:  # bad!
    ...

Instead, do this:

if pred:           # good!
    ...
if not pred:       # good!
    ...

Redundant if/else

Don't do this:

if pred:            # bad!
    return True
else:
    return False

Instead, do this:

return pred         # good!

Similar if/else suites

(related to the previous:) Don't do this:

if num != 49:
    total += example(4, 5, True)
else:
    total += example(4, 5, False)

In the example above, the only thing that changes between the conditionals is the boolean at the end. Instead, do this:

total += example(4, 5, num != 49)

while vs. if

Don't use a while loop when you should use an if:

while pred:
    x += 1
    return x

Instead, use an if

if pred:
    x += 1
    return x

Parentheses

: Don't use parentheses with conditional statements:

if (x == 4):
    ...
elif (x == 5):
    ...
while (x < 10):
    ...

Parentheses are not necessary in Python conditionals (they are in other languages though).

Miscellaneous

Semicolons

: Do not use semicolons. This is not C/C++/Java/etc.

Checking None

: Use is and is not for None, not == and !=.

Implicit False

: Use the "implicit" False value when possible. Examples include empty containers like [], (), {}, set().

if lst:       # if lst is not empty
    ...
if not tup:   # if tup is empty
    ...

Generator expressions

: Generator expressions are okay for simple expressions. This includes list comprehensions, dictionary comprehensions, set comprehensions, etc. Generator expressions are neat ways to concisely create lists. Simple ones are fine:

ex = [x*x for x in range(10)]
L = [pair[0] + pair[1]
     for pair in pairs
     if len(pair) == 2]

However, complex generator expressions are very hard to read, even illegible. As such, do not use generator expressions for complex expressions.

L = [x + y + z for x in nums if x > 10 for y in nums2 for z in nums3 if y > z]

Use your best judgement.