Agreed.  Perl borrows vocabulary almost exclusively from English, but it is
not English, and its conventions are not those of English.  (And the
conventions around hyphens that people are citing are quite specifically
those of standard written English; other writing systems, even those using
the same alphabet and mostly the same punctuation, have different rules).

I would personally like to see hyphens used as the standard word separator,
with underscores available for exceptions - say, naming a Perl interface
method exactly the same as the underlying C function it provides access to.
 I'd be less happy with underscores everywhere, but either of those
solutions is better (IMESHO) than mixing hyphens and underscores, which
should be avoided even within an API, never mind a single identifier.


On Sat, Apr 10, 2010 at 8:55 PM, John Siracusa <sirac...@gmail.com> wrote:

> On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso <dan...@ruoso.com> wrote:
> > Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu:
> >> I'm having trouble imaging any convention that involves mixing word
> >> separators being successful.
> >
> > But the convention Damian is proposing is simply "use underscores".
> >
> > Basically camelCase and with_underscores are conventions on "how to
> > circunvent the fact that we can't use spaces in our identifiers". What
> > is proposed here is that the p5 convention should be preserved.
> >
> > The hyphen is *not* a space, so it doesn't even get into the discussion
> > of this convention. The basic difference is that when a programmer with
> > sufficient communication skills have a composed word (i.e.: week-day),
> > he will have the ability to use the hyphen instead of either supress it
> > or use an underscore...
>
> These nuances are exactly what will be lost on people who see classes
> that use both underscores and hyphens in their method names.
>
> -John
>



-- 
Mark J. Reed <markjr...@gmail.com>

Reply via email to