[llvm-dev] RFC: changing variable naming rules in LLVM codebase (original) (raw)
via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 22 07:59:07 PST 2019
- Previous message: [llvm-dev] RFC: changing variable naming rules in LLVM codebase
- Next message: [llvm-dev] RFC: changing variable naming rules in LLVM codebase
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I had posted something in the code review but Chris suggested doing it here instead, which makes sense. Also I have to remember that the discussion is specifically about spelling variables, not changing any other spelling conventions.
Looking at names of "variables" there's reasonable support for making them visually more distinct from other kinds of names. Regarding making data-member names distinct from local variables, some people don't see why it should matter, others find it helpful; given this neutral-to-helpful spectrum, going with the kind-of helpful convention seems preferable.
So:
- Local variables and formal parameters should be lower_case, with one exception: Variables/parameters that have lambda/function type should follow the function-name spelling rules.
- Class data members should have an "m_" prefix, so m_lower_case.
- Initialisms and other abbreviations would be considered words for this purpose, so we have names such as: tli // Local variable for TargetLoweringInfo m_cgm // Data member for CodeGenModule
- I don't have a good suggestion for file-static/global variables. Some people have suggested a "g_" prefix for globals, or possibly an "s_" prefix for class-static data.
Regarding the transition:
Some people have worried that the churn will cause blame issues. I respectfully point out that in my own archaeology I have to deal with lots of clang-format/indentation/other random semantically meaningless refactoring, this is just one more. Also the point is not to optimize for git-blame but to optimize for reading what is there at the moment.
A more focused and shorter transition period will create a lot of
short-term churn but get us to the good endpoint sooner. Doing
conversions per-file or per-class (rather than per-function [too
small] or per-library [too big]) are probably the way to go.
Given we are changing the names used for data, and we try to
practice good data-hiding, the impact of the conversion of any
given class ought to be reasonably confined.
If someone can make clang-tidy help with this, that's awesome.
I'm almost afraid to make the next suggestion, but here goes: In more complicated/wide-impact cases, it would be possible to stage a data-member name conversion into "small-bang" iterations using a C++ tactic like this: class Foo { int m_bar; // The renamed member. int &Bar = m_bar; // TEMPORARY alias using the old name. }; This would have to be done sparingly and for good reason, such as when the names are known across many components/subprojects and doing them all at once would be really too much. Someone would have to commit to getting it all done and removing the aliases in a reasonably short period of time. Needing to do this trick would be (IMO) strong evidence of poor software design and a place to focus some refactoring effort.
HTH, --paulr
- Previous message: [llvm-dev] RFC: changing variable naming rules in LLVM codebase
- Next message: [llvm-dev] RFC: changing variable naming rules in LLVM codebase
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]