Closed jack60612 closed 1 year ago
@virtuald where would you want me to put the information on how to use the formatters & linters?
We already run black in CI?
We already run black in CI?
oops, I must have missed it.
We already run black in CI?
oops, I must have missed it.
~Wait, why did it reformat things then?~ Line length.
What should i use as the standardize
We already run black in CI?
oops, I must have missed it.
~Wait, why did it reformat things then?~ Line length.
I set the line length to 120 because it seemed like that was what was being used, but i can change that back to 88 if thats whats wanted.
Would it make sense to use pre-commit to front-load any formatting changes? Only being able to commit formatted code improves legibility of diffs commit to commit.
oops, i got distracted by the season, ill look at this again.
Would it make sense to use pre-commit to front-load any formatting changes? Only being able to commit formatted code improves legibility of diffs commit to commit.
Just enable format on save in your editor?
Just enable format on save in your editor?
I think that's pretty standard nowadays.
What I was suggesting is different from that though. Using pre-commit can help enforce repository-wide linting and style rules for all future contributions and allows contributors to catch any linting or formatting errors upon committing code locally and before they are pushed and subsequently fail in CI. Since the pre-commit hooks are installed by each contributor after checking out the repository people can choose whether they'd like that convenience or not. Configuring the linting and style rules for this purpose also creates explicit guidelines of how the project expects code to be formatted.
If you want to go down this path again, we've moved everything to the mostwpilib repository.
Added black (code formatter), isort (import formatter) and flake8 a pep8 abiding code linter Also added gh actions workflows for everything above