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.
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

Reply via email to