3 ms·

Please let this horrendous habit die. Aside from the impossible to read without printing it out on ruled paper, change the length of one variable and your auto

Please let this horrendous habit die. Aside from the impossible to read without printing it out on ruled paper, change the length of one variable and your auto format pollutes git history with a five line change. Most statements aligned like this aren't even related, they just happen to be colocated but then the (forced by the autoformatted standard) vertical alignment makes it look related. Coding style (more precisely whitespace) is able to say a lot about the code without you even reading the code. This code style paints a picture that isn't there.

dahart 4y ago
> It's a coding style that lies and it should be taken out back. I’m a fan of only aligning things that are actually similar. The important part IMO is to make it easy to see differences in the middle of something that’s a pattern, not to extract similarity out of semantically different things (which is the reason I don’t love aligning the opening function braces). I’m also a fan of using the -w flag with git diff, and of avoiding hyperbole, but there is a valid and very good point in there about causing merge conflicts! ;) I don’t get to use my grid aligner all that often, because using clang-format is more important, so I don’t use it around other people very much. But all that said, I never hesitate to re-grid something if a variable changes, as long as I know it won’t cause a source control conflict. * edit BTW I just realized the better argument which is that clang-format already has the very problem you mentioned: renaming anything can and will often cause reflow of text. Avoiding grid-alignment of text has very little bearing on whether this is going to happen to you. The only way to avoid formatting changes in your source control is to never reformat code, which isn’t something my team wants to prioritize, so we make do with selective application of clang-format. It’s sometimes useful to separate code changes from whitespace/format updates.
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.
Izkata 4y ago
> and your auto format pollutes git history with a five line change. Learn your tools: git provides "-w" to ignore whitespace changes. SVN provided a similar option. This isn't new.
- onlypositive 4y ago
  This noise shows up in git greps. It's not as superficial as you think.
  - dahart 4y ago
    It’s true that searching for something will return the lines as they’re formatted. I’m certainly curious to hear how whitespace changes over time in git grep causes problems, what the problems are, and what the alternatives are. I can imagine reasons that might happen, but that particular example isn’t something I’ve experienced myself or heard of before, so I don’t know if I’m discounting it unfairly. Like I said in defense of your comment higher up, I see why people like you react to certain formatting tools this way, but it turns out that tools that insert and delete line breaks are far more serious when it comes to workflow implications than tools that only insert spaces or tabs to get vertical alignment, so it’s worth making that distinction right from the start. I don’t think vertical alignment is going away, I think it will become far more common, and that our tools will catch up. My prediction is that git and other source control systems become more tolerant of formatting changes, and that developers in general will learn more workflow techniques for allowing whitespace churn. For me, having the alignment and making the code more readable to me is more valuable than the minor inconveniences with source control that it might cause, and on top of that I’ve learned that there are ways to mitigate most of the issues. I’m not arguing that it doesn’t cause any problems, I’m only saying that it’s worth prioritizing for me, that there are things you can learn to do about it, that the tools give you options and will probably improve, and that vertical alignment in particular does far less damage that line-breaking reflows like clang-format impose… and use of clang-format is pretty widespread and standard in my experience. Code does change over time. Refactoring happens. Variables are renamed. Comments change over time. We don’t ask people to avoid writing code or adding comments because the changes appear in git diff or grep, or even because they might cause merge conflicts… those things are considered an acceptable cost of doing business in software. I don’t see any reason to treat good formatting differently, within reason.

dahart 4y ago

> It's a coding style that lies and it should be taken out back. I’m a fan of only aligning things that are actually similar. The important part IMO is to make it easy to see differences in the middle of something that’s a pattern, not to extract similarity out of semantically different things (which is the reason I don’t love aligning the opening function braces). I’m also a fan of using the -w flag with git diff, and of avoiding hyperbole, but there is a valid and very good point in there about causing merge conflicts! ;) I don’t get to use my grid aligner all that often, because using clang-format is more important, so I don’t use it around other people very much. But all that said, I never hesitate to re-grid something if a variable changes, as long as I know it won’t cause a source control conflict. * edit BTW I just realized the better argument which is that clang-format already has the very problem you mentioned: renaming anything can and will often cause reflow of text. Avoiding grid-alignment of text has very little bearing on whether this is going to happen to you. The only way to avoid formatting changes in your source control is to never reformat code, which isn’t something my team wants to prioritize, so we make do with selective application of clang-format. It’s sometimes useful to separate code changes from whitespace/format updates.

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.

Izkata 4y ago

> and your auto format pollutes git history with a five line change. Learn your tools: git provides "-w" to ignore whitespace changes. SVN provided a similar option. This isn't new.

onlypositive 4y ago
This noise shows up in git greps. It's not as superficial as you think.
- dahart 4y ago
  It’s true that searching for something will return the lines as they’re formatted. I’m certainly curious to hear how whitespace changes over time in git grep causes problems, what the problems are, and what the alternatives are. I can imagine reasons that might happen, but that particular example isn’t something I’ve experienced myself or heard of before, so I don’t know if I’m discounting it unfairly. Like I said in defense of your comment higher up, I see why people like you react to certain formatting tools this way, but it turns out that tools that insert and delete line breaks are far more serious when it comes to workflow implications than tools that only insert spaces or tabs to get vertical alignment, so it’s worth making that distinction right from the start. I don’t think vertical alignment is going away, I think it will become far more common, and that our tools will catch up. My prediction is that git and other source control systems become more tolerant of formatting changes, and that developers in general will learn more workflow techniques for allowing whitespace churn. For me, having the alignment and making the code more readable to me is more valuable than the minor inconveniences with source control that it might cause, and on top of that I’ve learned that there are ways to mitigate most of the issues. I’m not arguing that it doesn’t cause any problems, I’m only saying that it’s worth prioritizing for me, that there are things you can learn to do about it, that the tools give you options and will probably improve, and that vertical alignment in particular does far less damage that line-breaking reflows like clang-format impose… and use of clang-format is pretty widespread and standard in my experience. Code does change over time. Refactoring happens. Variables are renamed. Comments change over time. We don’t ask people to avoid writing code or adding comments because the changes appear in git diff or grep, or even because they might cause merge conflicts… those things are considered an acceptable cost of doing business in software. I don’t see any reason to treat good formatting differently, within reason.