I'd honestly prefer to see this discussion drag on a little longer. The
original email was on Friday, so given that most participants on this list
aren't actively debating C++ coding style on the weekend, we've actually
had less than one full working day of discussion on this issue so far.
Let me suggest again (especially since I'm not sure my previous email
reached this list yet) that rather than compromise on the "e" prefix, we
compromise on all caps for values, which is just as readable without
placing even more pressure on our 80-character line length restriction.
Thanks,
- Seth
On Mon, Apr 11, 2016 at 8:00 AM, Kartikaya Gupta <kgu...@mozilla.com> wrote:
> Based on all the feedback so far I think the best compromise is to use
> enum classes with the "e" prefix on the values. As was mentioned, the
> "e" prefix is useful to distinguish between enum values and function
> pointer passing at call sites, but is a small enough prefix that it
> shouldn't be too much of a burden.
>
> I realize not everybody is going to be happy with this but I don't
> want this discussion to drag on to the point where it's a net loss of
> productivity no matter what we end up doing. I'll update the style
> guide.
>
> Thanks all!
>
> kats
>
>
> On Sun, Apr 10, 2016 at 11:43 AM, smaug <sm...@welho.com> wrote:
> > On 04/10/2016 05:50 PM, Aryeh Gregor wrote:
> >>
> >> On Fri, Apr 8, 2016 at 8:35 PM, smaug <sm...@welho.com> wrote:
> >>>
> >>> enum classes are great, but I'd still use prefix for the values.
> >>> Otherwise the values look like types - nested classes or such.
> >>> (Keeping my reviewer's hat on, so thinking about readability here.)
> >>
> >>
> >> In some cases I think it's extremely clear, like this:
> >>
> >> enum class Change { minus, plus };
> >>
> >> whose sole use is as a function parameter (to avoid a boolean
> >> parameter), like so:
> >>
> >> ChangeIndentation(*curNode->AsElement(), Change::plus);
> >>
> >> In cases where it might be mistaken for a class, it might make more
> >> sense to prefix the enum class name with "E". I don't think this
> >> should be required as a general policy, though, because for some enums
> >> it might be clear enough without it.
> >>
> >
> > Indeed in your case it is totally unclear whether one is passing a
> function
> > pointer or enum value as param.
> > If the value was prefixed with e, it would be clear.
> >
> > Consistency helps with reviewing (and in general code readability) a
> lot, so
> > the less we have optional coding style rules, or
> > context dependent rules, the better.
> >
> >
> >
> >
> >
> > _______________________________________________
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
