I did not look at their particular code but I had files named like this in my projects: api_v1, api_v2. Reason being that the software V2 still supported v1 api so both were present and needed.

A reasonable approach but from the README:

"To run the code you will need to install Python and the PyGame library, and then run the latest .py file because I can't be bothered to actually use version control."

I'm just reminded of the last line of the README.md

"I am in Electrical Engineering and I like writing shitty code to piss off my Computer Science friends." -- https://github.com/ehulinsky/AnalogChess/blob/main/README.md...

It's a relatively common approach in e.g. web services, but not in standalone games.

I did not really look at the project, just at the comments so yes sure.

I do the same. I think it's nice to have the old version readily available as reference instead of hidden in git.

Alternatively to "better IDE", use git worktree. git allows to check out multiple revisions to distinct working directories.

Or just clone the same repo multiple times, or have some releases unpacked outside of version control.

You need a better ide!

It's so cliche to recommend a more complex tool --- with its own associated learning curve and more complex failure modes --- when there's already a simple method that works perfectly well, but isn't "best practice" or whatever the dogmatists call it.

Can you run two or more versions and compare their behaviour simultaneously, even debug them side-by-side? I'm sure there's some sort of plugin and IDE ecosystem that you can spend tons of time learning how to configure just to be able to do that, but if all I need to do is to copy the files and rename them, why not?

Do some people really love excess complexity so much?

I guess it depends on your use case. If you have a basic tool where most of the functionality lives in a single file and which you need to compare to previous versions frequently, I can see how just having incrementing file names could be useful.

I would say that this is a bit of an exception though. Most projects are spread across many files and dependencies, so it would be a huge mess trying to manually version those by renaming files all the time. I also rarely want to compare several different versions of my code side by side, so I prefer having all of the old stuff 'hidden away' in git by default.

So to me, git + a sensible IDE is actually the less complex option, by far.

I agree with the general gist if your post, but still wanted to call out the "git worktree" because that would solve the problem you're describing. It's pretty much a better version of cloning the repo twice.

phpstorm has good history. vs code can die in a fire.

What has VS Code done to you to deserve that?

:-) I don't hate it that much, in fact, I use it a bit, but I still think it's inferior, but the fact that it's so popular means that a lot of extension developers are now targeting it and only it which forces me to use inferior tooling for some things. I already have this problem with Git. I think Mercurial is better but all the good tooling is built around Git.