[llvm-dev] RFC: changing variable naming rules in LLVM codebase

Michael Kruse via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 22 12:38:12 PST 2019

Am Fr., 22. Feb. 2019 um 09:59 Uhr schrieb via llvm-dev
<llvm-dev at lists.llvm.org>:
> 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.

If the goal of prefixes is to visually distinguish different scopes:
Some IDEs/editors support semantic code highlighting [1], i.e. assign
different colors to local/global/static variables/members/parameters.
I know at least the following support this natively: KDevelop [1],
Visual Studio [2], Eclipse CDT [3]


[1] https://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from-syntax-highlighting-to-semantic-highlighting/
[2] https://devblogs.microsoft.com/cppblog/first-look-at-the-new-c-ide-productivity-features-in-visual-studio-11/
[3] https://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.cdt.doc.user%2Freference%2Fcdt_u_c_editor_color.htm

More information about the llvm-dev mailing list