Christian Couder <christian.couder@xxxxxxxxx> writes: > It's up to each one to decide if they prefer post-commit or pre-commit > hooks or other ways to trigger the style check. So yeah, we could both > suggest using hooks and add a format-patch option to make it easier > for those who don't want a hook. The thing is, I have no idea what the "option" to format-patch you talk about should look like. This topic is about improving Git codebase by helping Git developers, and I do not want to add a project-specific option to the tool that is meant for the general public. >> Or just write that command invocation into "MyFirstContribution" etc.? > > Yeah, we could do that too. I think that is a good first step. Give an example that shows that the tool can give suboptimal suggestions as well as good ones, to stress the point that the output from the tool should not be taken blindly, but should still be looked at. >> What I called "once the code is written" is something I would refuse >> to accept as a "style fix" patch, but they are still improvements >> and it would be great if contributors followed these style checker's >> suggestion _before_ sending the patch to the list. > > If we encourage a style checker to make suggestions that are often in > bikeshedding territory, then I think we take the risks of: I do not think I am advocating to encourage a style checker to make bikeshedding suggestions at all. We are not discussing any change to .clang-format file in this discussion (a side thread we discussed about concluding a year-old experiment, which would result in a small change to the file, though). > - annoying some users who disagree with some suggestions, That I do not think we care too much. This is not about "users". > - having bikeshedding discussions on the list (like this one) about > things that are just not worth it, But now we have a good thing to point at. "You want to bikeshed? Let's see what clang-format with our recommended setting says." And the discussion should end there. > - the style checker being actually wrong (because of the context for example). If you are worried about "bikeshedding territory", there is no additional risks for the tool to be actually wrong. Whether you blindly take its stylistic changes or not, you'd need to be careful about tool changing the meanings of the code it is touching. > In my opinion the possible small gains are not worth taking those > risks. So, from my point of view, I am not sure if there is _any_ risks, but again I do not know who you think is advocating for more bikeshedding via the style checker. > In other words from a style checker I'd rather have fewer > suggestions that are more likely to be right, than more suggestions > that are more likely to be dubious. No question about that, but I see no logical linkage between what you said above and this goal, sorry. > I agree that in the example above the suggested change might be good. > But if there is ... Don't move the goalpost. It is not the case we are discussing. > So my opinion is that a style checker that doesn't take into account > the length of the lines around where it makes suggestions is likely to > make a number of wrong line wrapping suggestions. Your example is not even about "around", but the exact line that is being changed, isn't it? Even if the line being changed were the only overly long line, and all lines around it were below the length that is comfortably read with minimal horizontal eye movement, we still want to wrap it down, don't we?
