When you write code, it's always worth remembering that you might write (or re-write) a peice of code multiple times, but you're going to be reading it significantly more. You're going to be reading it when you refactor, you're going to be reading when debugging. So it's always worth making the code readable no matter what the size of the codebase. As the codebase get's bigger then the more important it is to make the code readable.

Let's take an example from Oubliette.

Now you see all the little const's in this file (these are the regular little pieces circled on the right). Having them all in there like this makes this particular file hard to read. You have to scroll a looooooooooooonnnnnnnnnnnnnnggggggggggggg way down to get to the meaty part of the file to understand what the code is doing.

I like to follow the mantra, often attributed to Ward Cunningham, 'Make it work, make it right, make it fast'. So because I need to meet the deadline for the Game Jam I've entered, I've left this as it is because the code is still going to work.

However, at some point, I may well revisit this part of the code and refactor it. Ideally, I would move it out into its own file, separating the concerns of data and its consumption. In coding, there is always a tradeoff. In this case it's making information which should be private to the pit generator more available in other places. Because we would not be using the pit data elsewhere, this means we are unnecessarily exposing information that is only used by the pit data. 

This could lead to another dev in the team, or even yourself later down the line re-using this data, and coupling the pit and tile information with other modules, making them harder to change.

I should be committing a running version of Oubliette to https://itch.io/jam/20-second-game-jam-2025 soon.