[llvm-dev] Variable names rule
Amara Emerson via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 1 18:49:45 PST 2019
Is moving to snake_case and the resulting inconsistency in the naming conventions worth the benefits? A wholesome change is out of the question.
> On 1 Feb 2019, at 06:20, Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Hi all,
> As application of the naming rules are currently under discussion  this seems like a good time to bring this up:
> The current variable naming rule  states: Variable names should be nouns (as they represent state). The name should be camel case, and start with an upper case letter (e.g. Leader or Boats).
> I'm a relatively new arrival to the LLVM codebase and I want to follow the rules wherever I can, but I humbly submit that this rule is suboptimal for readable code.
> The rationale given at the time this rule was added was "document the prevailing convention" . It was debated after the policy change whether this was the right choice .
> The main problem I find with this rule is that it is the same as the type naming rule. Why is this a problem? It is famously hard to name things ("There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.") and with this rule if you've already used a name for a type, you can't reuse it for a variable of that type.
> So what do you do instead? Often it seems the answer is to use an acronym (Target T), which hurts readability, or prepend "The" to the type name (Target TheTarget), which wastes space and also hurts readability because the start and end of a word are the most important for readnig. 
> So we've got declarations like "LB(L, PSE, LI, DT, TLI, TTI, AC, ORE, VF.Width, IC, &LVL, &CM)"  which is quite intimidating to newcomers.
> If we could also use snake_case variable names then straight away you have an obvious, readable name (Target target). It looks like there's plenty of code that does this already, and it's consistent with our Python code. Also, it makes C idioms like "for (int i = 0; ..." permissible.
> I realize that there's also a rule  "Avoid abbreviations unless they are well known" - I believe allowing a trivial way to get readable names would help greatly to adhere to this.
> What do you think? Could we relax the variable naming rule?
>  http://lists.llvm.org/pipermail/cfe-dev/2019-January/061085.html <http://lists.llvm.org/pipermail/cfe-dev/2019-January/061085.html>
>  https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly <https://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly>
>  https://github.com/llvm/llvm-project/commit/30e697ebaf4fc8a9b8cf6abecbc75ef1b9fa0dc0 <https://github.com/llvm/llvm-project/commit/30e697ebaf4fc8a9b8cf6abecbc75ef1b9fa0dc0>
>  http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20110808/126097.html <http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20110808/126097.html>
>  Mostly based on my own experience, but somewhat supported by evidence:https://en.wikipedia.org/wiki/Transposed_letter_effect <https://en.wikipedia.org/wiki/Transposed_letter_effect>
>  https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp#L7433 <https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp#L7433>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev