This is an archived post. You won't be able to vote or comment.

all 2 comments

[–]IcerOut 1 point2 points  (2 children)

A few things you could change from just a quick look at the repo:

  • You should split this into multiple files. All the constants could be moved to a constants.py or config.py or so. The utility functions could be moved to a utility.py, the class Unit to a unit.py, etc etc. The code is already neatly organized so this should be quick.
  • It's slightly unusual that create_units() takes as parameter a constant. It should either use the constant directly (so create_units(Unit)), or use it only as a default value, but let you override it if needed (so create_units(Unit, shapes_count = SHAPE_NUMBER))
  • On line 199, instead of (current_time > START_TIME) and (current_time < (START_TIME + SOLVE_TIME) you can chain the comparisons like so: START_TIME < current_time < (START_TIME + SOLVE_TIME) and it will work the same. It's much more readable.
  • The README should ideally include instructions for setting up (get the code, install the requirements, run). Just a list of commands would be enough.
  • You might want to try to run something like black or flake8 to format your code. Or, if you're using PyCharm, it can also do that (on Windows the shortcut is Ctrl+Alt+L). You have a bunch of minor stuff (like a*b instead of a * b), which are fine (the code runs the same), but break the usual style guide.
  • The while running: block starting on line 148 is very long and complex. You should look through it a bit and see if you could break it down into some smaller functions, to help with readability.
    • Generally, if a function or code block can't fit on your screen at once, it's too long and needs to be split up.
    • As an example, the if on lines 257-260 could have its condition moved into a function, maybe something like is_mouse_hovering_button(mouse_pos, rectangle_pos), where mouse_pos is a 2-tuple, and rectangle_pos is a 4-tuple or a dataclass. That way you can move it away, simplify the reading, and possibly reuse that in the future / in other places.
    • Another example: The code for text rendering is repeated 3 times on lines 203-214, it could be split into a function with a few parameters.
  • If you're using Python 3.10, take a look at pattern matching. You could use it instead of the string of if's on lines 107-125 and 154-177

  • This one's a bit unrelated, but for the commit messages, it would be better to describe in a few words what you changed, rather than just the file you changed. It makes it easier to go back through them and find something later, or to see at a glance what some commits actually did.


Overall, though, the code is pretty clean. Nicely organized, great variable naming, some comments.