preferred automated StyleGuide style? pre-review for pending submissions #354
-
|
I'm working on a contribution (maybe a series thereof, though I think that'll make the total work greater) that will be of non-trivial size. Various parts of it used at least three different abstractions over FastLED/AdaFruit and I've seen evidence of the same number of programmer (presumed) native languages. (My favorite is moving 1,1 from between the UL and LL corner in an effect...) Sometimes I replaced and sometimes I shimmed, but I'm getting to a pretty happy place with them. I've been keeping translation windows open for Russian, Portuguese, and Polish. However, there are deep style cracks everywhere if carefully scrutinized. If I tried to tackle them all, it's a deadlock AND it would make it more difficult to integrate further drops from the upstream projects. Is "clang-format --style=microsoft" generally close enough to acceptable for the reviewers here to clear the bar? Google has further style integrations into clang-tidy(?) that checks things like class names having FooNames and member names having foo_names_ and variables having foo_names and the order of include blocks a basically enshrines in policy every hour-long nerd-war during a code review ever and is accessible right from the review screen. Are there similar tools of automation recommended here? (Simonyi-style naming notation is right out of the question, though I've seen only a small amount of that here...) |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
|
I'd say the mix of coding styles is prevalent throughout the project. I think some of it is a testament to the actual age of the project, as well as the gradual development it has undergone for most of its existence. On the one hand I think the implementation of a certain level of style uniformity would be beneficial, but:
Back to your question: I don't have a strong opinion on the one style to aim to standardize towards, but maybe @davepl does. I do think that if and when we commit to applying automation to checking style within the project, we should do so project-wide and also commit to fixing whatever is found - otherwise the flags raised by the automation will become meaningless within days. Which brings me back to the last two bullets in the above list. |
Beta Was this translation helpful? Give feedback.
-
|
I code in what’s known as the Cairo coding style, since that’s when I was imprinting on the big ducks :-)
Basically, follow whatever convention is in the surrounding code. If creating a new file, follow the pattern set out into existing file closest in purpose to your own.
One I had to work in User32, which was not in the Cairo style. It was more
If (foo) {
// stuff
} else {
// otherstuff
}
… but I wrote in the Cairo style
If (foo)
{
}
else
{
}
…and got taken to task for that! So, my rule is write in the style of the file.
- Dave
… On Jul 11, 2023, at 2:10 AM, Rutger van Bergen ***@***.***> wrote:
I'd say the mix of coding styles is prevalent throughout the project. I think some of it is a testament to the actual age of the project, as well as the gradual development it has undergone for most of its existence.
On the one hand I think the implementation of a certain level of style uniformity would be beneficial, but:
A mix of styles will remain in the effective sense, due to dependencies using different ones
Applying whatever coding style we choose throughout the codebase is a Pretty Big Job
It's not at the top of my personal list of priorities
Back to your question: I don't have a strong opinion on the one style to aim to standardize towards, but maybe @davepl <https://github.com/davepl> does. I do think that if and when we commit to applying automation to checking style within the project, we should do so project-wide and also commit to fixing whatever is found - otherwise the flags raised by the automation will become meaningless within days. Which brings me back to the last two bullets in the above list.
—
Reply to this email directly, view it on GitHub <#354 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF2V2YGXBEVXFGQDTJLXPUKBZANCNFSM6AAAAAA2FMKEMY>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
One other style point - I like flat code. Code that is procedural, not deeply nested classes where the behavior is implicit in the declaration of a bunch of templates!
Simple is good, elegant is better, but complicated should be reserved for things that need it! So, keep it simple and readable :-)
- Dave
… On Jul 11, 2023, at 10:53 AM, Dave Plummer ***@***.***> wrote:
I code in what’s known as the Cairo coding style, since that’s when I was imprinting on the big ducks :-)
Basically, follow whatever convention is in the surrounding code. If creating a new file, follow the pattern set out into existing file closest in purpose to your own.
One I had to work in User32, which was not in the Cairo style. It was more
If (foo) {
// stuff
} else {
// otherstuff
}
… but I wrote in the Cairo style
If (foo)
{
}
else
{
}
…and got taken to task for that! So, my rule is write in the style of the file.
- Dave
> On Jul 11, 2023, at 2:10 AM, Rutger van Bergen ***@***.***> wrote:
>
>
> I'd say the mix of coding styles is prevalent throughout the project. I think some of it is a testament to the actual age of the project, as well as the gradual development it has undergone for most of its existence.
>
> On the one hand I think the implementation of a certain level of style uniformity would be beneficial, but:
>
> A mix of styles will remain in the effective sense, due to dependencies using different ones
> Applying whatever coding style we choose throughout the codebase is a Pretty Big Job
> It's not at the top of my personal list of priorities
> Back to your question: I don't have a strong opinion on the one style to aim to standardize towards, but maybe @davepl <https://github.com/davepl> does. I do think that if and when we commit to applying automation to checking style within the project, we should do so project-wide and also commit to fixing whatever is found - otherwise the flags raised by the automation will become meaningless within days. Which brings me back to the last two bullets in the above list.
>
> —
> Reply to this email directly, view it on GitHub <#354 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF2V2YGXBEVXFGQDTJLXPUKBZANCNFSM6AAAAAA2FMKEMY>.
> You are receiving this because you were mentioned.
>
|
Beta Was this translation helpful? Give feedback.
-
|
Cool. I can work with either. I also went from a UNIX shop using AT&T style to Google which maximizes information density on the screen. I was actually looking for more nuanced points like identifier names and such, but I'll apply my IRL rule of "leave it better than you found it and don't stress that it's not someone else's idea of perfect" and move along. Since I'm starting with code that came from a variety of sources and authors in a variety of (human) languages, that's probably clang-format, sweetened to taste. Post-question related question: Is there any kind of automated test suite (beyond buddy-build) that renders into an SDL window for a sanitizer build or things like tweaks in the telnet window to turn on more checking or such? Is there any higher bar than just running for a while? |
Beta Was this translation helpful? Give feedback.
I'd say the mix of coding styles is prevalent throughout the project. I think some of it is a testament to the actual age of the project, as well as the gradual development it has undergone for most of its existence.
On the one hand I think the implementation of a certain level of style uniformity would be beneficial, but:
Back to your question: I don't have a strong opinion on the one style to aim to standardize towards, but maybe @davepl does. I do think th…