<div dir="ltr"><div>If you're in favour of camel case, Mihael, I'd support that.  I guess it saves a few characters :).<br><br>sqrt and pow are pretty much universal, so I agree with that.  I think it's a little tricky to work out whether to abbreviate or not in general (e.g. length versus len).<br><br>Though, strcat, strlen, etc are really a C-ism that a few languages have copied (Perl, PHP as far as I know for mainstream languages).  Most languages don't follow that naming scheme so almost all users would have used a language where the str* naming convention wasn't used, and many users would have never used a language where the str* naming convention was used.  So I don't think familiarity is enough of a factor to justify being inconsistent in our naming.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 11, 2015 at 9:06 PM, Ketan Maheshwari <span dir="ltr"><<a href="mailto:ketan@mcs.anl.gov" target="_blank">ketan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think uniformity is good but not at the cost of readability/familiarity. Names with both camel case and underscores could be allowed on case by case basis. In some cases even common C-like function names such as strcat, sqrt etc. might be allowed. Users who have even a little familiarity with C will probably know what strcat, pow etc. functions do. So, I am more inclined towards letting go of uniformity in favor of familiarity. Just my opinion.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sat, Jan 10, 2015 at 11:41 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Just changing subject to reduce confusion.<br>
<br>
On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote:<br>
> I'm actually pretty indifferent :)  I switch between the two styles so much<br>
> anyway.<br>
><br>
> - Tim<br>
><br>
> On Sat, Jan 10, 2015 at 10:02 PM, Mihael Hategan <<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>><br>
> wrote:<br>
><br>
> > On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote:<br>
> > > I agree, I don't care about the naming convention for functions, so let's<br>
> > > just pick one and be consistent going forward (we can keep old names<br>
> > > around, at least forsome amount of time).<br>
> ><br>
> > Let's briefly discuss this and put it to a vote.<br>
> ><br>
> > I prefer camel case because it helps with tokenization in my head. In<br>
> > other words when I read a program, I would like a variable or function<br>
> > name to be a single entity visually. Underscores are very close to a<br>
> > blank, so it's easy to confuse the two on a quick visual scan and<br>
> > interpret, say function_name, as two separate tokens instead of one.<br>
> ><br>
> > Other than that, complex tokens themselves are probably easier to read<br>
> > with underscores: long_name_of_variable_that_holds_value vs<br>
> > longNameOfVariableThatHoldsValue.<br>
> ><br>
> > See <a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499" target="_blank">http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499</a> and<br>
> ><br>
> > <a href="http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf" target="_blank">http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf</a><br>
> > for some relevant research. Unfortunately they focus not on program<br>
> > readability, but on identifier readability.<br>
> ><br>
> > Mihael<br>
> ><br>
> ><br>
<br>
<br></div></div>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu" target="_blank">Swift-devel@ci.uchicago.edu</a><br>
<a href="https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel" target="_blank">https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel</a><br>
</blockquote></div><br></div>
</blockquote></div><br></div>