Re: Coding style question

> The disadvantage of using initializers is that you end up contorting the code
> to allow you to squeeze things into the initializers and it limits what you
> can do later to the code without undoing them.
>
> For example, if later you find out you have to, say, lock a table before the
> itupdesc initializer then all of the sudden you have to rip out all the
> initializers and rewrite them as assignments after the statement acquiring the
> table lock.

Good point (and I can't argue with your example). But, I think
initializers also force you to declare variables in the scope where they
are needed. Instead of declaring every variable at the start of the
function, it's better to declare them as nested as practical (not as
nested as possible, but as nested as practical). That means, you might
write the code like this:

static TransactionId
_bt_check_unique(Relation rel, IndexTuple itup, Relation heapRel,
Buffer buf, ScanKey itup_scankey)
{
if( lockTable( ... ))
{
TupleDesc itupdesc = RelationGetDescr(rel);
int natts = rel->rd_rel->relnatts;
Page page = BufferGetPage(buf);
OffsetNumber maxoff = PageGetMaxOffsetNumber(page);
...

The biggest advantage to that style of coding is that you know when each
variable goes out of scope. If you declare every variable at the start
of the function (and you don't initialize it), it can be very difficult
to tell at which points in the code the variable holds a (meaningful)
value. If you declare local variables in nested scopes, you know that
the variable disappears as soon as you see the closing '}'.

> I admit to a certain affinity to lisp-style programming and that does lead to
> me tending to try to use initializers doing lots of work in expressions. But I
> find I usually end up undoing them before I'm finished because I need to
> include a statement or because too much work needs to be done with one
> variable before some other variable can be initialized.
>
> But including complex expensive function calls in initializers will probably
> only confuse people trying to follow the logic of the code. Including
> _bt_binsrch() as an initializer for example hides the bulk of the work this
> function does.
>
> 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.

Agreed - you can certainly take initialization way too far, I just think
we don't take it far enough in many cases and I'm wondering if there's
some advantage that I'm not aware of.

-- Korry