Review of std.net.isemail part 2

[Jonathan M Davis]

On 2011-03-30 11:15, Don wrote:
> Lars T. Kyllingstad wrote:
> > On Wed, 30 Mar 2011 15:04:49 +0200, Don wrote:
> >> Lars T. Kyllingstad wrote:
> >>> On Wed, 30 Mar 2011 13:23:02 +0200, Don wrote:
> >>>> Jonathan M Davis wrote:
> >>>>> On 2011-03-30 01:27, Jacob Carlborg wrote:
> >>>>>> On 3/30/11 1:30 AM, Jesse Phillips wrote:
> >>>>>>> Jacob Carlborg Wrote:
> >>>>>>>> I've made a few minor changes:
> >>>>>>>> 
> >>>>>>>> * Renamed EmailStatusCode.Off ->  None and On ->  Any * Added and
> >>>>>>>> clarified the documentation for EmailStatusCode.Any and None *
> >>>>>>>> Updated the documentation
> >>>>>>>> 
> >>>>>>>> Github: https://github.com/jacob-carlborg/phobos/tree/isemail
> >>>>>>>> Docs: http://dl.dropbox.com/u/18386187/isemail.html
> >>>>>>>> 
> >>>>>>>> --
> >>>>>>>> /Jacob Carlborg
> >>>>>>> 
> >>>>>>> I believe enum values are to be named lowercase first.
> >>>>>>> EmailStatusCode.any
> >>>>>> 
> >>>>>> I don't know what the style guide says about enum members but if
> >>>>>> that's the case I'll change the names to begin with lowercase.
> >>>>> 
> >>>>> All names are camelcased.
> >>>> 
> >>>> That's not true. ALLCAPS is relatively common in Phobos. There is
> >>>> absolutely no way PI is going to become pi.
> >>>> 
> >>>>> All type names begin with an uppercase letter, and all variables
> >>>>> begin with a lowercase letter (with the possible exception of private
> >>>>> member variables beginning with _ - but what's private to a class or
> >>>>> struct isn't as critical as the public API regardless).
> >>>> 
> >>>> That part is clear.
> >>>> 
> >>>>  > enum values fall in the same camp as variables.
> >>>> 
> >>>> I never heard that before, and it doesn't seem to be true throughout
> >>>> Phobos. Grepping for all enum declarations (there isn't very many of
> >>>> them actually), I found some which were like that, some which start
> >>>> with uppercase, and some which are all caps.
> >>>> 
> >>>> I think you're assuming more concensus on style than has ever actually
> >>>> been discussed.
> >>> 
> >>> I think Andrei introduced the camelCase enum convention with his Phobos
> >>> overhaul back in 2.029.  All new modules, and most modules which have
> >>> seen major changes since then, follow it -- at least in the public API.
> >>> Examples include std.algorithm, std.datetime, std.file, std.getopt,
> >>> std.range and std.stdio.
> >>> 
> >>> I wouldn't mind if PI became pi -- I'd never dream of naming a variable
> >>> pi anyway, unless it's actually supposed to represent π.  Renaming E to
> >>> e, on the other hand, that's a lot worse.
> >>> 
> >>> -Lars
> >> 
> >> Hardly. The only examples I could find were algorithm: SwapStrategy,
> >> SortOutput
> >> range: traverseOptions, SearchPolicy
> >> There are many more which use other conventions, in other modules.
> > 
> > I don't intend to start a big debate about this, but I don't think you
> > looked very hard.  All of the modules I mentioned follow the camelCase
> > convention, and as far as I can tell, none have public enums that follow
> > other conventions.
> > 
> > std.algorithm: OpenRight, EditOp, SwapStrategy, SortOutput
> > 
> > std.datetime: Month, DayOfWeek, AllowDayOverflow, Direction, PopFirst,
> > AutoStart
> > std.file: SpanMode
> > 
> > std.getopt: config (actually not conventional, should be Config, but its
> > members are still camelCased)
> > 
> > std.range: StoppingPolicy, TransverseOptions, SearchPolicy
> > 
> > std.stdio: KeepTerminator
> > 
> >> Note that manifest constants (eg, enum int XXX = value;) are completely
> >> different to enumerated types (eg, enum XXX { AAA, BBB, CCC } ) They're
> >> using a keyword in common, but they're quite different concepts.
> > 
> > I think a sensible rule is that types (and templates that evaluate to
> > types) start with a capital letter, while values (and functions/templates
> > that evaluate to values) are camelCased.
> > 
> > -Lars
> 
> The point is this: we do NOT have a style guide.
> We have consensus on a few things. Types start with a capital letter.
> Functions are camelCased. Many other things haven't actually been
> discussed and agreed to.
> 
> Note that simplistic rules are doomed to failure. For example, template
> aliases can be either values or types.
> 
> Also, any attempt to use precedent is a disaster since Phobos began as a
> complete mishmash of styles. In some cases people erroneously believed
> there was a convention, and attempted to adhere to it, even though no
> such convention existed.
> 
> We desperately need a style guide containing all the things which have
> actually been agreed to (and equally importantly, nothing which hasn't).
> The simplest thing to do would be to fix up the existing one on the
> website which nobody follows.

I've tried to get Andrei to agree to a style guide a few times, but he's 
generally pushed back on it. I definitely think that we should have one if we 
want to actually have a consistent style, but thus far, he hasn't agreed to 
have one. I don't think that he's entirely against it, but we do keep running 
into issues where someone codes something one way and Andrei and/or others 
expect it to be another and are unhappy that it is (e.g. the 80 character line 
limit).

We don't need anything super strict or which specifies everything in insane 
detail, but basic style guidelines would definitely be a good thing to have. 
Maybe I should just put one together and post it on the Phobos list for 
discussion.

- Jonathan M Davis