Gregory Stark <stark@enterprisedb.com> writes:
> People expect initializers to be simple expressions, macro calls, accessor
> functions, and so on. Not to call out to complex functions that implement key
> bits of the function behaviour.
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.
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.
regards, tom lane