4 ms·

People/formatters that justify their structures drive me completely crazy (I'm looking at you golang et al). It's like they've never tried using revision contro

by ris 6y ago

People/formatters that justify their structures drive me completely crazy (I'm looking at you golang et al). It's like they've never tried using revision control before. It just takes a single change in the longest entry and something that was a 1-byte change becomes a 20-line diff. Noisy for code review and 20 times more likely to create a merge conflict. Your obsessive compulsions are something to be overcome, not embraced, and certainly not something to force on other people.

dmos62 6y ago
To be fair, you could argue that your mentioned behaviour is an undesirable feature of current revision control software and code editors. The formatting could be declarative, so that compiler-meaningless indentation is not on disk. And, compiler-meaningless changes could be ignored by revision control (that's probably provided if meaningless changes aren't persisted to disk in the first place).
- ris 6y ago
  This implies an amount of language-understanding from the revision control system I'd rather avoid, especially when I unfortunately spend so much of my life writing mixed source-in-source-in-source monstrosities these days.
  - eyelidlessness 6y ago
    How much would it have to know? I’d expect a `significant_leading_whitespace=true` config would probably do the job?
gjm11 6y ago
It maybe depends on who's going to be interacting with the code in what ways. If you expect the code to be changed infrequently but read frequently, and if you think the justified version is easier to read or harder to miss errors in, then that could easily outweigh the cost of noisier diffs. (I'm not sure whether I actually believe the following argument, but:) The increased likelihood of merge conflict is not necessarily a bad thing. If you've got a bunch of variables, structure entries, or whatever, that are related to one another, then if A changes one of them and B separately changes another this very well may be the sort of thing you need to look at carefully and explicitly, which is what getting a merge conflict forces you to do. And (maaaaybe) the more closely related nearby variables (etc.) are, the more likely people who like justified code are to justify them. Full disclosure: I sometimes justify things in code, in cases where I think it helps to clarify relationships between nearby lines. I don't remember ever getting a merge conflict as a result, or having colleagues complain about noisier diffs. But I've generally worked in small teams and I've often been the only person working on a given bit of code, and what works well in that context is not necessarily the same as what works if you have a much larger group all poking at the same code.
sly010 6y ago
As for golang, I think the pros outweigh the cons here. Code is read more than it's written. Cleaner code means you can literally identify code structure from afar. Which in turn makes is easier to focus on the part you care about. If you have to pick a length for automatic formatting，the same length makes sense. So is trailing commas. Even if only half of engineers think this is true, the other half should be pragmatic and let the go formatter do it's thing. The best thing about go is that it has one standard formatting. As for equal length variable names, the majority of these examples you would use naturally anyway, so I am not sure what are you so upset about (top/not instead of true/false is a bit overkill)
- ris 6y ago
  > Even if only half of engineers think this is true, the other half should be pragmatic and let the go formatter do it's thing. Why should a group of tolerant people bend to the wishes of a group of intolerant people? That's how I see the whole formatting debate. Why should people comply with a formatting that is demonstrably worse in concrete ways (let's not even start talking about how it makes the need for ugly line-breaks occur much sooner), and to many is harder to read? I don't understand why people feel the need to force their obsessions on other people. If you find it harder to read without a specific formatting, please go and develop some plugin in your fancy editor to display it to you that way. Just deal with it on your end and don't make it my problem.
eyelidlessness 6y ago
I used to hate it until I worked on a team that preferred it. Now I find more than a handful of lines without alignment hard to read. I’m not saying everyone would change their mind, but I suspect a lot of style preferences are more rooted in familiarity than we necessarily realize.

by ris 6y ago

dmos62 6y ago

To be fair, you could argue that your mentioned behaviour is an undesirable feature of current revision control software and code editors. The formatting could be declarative, so that compiler-meaningless indentation is not on disk. And, compiler-meaningless changes could be ignored by revision control (that's probably provided if meaningless changes aren't persisted to disk in the first place).

ris 6y ago
This implies an amount of language-understanding from the revision control system I'd rather avoid, especially when I unfortunately spend so much of my life writing mixed source-in-source-in-source monstrosities these days.
- eyelidlessness 6y ago
  How much would it have to know? I’d expect a `significant_leading_whitespace=true` config would probably do the job?

gjm11 6y ago

It maybe depends on who's going to be interacting with the code in what ways. If you expect the code to be changed infrequently but read frequently, and if you think the justified version is easier to read or harder to miss errors in, then that could easily outweigh the cost of noisier diffs. (I'm not sure whether I actually believe the following argument, but:) The increased likelihood of merge conflict is not necessarily a bad thing. If you've got a bunch of variables, structure entries, or whatever, that are related to one another, then if A changes one of them and B separately changes another this very well may be the sort of thing you need to look at carefully and explicitly, which is what getting a merge conflict forces you to do. And (maaaaybe) the more closely related nearby variables (etc.) are, the more likely people who like justified code are to justify them. Full disclosure: I sometimes justify things in code, in cases where I think it helps to clarify relationships between nearby lines. I don't remember ever getting a merge conflict as a result, or having colleagues complain about noisier diffs. But I've generally worked in small teams and I've often been the only person working on a given bit of code, and what works well in that context is not necessarily the same as what works if you have a much larger group all poking at the same code.

sly010 6y ago

As for golang, I think the pros outweigh the cons here. Code is read more than it's written. Cleaner code means you can literally identify code structure from afar. Which in turn makes is easier to focus on the part you care about. If you have to pick a length for automatic formatting，the same length makes sense. So is trailing commas. Even if only half of engineers think this is true, the other half should be pragmatic and let the go formatter do it's thing. The best thing about go is that it has one standard formatting. As for equal length variable names, the majority of these examples you would use naturally anyway, so I am not sure what are you so upset about (top/not instead of true/false is a bit overkill)

ris 6y ago
> Even if only half of engineers think this is true, the other half should be pragmatic and let the go formatter do it's thing. Why should a group of tolerant people bend to the wishes of a group of intolerant people? That's how I see the whole formatting debate. Why should people comply with a formatting that is demonstrably worse in concrete ways (let's not even start talking about how it makes the need for ugly line-breaks occur much sooner), and to many is harder to read? I don't understand why people feel the need to force their obsessions on other people. If you find it harder to read without a specific formatting, please go and develop some plugin in your fancy editor to display it to you that way. Just deal with it on your end and don't make it my problem.

eyelidlessness 6y ago

I used to hate it until I worked on a team that preferred it. Now I find more than a handful of lines without alignment hard to read. I’m not saying everyone would change their mind, but I suspect a lot of style preferences are more rooted in familiarity than we necessarily realize.