On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
quoted
quoted
Right, the reason I stopped pursuing it was that I couldn't find a way
to have it make suggestions for new code without nagging about existing
code. If we were to aggressively reformat to match the tool for existing
code, that would help. But I'm a bit worried that there would always be
suggestions from the tool that we don't agree with (i.e., where the
guiding principle is "do what is readable").
We may have different opinions on what is readable/beautiful code.
If we were to follow a mutual agreed style that is produced by a tool,
we could use clean/smudge filters with different settings each.
I'm less worried about a difference of opinion between humans. My
concern is that there are cases that the tool's formatting makes _worse_
than what any human would write. And either we accept ugly code because
the tool sucks, or we spend a bunch of time fighting with the tool to
try to make its output look good.
quoted
I would think based on these options, a pre commit hook can be
written that formats precisely the touched lines of code of each file.
I did not search enough, "clang-tidy-diff.py --fix" should be all that is needed
I think I found that script when we discussed this a while back, but I
couldn't get it to stop bugging me about lines that I hadn't touched. I
haven't looked at it recently, though. That's specifically what I was
wondering about with "is the tooling ready for this".
-Peff
On Wed, Aug 09, 2017 at 07:19:00PM -0400, Jeff King wrote:
On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
quoted
quoted
quoted
Right, the reason I stopped pursuing it was that I couldn't find a way
to have it make suggestions for new code without nagging about existing
code. If we were to aggressively reformat to match the tool for existing
code, that would help. But I'm a bit worried that there would always be
suggestions from the tool that we don't agree with (i.e., where the
guiding principle is "do what is readable").
We may have different opinions on what is readable/beautiful code.
If we were to follow a mutual agreed style that is produced by a tool,
we could use clean/smudge filters with different settings each.
I'm less worried about a difference of opinion between humans. My
concern is that there are cases that the tool's formatting makes _worse_
than what any human would write. And either we accept ugly code because
the tool sucks, or we spend a bunch of time fighting with the tool to
try to make its output look good.
This has been my issue with clang-format in the past. I have an SHA-256
implementation with an array of 64 32-bit hex integers. These fit six
to a line, but for neatness and consistency reasons, I'd like them four
to a line (4 divides 64, but 6 does not). Last I checked, clang-format
didn't allow me that option: it reordered them because it could fit six
on a line. This is not the only issue I discovered, just the most
memorable.
Other tools, such as perltidy, have traditionally honored existing line
breaks better (although not perfectly), which lets humans optimize for
readability.
Of course, clang-format could have dramatically improved since I last
looked (which was around clang 3.4 or 3.6, I think).
Overall, I do like the idea of using tidy tools, because it does reduce
quibbling over style quite a bit. I just like the tools to be more
responsive to the whitespace they're given on input.
--
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
Hi,
brian m. carlson wrote:
quoted
On Wed, Aug 09, 2017 at 03:53:17PM -0700, Stefan Beller wrote:
quoted
quoted
We may have different opinions on what is readable/beautiful code.
If we were to follow a mutual agreed style that is produced by a tool,
we could use clean/smudge filters with different settings each.
I think this is a long way away --- long enough away that by the time
such a change could be a serious possibility, a lot may have changed
and the project is likely to know a lot more. In other words, I don't
see speculating about that future as being likely to produce useful
results today.
It would be a different story if we were writing a new codebase from
scratch. In that case, I would be all for the gofmt approach. :)
On Wed, Aug 09, 2017 at 07:19:00PM -0400, Jeff King wrote:
quoted
I'm less worried about a difference of opinion between humans. My
concern is that there are cases that the tool's formatting makes _worse_
than what any human would write. And either we accept ugly code because
the tool sucks, or we spend a bunch of time fighting with the tool to
try to make its output look good.
This has been my issue with clang-format in the past. I have an SHA-256
implementation with an array of 64 32-bit hex integers. These fit six
to a line, but for neatness and consistency reasons, I'd like them four
to a line (4 divides 64, but 6 does not). Last I checked, clang-format
didn't allow me that option: it reordered them because it could fit six
on a line. This is not the only issue I discovered, just the most
memorable.
In case it comes up again for you in a project that has adopted the
gofmt approach: you can signify that your line breaks are intentional
by putting line comments at the end of each line and clang-format will
respect them.
The clang-format documentation also mentions[1] that you can do
/* clang-format off */
const double kIdentityMatrix[] = {
1, 0, 0,
0, 1, 0,
0, 0, 1,
};
/* clang-format on */
Thanks,
Jonathan
[1] http://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code