[coreboot] RFC: coding style: "standard" defines

Martin Roth gaumless at gmail.com
Thu Feb 4 22:22:07 CET 2016


I don't think we need redefinitions of TRUE/FALSE

Ron's argument against using BIT(16) makes sense to me.

I don't have a problem with BIT16, 0x10000, or (1 << 16) but
#define VENDOR_BIT_16 0x10000 seems like overkill.


I'd really generally prefer some good definitions though
  instead of write(BIT16) I'd really like to see:
  #define ENABLE_FEATURE BIT16
  write(ENABLE_FEATURE)

I know that at times we don't have good documentation about what the
values actually do, but we've got a lot of magic numbers throughout
our code.

How would people feel about adding something to the coding guide to
avoid magic numbers?

Martin

On Thu, Feb 4, 2016 at 6:05 AM, ron minnich <rminnich at gmail.com> wrote:
>
>
> On Thu, Feb 4, 2016 at 2:29 AM Patrick Georgi via coreboot
> <coreboot at coreboot.org> wrote:
>>
>>
>>
>> 1. TRUE/FALSE
>> Do we want such defines? If so, TRUE/FALSE, or true/false, or
>> True/False, or ...?
>
>
> should we start using bool ...?
>>
>>
>> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x10000
>> I don't think it makes sense to go for a single one of these (0x3ff is
>> certainly more readable than BIT11 | BIT10 | BIT9 | BIT8 | BIT7 | BIT8
>> | BIT5 | BIT4 | BIT3 | BIT2 | BIT1 | BIT 0), but I doubt we need both
>> BIT16 and BIT(16).
>>
>
> BIT16 is a constant. BIT(16) is a chance for things to go badly wrong, e.g.
> BIT(x-y) might produce some very strange problems. I kind of prefer the
> constant.
>
> ron
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot



More information about the coreboot mailing list