Adding a new BasedOnStyle to clang-format with a couple new options (or just adding these options separately) for a project

[ionagamed]

Hey!

https://github.com/ytsaurus/ytsaurus is using a custom styleguide (https://github.com/ytsaurus/ytsaurus/blob/main/yt/styleguide/cpp.md), and we are currently trying to patch clang-format on our side to add some options that we need.

https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options says that in order to merge patches into the upstream repo we need to be a big project with dozens of contributors (which we are), have a publically accessible styleguide (linked above), and have a person willing to contribute and maintain (which we have).

Before we try to make our patches opensource-ready I just wanted to check — do we have a chance of merging some new options here?

[mydeveloperday]

I can't speak for all the maintainers, but generally we welcome new contributions, here is some advice I recently gave to another newcomer

Incase this is your first submission here is some guidance for clang-format commits: (this isn't an exhaustive list)

• Get buy in from the main contributors @owenca , @HazardyKnusperkeks , @rymiel, @mydeveloperday before struggling through a large PR, we want to welcome new comers but we sort of need to have agreement on if we want the change.
• Always add tests
• If you touch TokenAnnotator.cpp then likely you'll need an AnnotatorTest, but a formatting test is good
• We don't use lit tests much but 99% of the time we use the GoogleTests
• Try not to change existing tests
• Always git-clang-format the code before submission
• If you change Format.h you need to regenerate the documentation ClangStyleFormatOptions.rst every time
• Documentation needs to carry a /version when it was introduced if the option is new.
• New options need to carry /code examples
• Backwards compatibility is king! people get grump if we change default behavior.
• Ask yourself does this need a new option or can an existing option support what you need (maybe change it from bool -> enum)
• Begin all commits with [clang-format] in the title
• Adding the people above as reviewer helps your change get attention, some of us have lower cadence than the others (me), my day job gets in the way.
• We really want new features to have a public style guide for a largish open source project that support the feature (not one or two people personal opinion), if you can quote the style guide wanting it that's extra points.
• Don't try and do more than one piece of work at a time.
• Don't change other pieces of code unrelated to your change (do that separately if its important)
• Run all the FormatTests before submitting (this times I've fat fingered that!)
• If you can run the sphinx documentation generation. (harder to setup)

[HazardyKnusperkeks]

I'd say start with the options you need, one per PR, and we see where it will go.