Should we have some sort of code style?

I notice there’s not much consistency across the codebase in some cases (e.g., 'strings' and "strings", etc.). Any code style is good enough (I really like black). This could be enforced in a post-commit or post-merge hook.

[shivupa]

What Minsik said was indeed true. I have some new thoughts about this.

I agree with making it easier to contribute. Personally I think precommit hooks are a little tedious on developers since it requires them to set it up, but I am open to discussion on that point.

I do think just running black -l 100 on the source and adding a github action to check if future contributions abide by the constraints sounds like a good option.

[berquist]

I think people were asked to run black -l 100 on any file they changed in the commit. As far as I remember, there was a discussion on whether we want to run black on the entire repo some time ago, but we decided not to because it would make it harder to track changes through git history. Please correct me if I am not recalling the discussion correctly!

This is correct on all points. I’m not sure it would be as bad as some renames or moves: I needed multiple revision checkouts to see the original history of io.

One more concrete (and common) concern is that it will mess with all open PRs, so we should try and push them through before running a formatter. Rebasing them after formatting the codebase will be a pain.

I use black as part of https://pre-commit.com/ (but not in GHA) for all my other projects. I think we should do whatever makes contributing to the code and modifying it easier.