I have to disagree, but I’m using black to format about 15 different repositories. 4 are open source. The ament_black repo is awesome for this purpose, and pre-commit works well too!
I got tried of flake8 easly on. Spending time manually formatting code is a complete waste of time, but I understand why this practice is enforced in the ROS core.
Anyways, I propose using automated tools for new code, and would be happy to lead a proposal to change this requirement for ROS packages:
https://docs.ros.org/en/rolling/The-ROS2-Project/Contributing/Developer-Guide.html#linters-and-static-analysis
To me, if a NEW package has all of its linting tool requirements specified in the package.xml, they are documented how to run them automatically in CI, and you can run them all automatically with pre-commit, why does it have to be the same style for the every repo in the ecosystem? Isn’t the point to be consistent within a repo and obvious for users on how to run the tools?
Personally, I have zero preference whether to write python strings with single or double quotes; it’s much more important to me that the tooling just fixes whatever I type and gives new contributors an easy way to auto-format the code. Having to maintain packages with manually formatted code and remind contributors every PR that they failed the style checks and have to go manually add some whitespace before a class definition is not the best use of time IMHO.
Also, regarding having to deal with noise in the commit history, there’s a solution: git-blame-ignore-revs:
- Decide the formatting tools
- Run them on the code, and merge a single commit to the repo with those automated changes
- Add a PR to add that commit hash to the .git-blame-ignore-revs file
- Now, your editor and Gitlab ignore those commits when looking at blame!
Note - mass-formatting a codebase between releases is hard if you maintain multiple LTS branches. Depending on the size of the repo, and whether it’s forked or used as-is, it might make sense to do a mass-format. Some people go as far as re-writing all the history in the repo with the new format from the beginning of time, however that’s quite aggressive and breaks any companies forking internally who aren’t superb git users. Internally, we had 3 teams working on the same codebase, and set a date a year out, about a month after a big release, when everyone was doing architecture work, and ran the tool. It was pretty low impact for us because you can have pre-commit run the formatter on each commit when you rebase a long-standing branch that had the format change under its feet.