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

Reply via email to