3 ms·

Golang, amusingly, is evidence that this not only won't die, but is not a problem. Auto formatting tools work. Well, even. And the idea of pollution in code

by taeric 4y ago

Golang, amusingly, is evidence that this not only won't die, but is not a problem. Auto formatting tools work. Well, even. And the idea of pollution in code history is signaling an ignorance of code repository capabilities. They have been able to show history ignoring whitespace changes for a long time.

dahart 4y ago
It might be worth us outlining a workflow (and I’d be interested to hear yours). I realize that the impulse to be afraid of whitespace changes is reasonable for several reasons: one because git (for example) has defaults that show differences & conflicts on whitespace changes, and you have to change the defaults, two because git and other version control systems are usually much less great at managing cross-line whitespace changes, and three because not everyone is (or should have to be) an expert in their version control tool. Specifically, the workflow here that allows intra-line whitespace without worry is to merge with whitespace disabled, and run the auto-formatter after merging. This means that vertically aligning things is almost innocuous, but having certain tools re-wrap text can still be problematic, at least as far as I know. If there are good ways to handle that second problem, I want that.
- taeric 4y ago
  In general, change what you have to. And no more. If you are fixing whitespace on functions and lines scattered throughout the code, do that deliberately as a code cleanup. But don't expect that running an auto formatter on the entire code base will go over well.
  - dahart 4y ago
    Yeah completely agreed and good point; in my team’s case our guidelines are to never re-format something you didn’t touch in the commit - we request spurious whitespace changes to be reverted during code review, whether accidental or deliberate - but we also request that the block of code that is touched gets formatted. Every once in a while, like maybe once a year or less, we’ll re-run the formatter on the code base because too many things are drifting, and we’ll do it by first broadcasting the intent to the entire team, and then scheduling a good time for it, and lastly changing only formatting and nothing else, and finally if it causes any major problems, reverting and re-scheduling. Formatting the whole code base is never something I’d do lightly.

by taeric 4y ago

dahart 4y ago

It might be worth us outlining a workflow (and I’d be interested to hear yours). I realize that the impulse to be afraid of whitespace changes is reasonable for several reasons: one because git (for example) has defaults that show differences & conflicts on whitespace changes, and you have to change the defaults, two because git and other version control systems are usually much less great at managing cross-line whitespace changes, and three because not everyone is (or should have to be) an expert in their version control tool. Specifically, the workflow here that allows intra-line whitespace without worry is to merge with whitespace disabled, and run the auto-formatter after merging. This means that vertically aligning things is almost innocuous, but having certain tools re-wrap text can still be problematic, at least as far as I know. If there are good ways to handle that second problem, I want that.

taeric 4y ago
In general, change what you have to. And no more. If you are fixing whitespace on functions and lines scattered throughout the code, do that deliberately as a code cleanup. But don't expect that running an auto formatter on the entire code base will go over well.
- dahart 4y ago
  Yeah completely agreed and good point; in my team’s case our guidelines are to never re-format something you didn’t touch in the commit - we request spurious whitespace changes to be reverted during code review, whether accidental or deliberate - but we also request that the block of code that is touched gets formatted. Every once in a while, like maybe once a year or less, we’ll re-run the formatter on the code base because too many things are drifting, and we’ll do it by first broadcasting the intent to the entire team, and then scheduling a good time for it, and lastly changing only formatting and nothing else, and finally if it causes any major problems, reverting and re-scheduling. Formatting the whole code base is never something I’d do lightly.