<br /><blockquote type="CITE"><pre>
<font color="#000000">Yeah, I agree with that. But as Andrew noted, we don't really have any</font>
<font color="#000000">hard and fast coding rules --- the only guideline is to do your best to</font>
<font color="#000000">make your code readable, because other people *will* have to read it.</font>
</pre></blockquote><br /> I'm not really looking for hard/fast rules. Just picking brains. <br /><br /><blockquote
type="CITE"><pre>
<font color="#000000">In the particular example here I find Korry's proposed coding less</font>
<font color="#000000">readable than what's there, but I can't entirely put my finger on why.</font>
<font color="#000000">Maybe it's just the knowledge that it's less easily modifiable. In general,</font>
<font color="#000000">I'd say initializers with side effects or nonobvious ordering dependencies</font>
<font color="#000000">are definitely bad style, because someone might innocently rearrange</font>
<font color="#000000">them, eg to group all the variables of the same datatype together.</font>
<font color="#000000">You can get away with ordering dependencies like</font>
<font color="#000000"> TupleDesc itupdesc = RelationGetDescr(rel);</font>
<font color="#000000"> int natts = itupdesc->natts;</font>
<font color="#000000">because the dependency is obvious (even to the compiler). Anything more</font>
<font color="#000000">complex than this, I'd write as a statement not an initializer.</font>
</pre></blockquote><br /> Agreed - I contrived an example (I just happened to be reading _bt_check_unique()). In fact,
Iwould <i>not</i> initialize 'offset' as I suggested, but I probably would initialize just about everything else.<br
/><br/> (In fact, in the actual code, there's a code-comment that describes the initialization of offset - I would
certainlyleave that in place).<br /><br /> -- Korry<br /><br /><br />
