John Peacock wrote:
> Julian Foad wrote:
>
>> Ooh, careful! I think we're both being a bit too hasty here. I was
>> just about to commit this, and then happened to go looking at it again
>> and noticed this error:
>>
>>> apr_pool_t *pool)
>>> {
>>> const svn_wc_entry_t *entry;
>>> - svn_subst_keywords_t kw = { 0 };
>>> + apr_hash_t *kw;
>>
>> kw is uninitialised here.
>
> Personally, I prefer to _always_ initialize, just to prevent conditional
> codepaths from being added later that break formerly working code. I
> think this is probably why I went through and tried to initialize all of
> the hashes when I first created the patch.
The converse is that, if variables are only initialised if they need to be,
then a programmer can look at one and think "Hmm, must be careful here: this
one is evidently going to be used without further initialisation." I think
that was sort of in the back of my mind when I went and looked at the code
again and noticed the mistake, but I can't swear to it. If we can rely on
every word and number in the source code to have a definite purpose, then that
helps us to understand it.
If, on the other hand, we initialise everything at its declaration, that just
adds noise and then the useful information is lost. And if someone adds a code
path that conditionally sets the variable, and wasn't actually aware that it is
used without going through that code path, what's the chance of that person's
modification being correct anyway? Also, such a policy is unbounded: how far
do you go with initialising a complex structure, for instance?
I prefer every single bit of the source code to have a purpose, such that the
program would not work so well without it.
> I don't like it when a
> variable is defined here and then used more than a screen's worth later,
> because you can miss stuff like this.
Now, that I agree with. We should make a bit more of an effort to avoid that.
Of course, this situation would not arise much in a language like C99 or C++
where declarations can be mixed with statements. In C89, we just have to do
the best we can by extracting blocks of code, with their variables, into
sub-functions or "{ ... }" blocks.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 21 21:51:49 2005