[PATCH] D145435: Choose style (file) from within code for use in IDEs

Thu Mar 9 04:34:20 PST 2023

HazardyKnusperkeks added a comment.

In D145435#4179662 <https://reviews.llvm.org/D145435#4179662>, @owenpan wrote:

> In D145435#4179308 <https://reviews.llvm.org/D145435#4179308>, @bersbersbers wrote:
>
>> In D145435#4173875 <https://reviews.llvm.org/D145435#4173875>, @owenpan wrote:
>>
>>> Please refer to D125171#4167866 <https://reviews.llvm.org/D125171#4167866> to make the case that such a feature should be added.
>>>
>>> - have a publicly accessible style guide
>>
>> I am not sure what a "style guide" might be in my case, and I'd be happy about any clarification. Might that simply be documentation?
>
> An example of publicly accessible style guides would be https://google.github.io/styleguide/cppguide.html#Formatting. Nevertheless, it's unlikely your proposed new feature is covered by any style guides.
>
>> In D145435#4176279 <https://reviews.llvm.org/D145435#4176279>, @owenpan wrote:
>>
>>> I don't understand why anyone wants to do this. [...] If I lock down the style for the files I created as this requested feature allows, what would happen if others need to maintain these files down the road?
>>
>> I see a number of settings where people might want this:
>>
>> - Teams not (fully) agreeing on a common style, with different people using different styles (such as `BS_Allman` vs `BS_Attach`). Not saying that should be allowed in every project, but I can easily see how allowing it can avoid conflicts if users can just impose their own style on the files they maintain. (Note that this is already possible, but only by moving each user's file into a separate directory. The proposed patch will just make it easier.)
>
> I don't think the purpose of supporting per-directory config files is to allow different users to have different styles within the same codebase.
>
>> - If the previous point sounds like opening the code base for style chaos (in fact, your final question appears to suggest that a per-file style will always be incompatible with the directory style), note there can be very benign examples. A team may have agreed on a 120 column limit, but they have a file that is diffed very often and for which it makes sense to have an 80 column limit. With the proposed style comment, you can enforce that locally. Note that such a file does not go against the 120 column limit, so no one is breaking any agreed-upon rules, and no other maintainer should have a problem with that file. Another example is `MaxEmptyLinesToKeep`: a team may have agreed on 3 (or no limit at all), but one maintainer likes to keep their code vertically short at works using `MaxEmptyLinesToKeep: 1`. That file will still be compliant with the agreed-upon style.
>> - Code and style are self-contained in a single file. If you move a file from one directory to another, it will continue to use the same style, even if the two folders use different .clang-format files. (Not saying this has to be done, but it's nice to have the option.) If you email/scp/... the file to someone, the recipient knows the format and can easily format after making changes.
>
> Are the settings above hypothetical or are they real-world use cases?
>
> IMO, if people really want to have per-file configurations, they can do so outside of clang-format, e.g. using grep in a shell script.

Although I don't think I will use that feature, I still think it might be useful and doesn't really hurt anyone. I can't give you any examples right now, but more than once I wished I could change the style **within** the file, right now I just do `// clang-format off` or accept that the code doesn't look like I want to.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145435/new/

https://reviews.llvm.org/D145435