Avoid aligning keys and values in source code unnecessarily(databasesandlife.com)
databasesandlife.com
Avoid aligning keys and values in source code unnecessarily
https://www.databasesandlife.com/dont-align-struct-values/
6 comments
Diff tools have managed pretty much well this formatting issue (ignore whitespace) so it's not really a topic anymore.
Interesting. Yeah I did think maybe this could be solved by more tooling. But at my place it work it isn’t, at least at the moment. Perhaps I could change that.
Do you have any info on what I could use to make the command-line “git diff” and “git rebase” handle this style of formatting? Ideally so the latter merges and produces code which matches “gofmt” output?
On the other hand I suppose my point is that even if there were such tooling, using style of formatting doesn’t offer enough (any?) benefit to justify the effort of introducing the tooling.
Do you have any info on what I could use to make the command-line “git diff” and “git rebase” handle this style of formatting? Ideally so the latter merges and produces code which matches “gofmt” output?
On the other hand I suppose my point is that even if there were such tooling, using style of formatting doesn’t offer enough (any?) benefit to justify the effort of introducing the tooling.
Context matters, but this what I would do (and I always apply when landing in a project, own or client, that has no documented or enforced code style):
1/ always have pre-commit hooks running lint/fmt, and document how to implement them in a common fashion in the team,
2/ strive to follow the language conventions (and if not, have those divergences explicitly defined in the linter/formatter tool configuration), this helps the team to align with it,
3/ having a job server-side that blocks merging PRs that do not pass both of these steps.
1/ always have pre-commit hooks running lint/fmt, and document how to implement them in a common fashion in the team,
2/ strive to follow the language conventions (and if not, have those divergences explicitly defined in the linter/formatter tool configuration), this helps the team to align with it,
3/ having a job server-side that blocks merging PRs that do not pass both of these steps.
Thanks. We're doing all that.
But that doesn't help when you do "git rebase" and there's a large conflict which you have to resolve manually, caused by two people changing different lines, and one or both of those lines caused the formatting of the whole block to change. That's the source of my frustration.
But that doesn't help when you do "git rebase" and there's a large conflict which you have to resolve manually, caused by two people changing different lines, and one or both of those lines caused the formatting of the whole block to change. That's the source of my frustration.
You can pry my alignment format rules out of my cold dead hands.
I Absolutely love how the use of white space makes things more readable.
I Absolutely love how the use of white space makes things more readable.
Im not sure I understand the readability benefits. Is code like line 286 here, which doesn’t align values in assignments, difficult to read?
https://github.com/gohugoio/hugo/blob/master/commands/comman...
Even if there were readability benefits, I’m not sure they’d be enough to offset the extra effort in reviewing, diffing and merging.
https://github.com/gohugoio/hugo/blob/master/commands/comman...
Even if there were readability benefits, I’m not sure they’d be enough to offset the extra effort in reviewing, diffing and merging.