On Mon, Apr 11, 2016 at 7:58 PM, Jeff Gilbert wrote:
> On Mon, Apr 11, 2016 at 4:00 PM, Bobby Holley
> wrote:
> > On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert
> wrote:
> >> I think the whole attempt is
> >> increasingly a distraction vs the alternative, and I say this as
> >> someone who write
On Mon, Apr 11, 2016 at 5:58 PM, Jeff Gilbert wrote:
> On Mon, Apr 11, 2016 at 4:00 PM, Bobby Holley
> wrote:
> > On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert
> wrote:
> >> I propose that if you're in a part of the codebase where you can't
> >> tell if it's an enum or a function pointer (regar
On Mon, Apr 11, 2016 at 4:00 PM, Bobby Holley wrote:
> On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert wrote:
>> I propose that if you're in a part of the codebase where you can't
>> tell if it's an enum or a function pointer (regardless of the fact
>> that the compiler can't confuse these), you sh
On Mon, Apr 11, 2016 at 1:46 PM, Seth Fowler wrote:
> 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
On Mon, Apr 11, 2016 at 2:12 PM, Jeff Gilbert wrote:
> I'm not sure how this is compromise. We were already supposed to use
> enum classes with new code.
>
> Every additional glyph incurs mental load. Code should instead be
> written so these things are not necessary to explicitly state. *That*
>
On 2016-04-11 19:47, Seth Fowler wrote:
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-characte
On 04/12/2016 12:12 AM, Jeff Gilbert wrote:
I'm not sure how this is compromise. We were already supposed to use
enum classes with new code.
Every additional glyph incurs mental load.
But it reduces the mental load from deciding from the context what kind of thing
one is dealing with (is it typ
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
I'm not sure how this is compromise. We were already supposed to use
enum classes with new code.
Every additional glyph incurs mental load. Code should instead be
written so these things are not necessary to explicitly state. *That*
is the code we should be trying to write. In well-written code,
s
> All caps actually makes long names *longer* because you now need to
> add underscores to separate words, rather than using sentence case.
> For example eSentenceCase is the same length as SENTENCE_CASE, but if
> you tack on another word the "e" prefix is shorter. Presumably this
> line-wrapping i
On 04/11/2016 09:01 PM, Milan Sreckovic wrote:
Maybe there was a reason we didn’t have this in the style guide as a single
choice.
My guess is that, even though there has been the Mozilla coding style forever,
we haven't traditionally been too strict about following it, so no one cared
too m
Maybe there was a reason we didn’t have this in the style guide as a single
choice.
—
- Milan
> On Apr 11, 2016, at 11:00 , Kartikaya Gupta 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
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
I agree in the extreme with Jeff here. Foo::Bar, in an expression context,
cannot be anything other than a value. For me, at least, I have never noticed
this adding any overhead in reviews - it’s immediately obvious what’s
happening. I suspect that if it *does* add overhead for you, you’ll find
On Mon, Apr 11, 2016 at 5:17 PM, Chris Peterson
wrote:
> On 4/8/16 8:10 AM, Kartikaya Gupta wrote:
>
>> Is there a recommendation for what enum values in C++ code should be
>> styled as? The coding style doesn't say and we use a variety of things
>> in existing code, so I was wondering if we shou
On 4/8/16 8:10 AM, Kartikaya Gupta wrote:
Is there a recommendation for what enum values in C++ code should be
styled as? The coding style doesn't say and we use a variety of things
in existing code, so I was wondering if we should settle on something
for new enums being added to the code, and up
On 04/10/2016 05:50 PM, Aryeh Gregor wrote:
On Fri, Apr 8, 2016 at 8:35 PM, smaug 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
On Fri, Apr 8, 2016 at 8:35 PM, smaug 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
It's noisy in code you *do* understand, which is the bulk of the code
we should be dealing with the majority of the time.
I do not parse this initially as a type because that generally doesn't
make sense given context.
Generally the names involved are also unlikely to be types, based on name alone
On Fri, Apr 8, 2016 at 2:03 PM, Jeff Gilbert wrote:
> Strong preference against eFoo, here. :)
Would you mind saying why?
/ Jonas
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 2016-04-08 23:03, Jeff Gilbert wrote:
Strong preference against eFoo, here. :)
Strong preference *for* eFoo, here. :)
If I see Bar::Foo anywhere in code I'm not familiar with, my brain
is likely to first parse that as a type before realizing that, hmm
that doesn't make sense in an expressio
Strong preference against eFoo, here. :)
Just use enum classes.
On Fri, Apr 8, 2016 at 10:35 AM, smaug wrote:
> On 04/08/2016 07:38 PM, Nick Fitzgerald wrote:
>>
>> On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas <
>> birunt...@mohanathas.com> wrote:
>>
>>> On 8 April 2016 at 18:10, Kartika
On 04/08/2016 07:38 PM, Nick Fitzgerald wrote:
On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas <
birunt...@mohanathas.com> wrote:
On 8 April 2016 at 18:10, Kartikaya Gupta wrote:
Others?
enum class OptionD {
SentenceCaseValues,
ThisWontBeConfusedWithOtherThings
// ... because
On Fri, Apr 8, 2016 at 9:29 AM, Birunthan Mohanathas <
birunt...@mohanathas.com> wrote:
> On 8 April 2016 at 18:10, Kartikaya Gupta wrote:
> > Others?
>
> enum class OptionD {
> SentenceCaseValues,
> ThisWontBeConfusedWithOtherThings
> // ... because you need to use OptionD::ThisWontBeConfu
On 04/08/2016 06:10 PM, Kartikaya Gupta wrote:
Is there a recommendation for what enum values in C++ code should be
styled as? The coding style doesn't say and we use a variety of things
in existing code, so I was wondering if we should settle on something
for new enums being added to the code, a
On 8 April 2016 at 18:10, Kartikaya Gupta wrote:
> Others?
enum class OptionD {
SentenceCaseValues,
ThisWontBeConfusedWithOtherThings
// ... because you need to use OptionD::ThisWontBeConfusedWithOtherThings
};
___
dev-platform mailing list
dev-pl
Is there a recommendation for what enum values in C++ code should be
styled as? The coding style doesn't say and we use a variety of things
in existing code, so I was wondering if we should settle on something
for new enums being added to the code, and update the style guide
accordingly.
enum Opti
27 matches
Mail list logo
