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

[Alex G.]

On 02/08/2016 11:29 AM, Julius Werner wrote:
>>> On 08.02.2016 12:10, Patrick Georgi via coreboot wrote:
>>>> 2016-02-04 10:35 GMT+01:00 Patrick Georgi <pgeorgi at google.com>:
>>>>> during the review of some commits that are in the process of being
>>>>> upstreamed from Chrome OS, people noticed that chipset drivers like to
>>>>> define their own TRUE/FALSE defines (sometimes prefixed to), and I
>>>>> have seen a bunch of #define BIT{0-31} ..., too, because that seems to
>>>>> be the house rules in some firmware communities.
>>>> Seems like for the BIT defines, all variants are popular. Any
>>>> objection with moving them to src/include instead of having various
>>>> copies across the tree?
>>> How about something like src/include/please_dont_use.h ?
>>>
>> I don't know about that but I'd have no objection to a comment in the file
>> itself that these are vile constructs.
> 
> If we agree on what not to use, why not just fix it completely?
> coccinelle is great for that sort of thing.
> (For the record, I don't mind BIT(x) too much but I also prefer (1 <<
> x), since it's more consistent with multi-bit fields like (5 << x).)

Other than BITxx macros, really, what's the purpose of this? Sure,
standardization sounds great, but can anyone point to reasons why _not_
standardizing results in loss of productivity? As I've said before, we
do import code from other codebases, which oftentimes are not even
self-consistent. There's loss in productivity from being forced to
convert one style of bit macro to another.

Just from that, it seems that trying to "standardize" is a net loss.
Pretty code is useless when it's slow and clumsy to write.

Alex