[zamubafoo]

I think I've learned more reading bad code bases than reading good code bases.

The entire point is not to just mindlessly consume a code base, but instead form an idea of how to approach the problem and then see if your hypothesis is correct. Then comparing your approach to the actual approach.

This can show you things that you might've missed taking into account.

For example, gallery-dl's incidental complexity all lies in centralizing persistent state, logging, and IO through the CLI. It doesn't have sufficient abstraction to allow it to be rewired to different UIs without relying on internal APIs that have no guarantee that won't change.

Meanwhile a similar application in yt-dlp has that abstraction and works better, but has similar complexity in the configuration side of things.

[sevensor]

It's a pain, but you can definitely learn a lot from fixing a bad codebase. For that, I recommend trying to write type annotations and get the whole thing to type-check. I've found that bad codebases end up having very complex type annotations because their authors actually contradict themselves. One of my personal favorites in Python is mixing strings and UUIDs as dictionary keys. This positively guarantees a fun afternoon.

Edit: speling

[agumonkey]

Another learning point is being sensitive to your psychology / mental energy. I can start with high quality well named, well abstracted code.. but after two weeks I find myself writing shitty code.. and having a hard time realising I should stop, take a pause, take a step back instead of piling on.

[mixmastamyk]

I'd start with pyflakes and ruff check/format as step 0. Much easier to get started, and will have fixed a lot of stuff quickly. Next, add types.

[noufalibrahim]

Related to this. Read the stdlib. Decades of somewhat decent backward compatibility, optimisations etc.

It's almost archaeological.