> 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.
>>
> good...
This may not inform the current conversation at all, but a while back I
went on a cross-compiler compatibility binge for all of my active
projects, and I found that some compilers (*cough* Borland *cough) had
some very strange compiler/run time errors unless all variables were
declared at the top of the function, before any other code gets
executed. For better or for worse, I started strictly declaring all
variables in this manner, with initialization happening afterward, and
the behavior has stuck with me. I don't know whether any compilers used
for postgres builds still have this issue - it's been a few years.
>> 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.
>
Insert emphatic agreement here. Refactoring into smaller functions or
doing a bit of object orientation almost always solves that readability
problem for me.

--
Nolan Cafferky
Software Developer
IT Department
RBS Interactive
nolan.cafferky@rbsinteractive.com