Yeah, I agree with that. But as Andrew noted, we don't really have any hard and fast coding rules --- the only guideline is to do your best to make your code readable, because other people *will* have to read it.
I'm not really looking for hard/fast rules. Just picking brains.
In the particular example here I find Korry's proposed coding less
readable than what's there, but I can't entirely put my finger on why.
Maybe it's just the knowledge that it's less easily modifiable. In general,
I'd say initializers with side effects or nonobvious ordering dependencies
are definitely bad style, because someone might innocently rearrange
them, eg to group all the variables of the same datatype together.
You can get away with ordering dependencies like
TupleDesc itupdesc = RelationGetDescr(rel);
int natts = itupdesc->natts;
because the dependency is obvious (even to the compiler). Anything more
complex than this, I'd write as a statement not an initializer.
Agreed - I contrived an example (I just happened to be reading _bt_check_unique()). In fact, I would not initialize 'offset' as I suggested, but I probably would initialize just about everything else.
(In fact, in the actual code, there's a code-comment that describes the initialization of offset - I would certainly leave that in place).
-- Korry
