{"version":"https:\/\/jsonfeed.org\/version\/1","title":"mathspp.com feed","home_page_url":"https:\/\/mathspp.com\/blog\/tags\/code-review","feed_url":"https:\/\/mathspp.com\/blog\/tags\/code-review.json","description":"Stay up-to-date with the articles on mathematics and programming that get published to mathspp.com.","author":{"name":"Rodrigo Gir\u00e3o Serr\u00e3o"},"items":[{"title":"mutability and random.shuffle","date_published":"2024-08-27T18:00:00+02:00","id":"https:\/\/mathspp.com\/blog\/mutability-and-random-shuffle","url":"https:\/\/mathspp.com\/blog\/mutability-and-random-shuffle","content_html":"

The function random.shuffle<\/code> relies on the mutability of the argument and mutability is a pain in the arse, so we propose an alternative.<\/p>\n\n

The function random.shuffle<\/code> shuffles its argument in place, which means it relies on the mutability of the argument.\nThis can introduce bugs if care is not taken.\nConsider the snippet of code that follows:<\/p>\n

def generate_maze(base_width, base_height):\n    width = 2 * base_width + 1\n    height = 2 * base_height + 1\n    # Initialize the grid with walls\n    maze = [[0 for _ in range(width)] for _ in range(height)]\n\n    DIRECTIONS = [(-1, 0), (1, 0), (0, -1), (0, 1)]\n\n    def carve_passages(x, y):\n        # Mark the current cell as part of the maze.\n        maze[y][x] = 1\n\n        random.shuffle(DIRECTIONS)\n\n        for dx, dy in DIRECTIONS:\n            nx, ny = x + 2 * dx, y + 2 * dy\n            if (\n                0 <= nx < width\n                and 0 <= ny < height\n                and maze[ny][nx] == 0\n            ):\n                # Carve through the wall between the current cell and the neighbor\n                maze[y + dy][x + dx] = 1\n                carve_passages(nx, ny)\n\n    carve_passages(\n        2 * random.randint(0, base_width), 2 * random.randint(0, base_height)\n    )\n\n    return maze<\/code><\/pre>\n
The function generate_maze<\/code> uses depth-first search to create a maze like the following, when base_width = 2<\/code> and base_height = 2<\/code>:<\/p>\n
1 1 1 0 1\n1 0 0 0 1\n1 1 1 1 1\n1 0 1 0 1\n1 0 1 0 1<\/code><\/pre>\n
The path of the maze is represented by the 1<\/code>s and the idea of the algorithm is that it will create a fully connected region, connecting all of the cells marked with an x<\/code>:<\/p>\n
x . x . x\n. . . . .\nx . x . x\n. . . . .\nx . x . x<\/code><\/pre>\n
However, from time to time, the function generate_maze<\/code> generates an incomplete maze, like this:<\/p>\n
1 1 1 0 1\n1 0 0 0 1\n1 1 1 1 1\n1 0 0 0 0\n1 0 0 0 0<\/code><\/pre>\n
Notice how the bottom-right corner has too many 0<\/code>s in a row, and in particular there are two x<\/code>s from the diagram above that were not added to the maze.<\/p>\n
After some debugging, I understood the issue: the list DIRECTIONS<\/code> was being shuffled in-place by the call to random.shuffle<\/code> and when I called carve_passages<\/code> recursively, the inner call would reshuffle the list DIRECTIONS<\/code> while the outer call was still traversing the the list DIRECTIONS<\/code>, which would introduce a bug in the loop.<\/p>\n
You can fix this by creating a copy of the list every time you want to shuffle it, but a better alternative seems to be to use the function random.sample<\/code> and set the parameter k<\/code> to the size of the list, like this:<\/p>\n
def generate_maze(base_width, base_height):\n    # ...\n\n    DIRECTIONS = [(-1, 0), (1, 0), (0, -1), (0, 1)]\n\n    def carve_passages(x, y):\n        # Mark the current cell as part of the maze.\n        maze[y][x] = 1\n\n        for dx, dy in random.sample(DIRECTIONS, 4):  #...<\/code><\/pre>","summary":"The function `random.shuffle` relies on the mutability of the argument and mutability is a pain in the arse, so we propose an alternative.","date_modified":"2025-07-23T16:49:02+02:00","tags":["code review","programming","python"],"image":"\/user\/pages\/02.blog\/mutability-and-random-shuffle\/thumbnail.webp"},{"title":"Manipulate Boolean values with conditions","date_published":"2023-11-28T10:00:00+01:00","id":"https:\/\/mathspp.com\/blog\/manipulate-boolean-values-with-conditions","url":"https:\/\/mathspp.com\/blog\/manipulate-boolean-values-with-conditions","content_html":"
In this article I explore a common code smell related to conditionals and Boolean values and show how to fix it.<\/p>\n\n
The code smell with return<\/code><\/a><\/h2>\n
Consider the function is_even<\/code> shown below.<\/p>\n
def is_even(number):\n    if number % 2 == 0:\n        return True\n    else:\n        return False\n\nprint(is_even(2))  # True\nprint(is_even(3))  # False<\/code><\/pre>\n
What's the code smell it shows?<\/p>\n
The code smell is that it uses an if<\/code> statement to manipulate the Boolean value that we will return from the function.\nI'll explain in more detail what I mean, but it'll be easier if I show you the improved version:<\/p>\n
def is_even(number):\n    return number % 2 == 0\n\nprint(is_even(2))  # True\nprint(is_even(3))  # False<\/code><\/pre>\n
Notice how we took the condition from the if<\/code> statement and just plugged it into the return<\/code>, there is no need for an actual if<\/code> statement.<\/p>\n
What people sometimes forget is that the condition of the if<\/code> statement is actually an expression:\nit's a piece of code that produces an actual value that you can use.\nSo, whenever you have an if<\/code> statement to pick a Boolean value to return, you can rewrite the return to include the condition(s).<\/p>\n
I hope this is making some sense.\nI have another example and an exercise for you, to make sure it is.<\/p>\n
The code smell with assignments<\/a><\/h2>\n
The code smell we're talking about isn't restricted to return<\/code> statements.\nSometimes, the code smell shows itself in assignments like the one below:<\/p>\n
def morning_routine(rodrigo, day):\n    if day in {\"mon\", \"tue\", \"wed\", \"thu\", \"fri\"}:\n        weekday = True\n        weekend = False\n    else:\n        weekday = False\n        weekend = True\n\n    rodrigo.shower()\n    if weekday:\n        rodrigo.shave()\n    rodrigo.walk_pet()\n    # ...<\/code><\/pre>\n
The point here is that we're still using an if<\/code> statement to manipulate Boolean values instead of using the Boolean values directly.\nFor instance, we could assign to weekday<\/code> directly and then set weekend<\/code> to the negation of the value in weekday<\/code>:<\/p>\n
def morning_routine(rodrigo, day):\n    weekday = day in {\"mon\", \"tue\", \"wed\", \"thu\", \"fri\"}\n    weekend = not weekday\n\n    rodrigo.shower()\n    if weekday:\n        rodrigo.shave()\n    rodrigo.walk_pet()\n    # ...<\/code><\/pre>\n
Maybe we don't even need the variable weekend<\/code>!\n(Or maybe we do, it would depend on the remainder of the body of the function morning_routine<\/code>.)<\/p>\n
Exercise<\/a><\/h2>\n
Function to rewrite<\/a><\/h3>\n
Consider the function is_ordered_triple<\/code>, shown below:<\/p>\n
def is_ordered_triple(tup):\n    if len(tup) == 3:\n        if tup[0] <= tup[1] and tup[1] <= tup[2]:\n            return True\n        else:\n            return False\n    else:\n        return False\n\nprint(is_ordered_triple((1, 2)))  # False\nprint(is_ordered_triple((1, 3, 2)))  # False\nprint(is_ordered_triple((1, 2, 3)))  # True<\/code><\/pre>\n
Can you rewrite it in the best way possible, and specifically addressing the code smell I discussed above?\nAfter you're done, add your solution to the comments below!<\/p>\n
Solution<\/a><\/h3>\n
The first thing you can do is rewrite the inner if<\/code> statement so that we return the Boolean value directly:<\/p>\n
def is_ordered_triple(tup):\n    if len(tup) == 3:\n        return tup[0] <= tup[1] and tup[1] <= tup[2]\n    else:\n        return False\n\nprint(is_ordered_triple((1, 2)))  # False\nprint(is_ordered_triple((1, 3, 2)))  # False\nprint(is_ordered_triple((1, 2, 3)))  # True<\/code><\/pre>\n
Then, we can chain comparison operators<\/a> to make...<\/p>","summary":"In this article I explore a common code smell related to conditionals and Boolean values and show how to fix it.","date_modified":"2025-07-23T16:49:02+02:00","tags":["code review","programming","python"],"image":"\/user\/pages\/02.blog\/manipulate-boolean-values-with-conditions\/thumbnail.webp"},{"title":"Why use enums?","date_published":"2023-11-24T12:00:00+01:00","id":"https:\/\/mathspp.com\/blog\/why-use-enums","url":"https:\/\/mathspp.com\/blog\/why-use-enums","content_html":"
This article explains why a user would need to use enums in their code and shows how to do it with a simple example.<\/p>\n\n
What are enums and why do you need them?<\/a><\/h2>\n
Let me show you with a clear example.\nConsider the code below.\nThe function greet<\/code> will accept the name of a person and then it will greet them:<\/p>\n
def greet(user, greeting_type):\n    if greeting_type == \"plain\":\n        return f\"Hello, {user}.\"\n    elif greeting_type == \"warm\":\n        return f\"My dear friend, {user}, how are you doing?\"\n    elif greeting_type == \"casual\":\n        return f\"What's up, {user}?\"\n\nprint(greet(\"Rodrigo\", \"casual\"))\n# \"What's up, Rodrigo?\"<\/code><\/pre>\n
The name can be any string, but the greeting type is supposed to be one of three pre-defined values:<\/p>\n
  1. plain<\/code><\/li>\n
  2. warm<\/code><\/li>\n
  3. casual<\/code><\/li>\n<\/ol>
    These three values represent options<\/em>.\nThe user is supposed to supply one of those, otherwise the function won't know what to do (it should probably raise an error, or something of the sort).<\/p>\n
    Now, imagine this scenario: I'm using the code and I call the function like this greet(\"Rodrigo\", \"PLAIN\")<\/code>.\nWhat happens?<\/p>\n
    What happens is that the code doesn't work! 🤡\nI messed up the casing, which should've been lowercase.<\/p>\n
    Or I could write a typo when writing the option name, like I do so often: greet(\"Rodrigo\", \"WARN\")<\/code>.\nThis would also not work.<\/p>\n
    Or I could just forget which options are available, which also happens frequently to me when working on projects with more than 3 functions!<\/p>\n
    Another thing that could also happen is me mixing up the names of the options when writing another function that should accept the same values.\nFor example, I could create a function say_goodbye<\/code> and then, by mistake, expect these three different options:<\/p>\n
    1. plain<\/code><\/li>\n
    2. friendly<\/code> (instead of warm<\/code>)<\/li>\n
    3. casual<\/code><\/li>\n<\/ol>
      If I do this, I end up with two functions that should accept the same greeting types, but don't!<\/p>\n
      Enums (short for enumerations) are useful to prevent all these mistakes.<\/p>\n
      Using an enumeration for options<\/a><\/h2>\n
      Here's the same code, but using an Enum<\/code> from the module enum<\/code>, instead of harcoded strings:<\/p>\n
      from enum import auto, Enum\n\nclass GreetingType(Enum):\n    PLAIN = auto()\n    WARM = auto()\n    CASUAL = auto()\n\ndef greet(user, greeting_type):\n    if greeting_type is GreetingType.PLAIN:\n        return f\"Hello, {user}.\"\n    elif greeting_type is GreetingType.WARM:\n        return f\"My dear friend, {user}, how are you doing?\"\n    elif greeting_type is GreetingType.CASUAL:\n        return f\"What's up, {user}?\"\n\nprint(greet(\"Rodrigo\", GreetingType.WARM))\n# 'My dear friend, Rodrigo, how are you doing?'<\/code><\/pre>\n
      The class Enum<\/code> is what you inherit from, when creating an enumeration, and the function auto<\/code> is an auxiliary function that you can use to populate the values automatically.\nWhat you really care about is the names GreetingType.PLAIN<\/code>, WARM<\/code>, and CASUAL<\/code>, not the actual value that's stored inside, so auto<\/code> will make sure that you get a unique value for each name without having to worry about it.<\/p>\n
      So, why is this alternative better?<\/p>\n
      All of the previous problems are easily solved!\nMy IDE will auto-complete the greeting type, so there will be no problems with lowercase vs...<\/p>","summary":"This article explains why a user would need to use enums in their code and shows how to do it with a simple example.","date_modified":"2025-07-23T16:49:02+02:00","tags":["code review","programming","python"],"image":"\/user\/pages\/02.blog\/why-use-enums\/thumbnail.webp"},{"title":"5 ways to flatten a list of lists","date_published":"2023-11-23T11:00:00+01:00","id":"https:\/\/mathspp.com\/blog\/5-ways-to-flatten-a-list-of-lists","url":"https:\/\/mathspp.com\/blog\/5-ways-to-flatten-a-list-of-lists","content_html":"
      This article shows 5 ways of flattening a list of lists, ranked from worst to best.<\/p>\n\n
      5 ways to flatten a list of lists<\/a><\/h1>\n
      This short article will show 5 ways of flattening a list of lists, ranked from worst to best.<\/p>\n
      This is the list we'll be using:<\/p>\n
      list_of_lists = [\n    [1, 2, 3],\n    [4, 5],\n    [6],\n    [7, 8, 9],\n]<\/code><\/pre>\n
      Let's start.<\/p>\n
      5th – using functools.reduce<\/code><\/a><\/h2>\n
      >>> from functools import reduce\n>>> from operator import add\n>>> flat_list = reduce(add, list_of_lists, [])\n>>> flat_list\n[1, 2, 3, 4, 5, 6, 7, 8, 9]<\/code><\/pre>\n
      This is not a great idea because using reduce(add, ...)<\/code> is almost always worse than using the equivalent built-in sum<\/code>.<\/p>\n
      In other words, sum<\/code> is the specialised version of reduce<\/code> that adds things, so you'll almost never need reduce(add, ...)<\/code>.<\/p>\n
      (reduce<\/code> isn't useless, though. You can and should read about reduce<\/code> and its use-cases<\/a>.)<\/p>\n
      So, this leads clearly to the next version.<\/p>\n
      4th – using sum<\/code><\/a><\/h2>\n
      >>> flat_list = sum(list_of_lists, [])\n>>> flat_list\n[1, 2, 3, 4, 5, 6, 7, 8, 9]<\/code><\/pre>\n
      This is better than option 5.<\/p>\n
      But it's still not great.<\/p>\n
      The main reason this isn't great is because sum<\/code> will do too much work.\n(Can you see why?)<\/p>\n
      Every time we add two lists (the accumulated one and one from list_of_lists<\/code>), we need to create a third list with all of the elements of the two, so we'll waste a lot of time recomputing lists.<\/p>\n
      So, using sum<\/code> is a neat party trick, and it shows you understand the underlying way in which sum<\/code> works, but it isn't practical.<\/p>\n
      3rd – two nested loops<\/a><\/h2>\n
      This is the KISS solution.\nIt's pretty straightforward and it's a great solution!\nTwo for<\/code> loops and an append<\/code>:<\/p>\n
      >>> flat_list = []\n>>> for sublist in list_of_lists:\n...     for element in sublist:\n...         flat_list.append(element)\n...\n>>> flat_list\n[1, 2, 3, 4, 5, 6, 7, 8, 9]<\/code><\/pre>\n
      This is a brilliant solution!\nThe reason it's placed in 3rd is not because it's bad, but because you can do even better!<\/p>\n
      2nd – using a list comprehension<\/a><\/h2>\n
      >>> flat_list = [\n...     element\n...     for sublist in list_of_lists\n...     for element in sublist\n... ]\n>>> flat_list\n[1, 2, 3, 4, 5, 6, 7, 8, 9]<\/code><\/pre>\n
      This solution is better than the two loops because there are many advantages to using list comprehensions when you have simple for<\/code> loops whose only job is to append items to a new list.<\/p>\n
      I've written extensively about list comprehensions before!\nIf you're interested (and you should be!) you can learn more about list comprehensions and their advantages<\/a>.<\/p>\n
      The list comprehension is always better than the two loops.\nSo, that's why it comes after the two loops.\nBut the next solution is only better than the list comprehension in some cases.<\/p>\n
      1st – using itertools.chain<\/code>:<\/a><\/h2>\n
      >>> from itertools import chain\n>>> flat_list = list(chain.from_iterable(list_of_lists))\n>>> flat_list\n[1, 2, 3, 4, 5, 6, 7, 8, 9]...<\/code><\/pre>","summary":"This article shows 5 ways of flattening a list of lists, ranked from worst to best.","date_modified":"2023-11-24T12:26:55+01:00","tags":["code review","programming","python"],"image":"\/user\/pages\/02.blog\/5-ways-to-flatten-a-list-of-lists\/thumbnail.webp"},{"title":"Enumerate from first principles","date_published":"2022-02-22T00:00:00+01:00","id":"https:\/\/mathspp.com\/blog\/enumerate-from-first-principles","url":"https:\/\/mathspp.com\/blog\/enumerate-from-first-principles","content_html":"
      In this article we reimplement the built-in enumerate<\/code> in the best way possible.<\/p>\n\n
      \""A<\/p>\n
      Preamble<\/a><\/h2>\n
      In this article, we will use Python to reimplement the built-in enumerate<\/code>.\nWe will start with a rough solution that doesn't really cut it,\nand we will rework it bit by bit until we have a full reimplementation of the built-in enumerate<\/code>.\nWe will use this task as the motivation for studying a series of interesting Python concepts and subtleties.\nAs a by-product of working through this article,\nyou will also gain a better understanding of what the built-in enumerate<\/code> is and how it really works.<\/p>\n
      After you work through this article, you will:<\/p>\n