search for: m_cgm

...on 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...

...tiple dev threads plus a Phabricator review. Not optimal, but that's what it is. > > > - 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 actually think we need something stronger. Acronyms should be > discouraged unless it's absolutely clear what it is. As has been > pointed out, "tli" means at least two common and very different things: > "TargetLoweringInf...

...or something other than emulating a function call? > > I think the simple rule is superior. > > - 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 >> > > Agreed. > > >> - 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. &gt...

> On Feb 19, 2019, at 7:43 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, 19 Feb 2019 at 15:24, Zachary Turner <zturner at google.com> wrote: >> On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Regarding a plan for conversion, I'm keen to avoid perfect