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
