[cfe-dev] [LLVMdev] draft rule for naming types/functions/variables

[Chris Lattner]

FYI, I'm dropping cfe-dev from this thread, if you're interested, please follow it on llvmdev.

-Chris


On Nov 29, 2010, at 11:21 AM, Zhanyong Wan (λx.x x) wrote:

> On Mon, Nov 29, 2010 at 12:39 AM, Bo Persson <bop at gmb.dk> wrote:
>> 
>> 
>> 
>> On 29 nov 2010 03:47 "Xu Zhongxing" <xuzhongxing at gmail.com> wrote:
>>> Hi,
>>> I enjoyed the new coding style in recent patches. Camel case makes it
>>> easy to pick a descriptive name. Starting functions and variables with
>>> lower cases reduces chances to conflict with a type name.
>> 
>> On the other hand, having names that only differ in the case of a single character, is not really improving readability at all.
> 
> It depends on what you are comparing with, right?
> 
> 'type' may or may not be a great name for a variable of type (no pun
> intended) Type.  If this variable represents a generic value that can
> be any Type, then 'type' might be as descriptive as you need it to be.
> Otherwise, you might want to pick names like operandType or
> returnType, for example.  In any case, I don't think T, Ty, or AType
> is more readable.
> 
>> In my opinion, this is a misuse of the C family language rules that happen to allow it. In other languages it is forbidden.
> 
> Since changing the C++ language is not an option, we'll have to live
> with its rules and conventions, rather than fighting them.  Note that
> while some languages (e.g. Pascal) have case-insensitive identifiers,
> not all non-C-family languages are like that.  For example, in
> Haskell, the practice of uppercase names for types and lowercase names
> for variables is not only preferred, but actually enforced by the
> compiler.
> -- 
> Zhanyong
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev