Details
-
Type:
RFC
-
Status: Withdrawn
-
Resolution: Done
-
Component/s: DM
-
Labels:None
-
Location:This ticket
Description
A good automatic code formatter has the potential to save a lot of developer time vs. hand formatting, testing with a validator, and learning to read different user's styles.
The "black" formatter https://black.readthedocs.io/en/stable/ seems to do a very nice job with Python code (unlike AutoPep8) and the results appear to be pep8 complaint. The one major difference I have noticed compared to our standards is that when a statement with binary operators is broken into multiple lines, the binary operator is at the beginning of the new line. flake8 can be configured to support this.
Note that black is not very configurable. So we don't have to argue about which settings to use.
This proposal is to allow us to use black to format our code. A future RFC would be needed to require use of black.
Thanks to Matthew Becker for bring it to my attention.
As an experiment I used black (with no configuration) to reformat all of the python code in ts_salobj (a fairly large package of pure Python code). I then ran flake8 on it only got two categories of warnings:
- W503 line break before binary operator. This is expected and reflects an existing standard we would have to change.
- E203 whitespace before ':'. Black uses [start : end] instead of [start: end] for ranges.
I made a pull request to show what changed: https://github.com/lsst-ts/ts_salobj/pull/69
I don't agree with all the changes, but I think the results are quite readable. I think the potential productivity benefits far outweigh any minor formatting annoyances.
I filed https://jira.lsstcorp.org/browse/RFC-650 to change our standard for binary operators in continuation lines. But as I said, I see it as orthogonal, though it would nicely pave the way for this one.