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

[ron minnich]

Vendors frequently ask us to use magic numbers, and have even requested at
times that we remove explanatory text.

We'll never get rid of magic numbers in this world :-(

ron

On Thu, Feb 4, 2016 at 1:25 PM Patrick Georgi <pgeorgi at google.com> wrote:

> 2016-02-04 22:22 GMT+01:00 Martin Roth <gaumless at gmail.com>:
> > I don't think we need redefinitions of TRUE/FALSE
> We have no canonical definitions for TRUE/FALSE right now.
> Contributions that use them (for whatever reason) tend to bring local
> copies, and that's what I'd like to avoid.
>
> > How would people feel about adding something to the coding guide to
> > avoid magic numbers?
> Make that a separate thread please :-)
>
>
> Patrick
>
> > 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
>
>
>
> --
> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
> Hamburg
> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160204/fffae011/attachment.html>