Re: History of French

From: Richard Herring (junk_at_[127.0.0.1)
Date: 10/07/04 

Date: Thu, 7 Oct 2004 10:56:41 +0100

In message <umk8m0p413qrbo5e7ppll7vef7sl1lhbpu@4ax.com>, Mxsmanic
<mxsmanic@hotmail.com> writes
>Richard Herring writes:

[over-snipped context restored, as usual. Apologies for the hash it
makes of the indentation ]

mxsmanic said, of variable declarations:
>Good programmers put them up at the top, anyway.
>
me:
>> If that's intended as a universal truth, it's either nonsense or a
>> no-true-Scotsman circular argument.
>
>It's a general observation.
>
>> Ah, you mean it's anecdotal.
>
>No, it comes from studies I've read in the past,

Unless you cite them, it's anecdotal, and you've given no reason for
anyone reading this group to believe that you are capable of accurate
reporting.

>although the mountains
>of code I've read over the years correlate with the studies.

As I said, anecdotal.

>>For that to be of any value, first you'd have to establish that you're
any
>>kind of authority to decide who is and who is not a good programmer.

Which you haven't done.
>
>There are also best-practices guidelines.

Like the corporate style guides I refer to below.

>Remember structured
>programming?

Yes. What of it?
>
>> Some good programmers declare them where their corporate style guide
>> requires them to.
>
>People who follow a corporate style guide are not relevant.
>> Why ever not?
>
>Because they are just doing what they are told--anyone can do that.

But _someone_ has to decide what to tell them. As I said,

>> The guide didn't just happen, someone codified what they determined
to
>>be good practice.

You can't have it both ways. Earlier, you referred me to best-practices
guidelines. Now you say they don't count.

>> The absence of intervening irrelevant material means that it's easier
>> for a human reader to get a complete view of what the thing is for.
>
>The problem is that, unless the scope of the identifier is very limited,

-- as it should be --

>it will probably still be declared far away from most references; and if
>it's not declared up top, it can take a long time to find that first
>declaration when you need it. Been there and done that.

So on your own admission you write functions that are too long.
>
>> It's less likely that the programmer will forget to initialise it
>> properly.
>
>He needs to initialize it

Of course he does. We're talking about the likelihood and consequences
of his forgetting to do so.

>each time it requires initialization,

After the first time, it's *not* initialization, it's assignment. The
semantics of "initial" should give you a clue.

His real objective is to ensure that an invariant is maintained.

>not when
>it is declared. The latter is especially risky because it doesn't
>explicitly state when the initialization will occur,

We're talking about objects with block scope here. For them, it's very
precisely defined when initialisation occurs, it's at the point of
declaration.

>and that often
>depends on the declared scope of the identifier, which can be very
>difficult to determine.

All the more reason to do it exactly where it's needed.

>> Now, what's bad about it?
>
>See above.

Non sequitur. Nothing you have posted is a valid argument for separating
declaration from use.

> I've done all this before, ages ago.
>
And clearly not learned from your mistakes. 

-- 
Richard Herring

Relevant Pages