Re: Coding style question

Поиск
Список
Период
Сортировка
От
Тема Re: Coding style question
Дата
Msg-id 1162498576.7998.324.camel@sakai.localdomain
обсуждение исходный текст
Ответ на Re: Coding style question  (Neil Conway <neilc@samurai.com>)
Ответы Re: Coding style question  (Nolan Cafferky <Nolan.Cafferky@qualitysmith.com>)
Список pgsql-hackers
<br /><blockquote type="CITE"><pre>
<font color="#000000">Well, clearly you should only assign meaningful values to variables, but</font>
<font color="#000000">I don't see anything wrong with omitting an initializer, initializing</font>
<font color="#000000">the variable before using it, and letting the compiler warn you if you</font>
<font color="#000000">forget to do this correctly. </font>
</pre></blockquote><br /> 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
exampleI cited, each variable was assigned a value immediately after being declared.  That wasn't a good example - in
someplaces, we declare all variables at the start of the function, but we don't assign a value to some of the variables
until20 or 30 lines of code later (and if there are multiple code paths, you have to follow each one to find out when
thevariable gains a meaningful value).  <br /><br /><blockquote type="CITE"><pre>
 
<font color="#000000">I agree with Greg's rationale on when to</font>
<font color="#000000">include an initializer in a variable declaration (when the initializer</font>
<font color="#000000">is trivial: e.g. casting a void * to a more specific pointer type, or</font>
<font color="#000000">using one of the PG_GETARG_XXX() macros in a UDF).</font>
</pre></blockquote><br /> I agree too.  I wasn't trying to suggest that <i>every variable must be initialized. </i><br
/><br/> I think Tom stated it pretty well:<br /><blockquote><tt>When the variable is going to be set anyway in
straight-linecode at the top of the function, then it's mostly a matter of taste whether you set it with an initializer
oran assignment.</tt><br /></blockquote> the key phrase is: "set anyway in straigh-tline code <i>at the top of the
function</i><i><u>"</u></i><blockquotetype="CITE"><pre>
 
<font color="#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 type="CITE"><pre>
<font color="#000000">I also find 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 /> Thanks for your comments.<br /><br />             --
Korry<br/><br /> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От:
Дата:
Сообщение: Re: Coding style question
Следующее
От: Richard Troy
Дата:
Сообщение: Re: Design Considerations for New Authentication Methods