Avoid aligning keys and values in source code unnecessarily
databasesandlife.com
Avoid aligning keys and values in source code unnecessarily
1–7 of 7 posts
Re: Avoid aligning keys and values in source code unnecessarily
#2You 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.
Re: Avoid aligning keys and values in source code unnecessarily
#3Diff tools have managed pretty much well this formatting issue (ignore whitespace) so it's not really a topic anymore.
Re: Avoid aligning keys and values in source code unnecessarily
#4Diff 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.
Re: Avoid aligning keys and values in source code unnecessarily
#5You 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.
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.
Re: Avoid aligning keys and values in source code unnecessarily
#6Diff 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 th…
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.
Re: Avoid aligning keys and values in source code unnecessarily
#7Earlier quoted context omitted.
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 th…
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…
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.