# Reviewer Checklist¶

• The code must be readable without extra effort from your part. The code should be easily readable (for infos e.g. here)

• Include references to the used algorithms in the docstring

• If the algorithm is new, please include a description in the docstring, or be sure to include a reference as soon as you publish the work

• Variable names should be chosen to be clear. Avoid item, element, var, list, data etc… A good variable name makes it immediately clear what it contains.

• Avoid as much as possible hard-coded indices for list (no x = l[0], y = l[1]). Rather, use tuple unpacking (see here). Note that tuple unpacking can also be used to update variables. For example, the Fibonacci sequence next number pair can be written as n1, n2 = n2, n1+n2.

• Do not use mutable (lists, dictionaries, …) as default values for functions and methods. Do not write: def function(default=[]):

but use def function(default=None):      if default is None: default=[]

• Use pythonic loops, list comprehensions

• Make sure the unit tests are testing all the lines of the code. Do not only check for working cases, but also the most common wrong use cases.

• Check the docstrings (Do they follow the Numpydoc conventions, is everything clearly explained, are the default values given and is it clear why they are set to this value)

• Keep the code simple. Avoid using complex Python functionalities whose use is opaque to non-expert developers unless necessary. For example, the @staticmethod decorator should only be used if really necessary. Another example, for counting the dictionary colors = ['red', 'green', 'red', 'blue', 'green', 'red'], version:

d = {}
for color in colors:
d[color] = d.get(color, 0) + 1


is perfectly fine, no need to complicate it to a maybe more pythonic version d = collections.defaultdict(int)  for color in colors:      d[color] += 1

• Did the code writer perform a static code analysis? Does the code respect Pep8 (see also the pylint config file)?

• Did the code writer perform a profiling and checked that there are no obviously inefficient (computation time-wise and memory-wise) parts in the code?