More name hiding

[bearophile]

nsf:

> Well, D currently says I can't shadow variables:

Right, that's a third way to shadow variables that D forbids, thank you. But in my post I've shown other kinds of shadowing that currently D accepts. Shadowing global variables has caused some problems in my C code. One good commercial C lint lists all such cases with a warning.


> which pisses me off personally. It's such a handy feature.

It's a handy anti-feature, good source of bugs. Style guides suggest to rename one of them. If I see production C/C++ code that does that, I rename one of the two variables. In Haskell in your situation you are allowed to use x and x'.


> And there is exactly one way to solve your problem which comes in two parts:

Surely there are some alternative ways to solve this problem, SPARK and Java doesn't use your solution.

 
> 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.

I like to add a third rule, for D code:
3. Use pure functions everywhere possible. This avoids the shadowing problem.

But:
1) Old C code translated to D often doesn't follow your rules, unfortunately.
2) I have had colleagues that don't always follow your rules.
3) Even good codebases sometimes have longer functions. You find them even in the C sources of Python.
4) Even if you always follow your two rules, you are able to shadow a global (or outer) variable still, and 20 lines later sometimes you think that you are using the global variable, while you are modifying the local one. I have seen this happen even in code written by expert programmers, and it causes problems.


> /me wants to be able to shadow his variables everywhere

Good luck :-)

Bye and thank you for your comments,
bearophile