On 23/01/2024 4:14 AM, Prajwal S N wrote:
> I came across this suggestion from Rikki in one of the other threads, and just wanna make sure I understand correctly - we'd ideally want a CI job that runs dfmt on the PR, and in case of any reformatting, it pushes a commit with those changes. Or are we just looking for a job that detects if there is something that's not formatted correctly? (I think we already have this? Not sure)

Yes, we would commit the formatted code straight back.

What we have now with the primitive formatting check is it creates opportunity for the PR to fail the CI.

With an automatic formatting tool, we can simply fix the code and move on with our lives. No nitpicking, no asking how do I fix this error, just ready to merge code!

On Monday, 22 January 2024 at 16:24:48 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 23/01/2024 4:14 AM, Prajwal S N wrote:
>> I came across this suggestion from Rikki in one of the other threads, and just wanna make sure I understand correctly - we'd ideally want a CI job that runs dfmt on the PR, and in case of any reformatting, it pushes a commit with those changes. Or are we just looking for a job that detects if there is something that's not formatted correctly? (I think we already have this? Not sure)
>
> Yes, we would commit the formatted code straight back.
>
> What we have now with the primitive formatting check is it creates opportunity for the PR to fail the CI.
>
> With an automatic formatting tool, we can simply fix the code and move on with our lives. No nitpicking, no asking how do I fix this error, just ready to merge code!

You really want a bot to commit in the author branch ? Maybe you mean that this should be done as part of the merge process ? BTW authors have an option to prevent external modifications even if the "external agent" has the permissions to modify, e.g in the context of an organization.

On Monday, January 22, 2024 9:24:48 AM MST Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> On 23/01/2024 4:14 AM, Prajwal S N wrote:
> > I came across this suggestion from Rikki in one of the other threads, and just wanna make sure I understand correctly - we'd ideally want a CI job that runs dfmt on the PR, and in case of any reformatting, it pushes a commit with those changes. Or are we just looking for a job that detects if there is something that's not formatted correctly? (I think we already have this? Not sure)
>
> Yes, we would commit the formatted code straight back.
>
> What we have now with the primitive formatting check is it creates opportunity for the PR to fail the CI.
>
> With an automatic formatting tool, we can simply fix the code and move on with our lives. No nitpicking, no asking how do I fix this error, just ready to merge code!

Please, no. Code formatters consistently make code look like garbage. Some flexbility is needed if we want code to actually look nice.

- Jonathan M Davis

On 23/01/2024 12:10 PM, Jonathan M Davis wrote:
> Please, no. Code formatters consistently make code look like garbage. Some
> flexbility is needed if we want code to actually look nice.

There is always flexibility, by turning off the formatter for a given block and formatting manually.

However, 'looks like garbage' is subjective. For instance I think anything that uses the D style guidelines is inherently garbage. But yet I am still forced to write code that way if I want to contribute.

It is a choice, you either value peoples contributions more than you do what style they wrote it in, or you value the ability to nitpick it. As far as I'm concerned we need to value contributions significantly more and that includes making the CI not fail over something it can correct.

On Monday, 22 January 2024 at 23:10:06 UTC, Jonathan M Davis wrote:
> Please, no. Code formatters consistently make code look like garbage. Some flexbility is needed if we want code to actually look nice.
>
> - Jonathan M Davis

For a large project like this with many contributors, consistency is more important than personal aesthetic preferences.

On Tuesday, January 23, 2024 5:49:28 PM MST Meta via Digitalmars-d wrote:
> On Monday, 22 January 2024 at 23:10:06 UTC, Jonathan M Davis
>
> wrote:
> > Please, no. Code formatters consistently make code look like garbage. Some flexbility is needed if we want code to actually look nice.
> >
> > - Jonathan M Davis
>
> For a large project like this with many contributors, consistency is more important than personal aesthetic preferences.

My complaint isn't about that. My complaint is that when you have a formatter do it, the code always ends up looking ugly no matter the rules used, because it's too inflexible about it. We already have a style guide (and have had for years), and it's fairly straightforward. When a human follows it, there is some flexibility, because the guide has some flexibility, and so the human can make intelligent decisions about things like line breaks, whereas the formatter is going to be dumb about it and apply a much more exact set of rules that then result in things like breaking up the code in places which make the code harder to read.

Formatters always result in terrible looking code. Obviously, if you prefer the target coding style, it's going to look better than if you don't, but computers have zero aesthetics, so the results always have issues. Of course, the advantage is that you can then just tell folks to use the formatter (or automate the process), and then there are no arguments over the result (which is obviously which folks like to use formatters), but the result is always terrible, which is why I'd much prefer that any project that I work on not use a formatter. At least if the process involves a bot telling you that the code failed some style rule, the human can fix it in an intelligent manner, whereas the formatter is just going to uglify the code in the process.

- Jonathan M Davis

On Tue, Jan 23, 2024 at 06:11:00PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Tuesday, January 23, 2024 5:49:28 PM MST Meta via Digitalmars-d wrote:
> > On Monday, 22 January 2024 at 23:10:06 UTC, Jonathan M Davis
> >
> > wrote:
> > > Please, no. Code formatters consistently make code look like garbage. Some flexbility is needed if we want code to actually look nice.
> > >
> > > - Jonathan M Davis
> >
> > For a large project like this with many contributors, consistency is more important than personal aesthetic preferences.
> 
> My complaint isn't about that. My complaint is that when you have a formatter do it, the code always ends up looking ugly no matter the rules used, because it's too inflexible about it. We already have a style guide (and have had for years), and it's fairly straightforward. When a human follows it, there is some flexibility, because the guide has some flexibility, and so the human can make intelligent decisions about things like line breaks, whereas the formatter is going to be dumb about it and apply a much more exact set of rules that then result in things like breaking up the code in places which make the code harder to read.
[...]

I agree, but there's no reason we can't have both.  If the formatter is
messing things up in a particular bit of code, just wrap it with
`// dfmt off` and `// dfmt on` and format it however you please.


T

-- 
Curiosity kills the cat. Moral: don't be the cat.

On Wednesday, 24 January 2024 at 01:11:00 UTC, Jonathan M Davis wrote:
> On Tuesday, January 23, 2024 5:49:28 PM MST Meta via Digitalmars-d wrote:
>> On Monday, 22 January 2024 at 23:10:06 UTC, Jonathan M Davis
>>

I think that we can use dfmt to automatically fix trivial things such as the number of spaces between an `if` and a `(`, but leave the more complicated stuff such as line breaks to the human.

We can have best of both worlds.

RazvanN

On Wednesday, 24 January 2024 at 01:11:00 UTC, Jonathan M Davis wrote:
>
> My complaint isn't about that. My complaint is that when you have a formatter do it, the code always ends up looking ugly no matter the rules used, because it's too inflexible about it. [..]

In general, I agree with your sentiment. However it also heavily depends on the quality of implementation of the formatter, i.e. the combination of objective rules and subjective heuristics it applies.

For example, for the past 4-5 years I've had to maintain various projects written in TypeScript at work. I have yet to find an instance where a `*.[t|j]sx?` file is formatted with Prettier [0] and I don't like the end-result.
On the other hand, I've also worked on projects written in Go, and in general I don't find the result of running `go fmt` particularly pleasing, but it's tolerable. (But maybe that's because no matter how you format Go code it will always look ugly, unlike D :D)

[0]: https://prettier.io/