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
[EMAIL PROTECTED]
|
- Re: [HACKERS] Coding style question Nolan Cafferky
-
