On 27-02-2019 21:05, Mark Brown wrote: > On Wed, Feb 27, 2019 at 08:41:46PM +0100, Olliver Schinagl wrote: >> On 25-02-2019 18:25, Mark Brown wrote: >>> If you find you need to describe what the fields are it would be much >>> more constructive to add a comment at the top of the table saying what >>> they are. As things are this isn't helping anyone - as a big pile of >>> defines it's hard to read the values without context for how they're >>> used and if you're looking at the table you can't tell what the >>> regulator actually supports without going and decoding the defines. >> Then the name of the define should be more constructive, which imo they >> are reasonably? But as everything with programming, naming things is the >> he hardest part, right? > I really don't think that's it - I think that sometimes a data table is > just a data table. There are some coding styles that work to avoid > having raw numbers anywhere in code outside of defines at all costs but > I do think that goes too far in cases like this where the name of the > define is at some level just going to summarize what should go in a > given slot in a table which adds little.
I'm not sure if we're still talking about the same thing or same table; In any case, this is something up to personal taste in the end, and I am in the camp that favors (readable, which of course could always be improved) defines over magic values; especially when it comes to these bit-selectors. And even if a little less here, to keep things consistent with all defines is why at least I prefer the one approach. You guys prefer the raw values. Two flavors of two opinions I suppose :)