Re: Coding style question

<br /><blockquote cite="mid1162498576.7998.324.camel@sakai.localdomain" type="cite">I think Tom stated it pretty
well:<br/><blockquote><tt>When the variable is going to be set anyway in straight-line code at the top of the function,
thenit's mostly a matter of taste whether you set it with an initializer or an assignment.</tt><br /></blockquote> the
keyphrase is: "set anyway in straigh-tline code <i>at the top of the function</i><i><u>"</u></i><blockquote
type="CITE"><pre><fontcolor="#000000">> (I don't go so far as to introduce artificial scopes just for the
sake</font>
<font color="#000000">> of nesting variable declarations).</font>

<font color="#000000">I don't introduce artificial scopes either. However, I do try to declare</font>
<font color="#000000">variables in the most-tightly-enclosing scope. For example, if a</font>
<font color="#000000">variable is only used in one branch of an if statement, declare the</font>
<font color="#000000">variable inside that block, not in the enclosing scope.</font>   </pre></blockquote>
good...</blockquote>This may not inform the current conversation at all, but a while back I went on a cross-compiler
compatibilitybinge for all of my active projects, and I found that some compilers (*cough* Borland *cough) had some
verystrange compiler/run time errors unless all variables were declared at the top of the function, before any other
codegets executed.  For better or for worse, I started strictly declaring all variables in this manner, with
initializationhappening afterward, and the behavior has stuck with me.  I don't know whether any compilers used for
postgresbuilds still have this issue - it's been a few years.<br /><blockquote
cite="mid1162498576.7998.324.camel@sakai.localdomain"type="cite"><blockquote type="CITE"><pre><font color="#000000">I
alsofind that if you're declaring a lot of variables in a single</font>
 
<font color="#000000">block, that's usually a sign that the block is too large and should be</font>
<font color="#000000">refactored (e.g. by moving some code into separate functions). If you</font>
<font color="#000000">keep your functions manageably small (which is not always the case in</font>
<font color="#000000">the Postgres code, unfortunately), the declarations are usually pretty</font>
<font color="#000000">clearly visible.</font>   </pre></blockquote><br /> I couldn't agree more.<br /><br
/></blockquote>Insert emphatic agreement here.  Refactoring into smaller functions or doing a bit of object orientation
almostalways solves that readability problem for me.<br /><br /><pre class="moz-signature" cols="72">-- 
 
Nolan Cafferky
Software Developer
IT Department
RBS Interactive
<a class="moz-txt-link-abbreviated"
href="mailto:nolan.cafferky@rbsinteractive.com">nolan.cafferky@rbsinteractive.com</a></pre>