Hi,<div><br></div><div>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.</div>
<div><br><div class="gmail_quote">2010/11/23 Zhanyong Wan (λx.x x) <span dir="ltr"><<a href="mailto:wan@google.com">wan@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Mon, Nov 22, 2010 at 11:41 PM, Zhanyong Wan (λx.x x) <<a href="mailto:wan@google.com">wan@google.com</a>> wrote:<br>
> +llvmdev<br>
><br>
> Thanks for the comments, Chris.<br>
><br>
> On Mon, Nov 22, 2010 at 11:08 PM, Chris Lattner <<a href="mailto:clattner@apple.com">clattner@apple.com</a>> wrote:<br>
>><br>
>> On Nov 22, 2010, at 5:16 PM, Zhanyong Wan (λx.x x) wrote:<br>
>><br>
>>> Hi guys,<br>
>>><br>
>>> Based on our discussion last week, I put together a new coding style<br>
>>> rule regarding the naming of types/functions/variables. I've uploaded<br>
>>> the patch to<br>
>>><br>
>>> <a href="http://codereview.appspot.com/3264041" target="_blank">http://codereview.appspot.com/3264041</a><br>
>>><br>
>>> Please let me know what you think. My idea is to start with something<br>
>>> non-controversial such that we can get the baseline committed soon.<br>
>>> We can then tweak the rule as needed later to cover more specific<br>
>>> scenarios. Thanks,<br>
>><br>
>> I think that the type/function name convention makes sense.<br>
>><br>
>> However, I don't fully agree for local variable names. For them, there are two cases, things with small lifetimes where having a simple short name is good, and things with longer lifetimes where you want something descriptive.<br>
>><br>
>> For example, naming a variable i here is perfectly fine:<br>
>><br>
>> for (unsigned i = 0; i != 100; ++i)<br>
>> A[i] = 0;<br>
>><br>
>> Naming it "ArrayIndex" would not make it more clear :)<br>
><br>
> Good point. I actually have this in the example:<br>
><br>
> 828 VehicleMaker m; // Bad (abbreviation and non-descriptive); might be<br>
> 829 // OK for a local variable if its role is obvious.<br>
><br>
> I'll reword the rule to match what you have in mind.<br>
<br>
</div>I've made the change and uploaded the new patch to<br>
<a href="http://codereview.appspot.com/3264041" target="_blank">http://codereview.appspot.com/3264041</a> -- you can also find it attached<br>
to this message. Thanks,<br>
<div><div></div><div class="h5"><br>
><br>
>> For capitalization, I generally prefer capital names with the exception being one character names that are often metasyntactic names (like i/j).<br>
><br>
> If possible, I'd prefer that all variable names have the same style.<br>
> I'm afraid that we'll end up with the current inconsistent style if we<br>
> leave it to people to interpret whether a name is metasyntactic and<br>
> thus should be lower-case.<br>
><br>
> Also, having both types and variables in StrictCamelCase increases the<br>
> chance of clashing between the two and thus sometimes makes it hard to<br>
> choose good variable names. For example, if you have a function that<br>
> takes a Type parameter, how would you name the parameter if it has to<br>
> start with an upper-case? There are several obvious choices:<br>
><br>
> void VisitType(Type T); // Bad -- T is too generic and could be<br>
> mistaken for "temporary".<br>
> void VisitType(Type Ty); // Bad -- Ty is not a well-known abbreviation.<br>
> void VisitType(Type AType); // Unnecessarily awkward.<br>
><br>
> In contrast,<br>
><br>
> void VisitType(Type type);<br>
><br>
> is readable and natural. The same argument applies to other kinds of variables.<br>
><br>
> Another reason for preferring lower-case-started variable names is, as<br>
> I wrote in the proposed rule, it helps a lot with readability to know<br>
> at a glance whether something is a type or not -- at least that's my<br>
> experience.<br>
><br>
> So, would you be fine with making all variables start with lower-case?<br>
><br>
>> Also, since this applies to LLVM as a whole, I'd suggest moving this to llvmdev, which will reach a larger audience.<br>
><br>
> Good point. Done. Hopefully this doesn't bring on bike shedding. ;-)<br>
><br>
> --<br>
> Zhanyong<br>
><br>
<br>
<br>
<br>
</div></div>--<br>
<font color="#888888">Zhanyong<br>
</font><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>