[Swift-devel] Naming convention discussion

[Ketan Maheshwari]

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/20150111/8acb66cd/attachment.html>