Well, clearly you should only assign meaningful values to variables, but
I don't see anything wrong with omitting an initializer, initializing
the variable before using it, and letting the compiler warn you if you
forget to do this correctly. 

The problem that that introduces is that you have to unravel the code if you want to maintain it, especially if you're changing complex code (many code paths) and some variable is initialized long after it's declared.  You have to search the code to figure out at which point the variable gains a meaningful value.  In the example I cited, each variable was assigned a value immediately after being declared.  That wasn't a good example - in some places, we declare all variables at the start of the function, but we don't assign a value to some of the variables until 20 or 30 lines of code later (and if there are multiple code paths, you have to follow each one to find out when the variable gains a meaningful value). 

I agree with Greg's rationale on when to
include an initializer in a variable declaration (when the initializer
is trivial: e.g. casting a void * to a more specific pointer type, or
using one of the PG_GETARG_XXX() macros in a UDF).

I agree too.  I wasn't trying to suggest that every variable must be initialized.

I think Tom stated it pretty well:
When the variable is going to be set anyway in straight-line code at the top of the function, then it's mostly a matter of taste whether you set it with an initializer or an assignment.
the key phrase is: "set anyway in straigh-tline code at the top of the function"
> (I don't go so far as to introduce artificial scopes just for the sake
> of nesting variable declarations).

I don't introduce artificial scopes either. However, I do try to declare
variables in the most-tightly-enclosing scope. For example, if a
variable is only used in one branch of an if statement, declare the
variable inside that block, not in the enclosing scope.
I also find that if you're declaring a lot of variables in a single
block, that's usually a sign that the block is too large and should be
refactored (e.g. by moving some code into separate functions). If you
keep your functions manageably small (which is not always the case in
the Postgres code, unfortunately), the declarations are usually pretty
clearly visible.

I couldn't agree more.

Thanks for your comments.

            -- Korry

Reply via email to