Replies: 2 comments
-
I don't currently use a formatter, but I'll definitely look into it. I use VSCode, which appears to make this sort of integration easy. More broadly, my $0.02 is that we should require good formatting practices in the framework's code, but we shouldn't flag formatting issues in submitted PODs if they aren't syntax errors or issues otherwise flagged by the linter. I feel like we have a finite supply of credit with POD contributors -- if we make the POD submission process too demanding, we'll lose their enthusiasm and goodwill, and one way to preserve that is prioritizing the changes we request from PRs to fix the most critical bugs first. |
Beta Was this translation helpful? Give feedback.
-
On doing a bit more googling, it seems like black is the best of the options out there: e.g. it has the property that running it twice doesn't produce any additional changes, which e.g. yapf isn't guaranteed to do. It introduces many more line breaks than what's in the existing code, which apparently is with the goal of minimizing the size of future diffs. I don't think it would be feasible to, eg, set up a git hook to run a formatter and linter on every commit, since the package is being developed by people using a range of development environments, and we want to make package development accessible to the community. I'd be up for using black to manually reformat the existing package code (after beta 3) -- if you think that should be prioritized, please open an issue for it. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Using a code formatter can make your code much easier for others to read. More importantly, when you make changes to your code, GitHub will render differences in a more clean and predictable way.
I prefer the black code formatter: https://black.readthedocs.io/en/stable/
Does anyone else use a formatter?
Beta Was this translation helpful? Give feedback.
All reactions