[fpc-devel] Suggestion for change: Overly strict check

Vinzent Hoefler JeLlyFish.software at gmx.net
Tue Oct 3 09:36:11 CEST 2006


On Monday 02 October 2006 17:16, Micha Nelissen wrote:
> Chris Cheney wrote:
> >> I'm pretty sure he means that no can no longer, for example, copy
> >> a function from one class to another, without risking having to
> >> rewrite all the parameter names.
> >
> > You have understood me correctly - I would have expressed it a
> > little differently, but not as succinctly.
>
> Ok, so enforcing different names is good then, that makes code more
> context insensitive, since identifiers won't suddenly "resolve" to
> parameters with the same name.

No, it's more like the other way around. You get sudden name clashes 
which you didn't have before, because in the other class the field 
which clashes with your wisely chosen parameter name didn't exist.

There's a reason, I always write "self.Identifier" and I also refuse to 
revert back to the so called Hungarian notation (like AParameter). Even 
if there is *no* parameter and/or field with that name it's always 
clear which part is meant.

It would be more wise to warn about name clashes between units, because 
for example NewStr is defined in objects.pas and in classes.pas (IIRC), 
but depending on which one and how it is used your program may crash.

As long as such problems exist in the language definition itself, this 
whole discussion about "cleaner code" and if such syntactic checks are 
needed is f*cking pointless, because the language already forces you to 
use fully qualified names anyway if you want to avoid such problems. So 
you can as well use "self" to distiguish between parameters and fields 
even if they have the same name.


Vinzent.




More information about the fpc-devel mailing list