[Swift-devel] Naming convention discussion

[Tim Armstrong]

If you're in favour of camel case, Mihael, I'd support that.  I guess it
saves a few characters :).

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

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.


On Sun, Jan 11, 2015 at 9:06 PM, Ketan Maheshwari <ketan at mcs.anl.gov> wrote:

> 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.
>
> On Sat, Jan 10, 2015 at 11:41 PM, Mihael Hategan <hategan at mcs.anl.gov>
> wrote:
>
>> Just changing subject to reduce confusion.
>>
>> On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote:
>> > I'm actually pretty indifferent :)  I switch between the two styles so
>> much
>> > anyway.
>> >
>> > - Tim
>> >
>> > On Sat, Jan 10, 2015 at 10:02 PM, Mihael Hategan <hategan at mcs.anl.gov>
>> > wrote:
>> >
>> > > On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote:
>> > > > I agree, I don't care about the naming convention for functions, so
>> let's
>> > > > just pick one and be consistent going forward (we can keep old names
>> > > > around, at least forsome amount of time).
>> > >
>> > > Let's briefly discuss this and put it to a vote.
>> > >
>> > > I prefer camel case because it helps with tokenization in my head. In
>> > > other words when I read a program, I would like a variable or function
>> > > name to be a single entity visually. Underscores are very close to a
>> > > blank, so it's easy to confuse the two on a quick visual scan and
>> > > interpret, say function_name, as two separate tokens instead of one.
>> > >
>> > > Other than that, complex tokens themselves are probably easier to read
>> > > with underscores: long_name_of_variable_that_holds_value vs
>> > > longNameOfVariableThatHoldsValue.
>> > >
>> > > See http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.158.9499
>> and
>> > >
>> > >
>> http://www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
>> > > for some relevant research. Unfortunately they focus not on program
>> > > readability, but on identifier readability.
>> > >
>> > > Mihael
>> > >
>> > >
>>
>>
>> _______________________________________________
>> Swift-devel mailing list
>> Swift-devel at ci.uchicago.edu
>> https://lists.ci.uchicago.edu/cgi-bin/mailman/listinfo/swift-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150112/1ae2b38c/attachment.html>