Identifier naming inconsistencies in clang

Hi Team,

So... my IDE has settings to recognize identifier naming conventions
and it's constantly flagging various bits of clang code as not
following the convention, typically:

- Methods/functions that don't begin with lower-case letter
- Variables that don't begin with upper-case character
- Occasionally methods/variables using underscores as word separators

Is it acceptable to submit NFC refactoring changes that address the
inconsistencies or does it require a phabricator review?

Thanks,

-- Richard

The coding guidelines here https://llvm.org/docs/CodingStandards.html#introduction say

“There are some conventions that are not uniformly followed in the code base (e.g. the naming convention). This is because they are relatively new, and a lot of code was written before they were put in place. Our long term goal is for the entire codebase to follow the convention, but we explicitly do not want patches that do large-scale reformatting of existing code. On the other hand, it is reasonable to rename the methods of a class if you’re about to change it in some other way. Please commit such changes separately to make code review easier.”

But it has said that for a long time so I don’t know what the feeling is these days.

Some naming violations are deliberate; this is particularly true in llvm/include/ADT, where many classes define methods that intentionally follow the snake_case conventions used by STL. Those should not be changed.

You should feel empowered to update the conventions for code you are working on for other reasons (as separate NFC changes and not requiring a pre-commit review). But going through the entire project to update the conventions would probably be viewed as unnecessary churn, and potentially making life more difficult for people working on those areas.

–paulr

In article <SN4PR13MB5294C51D1BA806C35DFF725F92529@SN4PR13MB5294.namprd13.prod.outlook.com>,
    <paul.robinson@sony.com> writes:

Some naming violations are deliberate; this is particularly true in
llvm/include/ADT, where many classes define methods that intentionally
follow the snake_case conventions used by STL. Those should not be
changed.

Yeah, I noticed some of that too.

You should feel empowered to update the conventions for code you are
working on for other reasons (as separate NFC changes and not requiring a
pre-commit review). But going through the entire project to update the
conventions would probably be viewed as unnecessary churn, and potentially
making life more difficult for people working on those areas.

I was definitely thinking of the former (stuff in clang-tidy and
related code like AST matchers) and not the latter.