digitalmars.D - Automating formatting for official D repos
- Prajwal S N (7/7) Jan 22 I came across this suggestion from Rikki in one of the other
- Richard (Rikki) Andrew Cattermole (7/13) Jan 22 Yes, we would commit the formatted code straight back.
- Basile B. (7/21) Jan 22 You really want a bot to commit in the author branch ? Maybe you
- Jonathan M Davis (5/18) Jan 22 Please, no. Code formatters consistently make code look like garbage. So...
- Richard (Rikki) Andrew Cattermole (10/12) Jan 22 There is always flexibility, by turning off the formatter for a given
- Meta (4/8) Jan 23 For a large project like this with many contributors, consistency
- Jonathan M Davis (22/31) Jan 23 My complaint isn't about that. My complaint is that when you have a
- RazvanN (7/11) Jan 24 I think that we can use dfmt to automatically fix trivial things
- Petar Kirov [ZombineDev] (16/20) Jan 24 In general, I agree with your sentiment. However it also heavily
- H. S. Teoh (8/31) Jan 23 [...]
- kdevel (6/10) Jan 24 What if a contributor thinks their whole code shall be exempt
- Richard (Rikki) Andrew Cattermole (4/17) Jan 24 We do the same thing we do today if someone disables style checks
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)
Jan 22
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!
Jan 22
Basile B. <b2.temp gmx.com> 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: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.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!
Jan 22
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:Please, no. Code formatters consistently make code look like garbage. Some flexbility is needed if we want code to actually look nice. - Jonathan M DavisI 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!
Jan 22
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.
Jan 22
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 DavisFor a large project like this with many contributors, consistency is more important than personal aesthetic preferences.
Jan 23
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: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 DavisPlease, no. Code formatters consistently make code look like garbage. Some flexbility is needed if we want code to actually look nice. - Jonathan M DavisFor a large project like this with many contributors, consistency is more important than personal aesthetic preferences.
Jan 23
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: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. RazvanNOn Monday, 22 January 2024 at 23:10:06 UTC, Jonathan M Davis
Jan 24
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/
Jan 24
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:[...] 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 Monday, 22 January 2024 at 23:10:06 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. 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.Please, no. Code formatters consistently make code look like garbage. Some flexbility is needed if we want code to actually look nice. - Jonathan M DavisFor a large project like this with many contributors, consistency is more important than personal aesthetic preferences.
Jan 23
On Monday, 22 January 2024 at 16:24:48 UTC, Richard (Rikki) Andrew Cattermole wrote:[...] 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!What if a contributor thinks their whole code shall be exempt from reformatting by putting // dfmt off in the very first line of the translation unit?
Jan 24
On 25/01/2024 10:36 AM, kdevel wrote:On Monday, 22 January 2024 at 16:24:48 UTC, Richard (Rikki) Andrew Cattermole wrote:We do the same thing we do today if someone disables style checks without a very good reason. Push back and get them to turn it back on.[...] 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!What if a contributor thinks their whole code shall be exempt from reformatting by putting // dfmt off in the very first line of the translation unit?
Jan 24