[llvm-dev] Variable names rule

[Chris Lattner via llvm-dev]

> On Feb 1, 2019, at 6:20 AM, Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi all,
>  
> As application of the naming rules are currently under discussion [1] this seems like a good time to bring this up:
>  
> The current variable naming rule [2] 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" [3].

I completely agree with you that our variable naming rule is broken.  This discussion has been brought up before (e.g. http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html <http://lists.llvm.org/pipermail/llvm-dev/2014-October/077685.html>) and hasn’t made any progress - people seem to not be willing to make a change, e.g. saying "the cure is worse than the disease".  I’m personally in favor of Nick’s proposal (linked above) which makes variable names and function names be lower camel case.  

The Swift language world (a developer community several orders of magnitude larger than LLVM’s) uses this convention very successfully and people seem very happy with it.  Swift also has a very carefully considered API design guide (https://swift.org/documentation/api-design-guidelines/ <https://swift.org/documentation/api-design-guidelines/>), which applies quite well to C++ APIs as well.  If you haven’t seen it, it is worth a look.

Using camel case for one thing and snake case for another is too weird IMO.


Even if the community does not have the appetite to do a huge scale renaming of all the things in LLVM, it would be interesting to carve out an exception for new code being written, refactored, or potentially for use in new subprojects.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190202/4a3dfda0/attachment.html>