On Fri, 19 Aug 2011 11:07:12 -0400
bearophile <bearophileh...@lycos.com> wrote:
> Some ways to face this problem:
>
> 1) Do nothing.
> 2) Give optional explicit information about the source of all variable names
> used in a function, using the optional @outer() I have proposed elsewhere.
> 3) Statically disallow (gives an error) local variables from shadowing global
> ones.
> 4) Produce a warning when a local variable shadows a global ones, in a smart
> way.
> 5) As the leading dot to denote global variables, require the use of another
> leading symbol (or some other mean) to denote local variable, when there is
> ambiguity.
Well, D currently says I can't shadow variables:
void foo() {
int x = 10;
{
int x = 5; // error
}
}
which pisses me off personally. It's such a handy feature. And there is
exactly one way to solve your problem which comes in two parts:
1. Don't violate the rule: "one or two screens of text per function".
2. Keep the low number of variables in a function, people say it should
be close to seven.
/me wants to be able to shadow his variables everywhere
