Dear Delphi Developers
Dear Delphi Developers,
Please, please, PLEASE do not do this:
Do not use an identifier for a field in your class, and then use that exact same identifier as a parameter on about six different methods in that class.
Please, I beg you.
Your Pal,
Nick
Please, please, PLEASE do not do this:
Do not use an identifier for a field in your class, and then use that exact same identifier as a parameter on about six different methods in that class.
Please, I beg you.
Your Pal,
Nick
Well, I thought that's why you have 'scope'.
ReplyDelete:P
I don't.
ReplyDeleteTMyClass = Class
private
FStuff1: Boolean;
FStuff2: Boolean;
..
..
function DoThing1(Thing1,Thing2,Thing3: Boolean);
function DoThing2(Thing1,Thing2,Thing3: Boolean);
...
..
I prefer to use generic variable naming to avoid confusion. ;-)
Scope is for compilers - not for humans.
ReplyDeleteOh, picky, picky, picky... You just want to spoil all our fun. ;)
ReplyDeleteNick Hodges especially when the parameter represents conceptually different data than the field with the same name.
ReplyDelete...or worse, when they have the same name and the same type. Yikes!
ReplyDeleteI put an A in front of each parameter.
ReplyDeleteWith is evil ! (in the sense a method is implicitely enclosed with a "with self do")
ReplyDeleteNick Hodges but it's ok to use a global variable with the same name, isn't it?
ReplyDeleteMoz Le Oh, sure, that's perfectly fine. No problem. ;-)
ReplyDeleteThat's why I use the notation my good friend Thomas Mueller proposed for parameters: Prefix them with an underscore. (I don't like the "A" prefix, it just doesn't look natural. If I remember correctly he told me he cooked that up with Allan Mertner .
ReplyDeleteI use a lower case 'a' for my parameters.
ReplyDeleteThat's what you have prefixes for. It would be nice if the compiler threw an annoying warning about this though, and similar if a local function's variable hides a variable or parameter in the parent function.
ReplyDeleteI blame you for this... I'm looking at new code and it is full of copy'n'pasted code with this sort of name overloading. Same names for private fields on the class, local variables. Bonus: every now and then there's a nested procedure that uses the same names again (and, of course, all variables are declared before any nested ones)
ReplyDeleteHere's my parameter prefix convention
ReplyDeleteprocedure DoStuff(const inFoo : string; var ioFoo : string; out outFoo);
It's not always that clear cut of course, objects passed in as const or with no access specifier can be modified by setting properties or calling methods. In those instances I use the prefix that matches how I'm going to use the parameter usually "io".
FPC just prohibits this. That sui how i learned i was doing it. So... don't lament here - 1% of devels would ever read it and 1% of those who read would remember. Change the compiler, - it would be less breaking changes than XE34s 0-based strings and Free changed to FreeAndNil.
ReplyDeleteArioch The problem is that there's already a bunch of options in the complier that you should turn on, most people leave off, and turning them on breaks code. Even if it was just a hint or warning, the people you most want to change their behaviour because of it will just turn it off or ignore it. "yeah, you're right, there are 3572 hints'n'warnings now. You say there used to be only 2853? Interesting".
ReplyDeleteMoz Le yes, they can turn the safety net off, after them been informed. But now they are not event informed. If Nick just wanted to vent the steam, that is okay. But if he really wants it to change then lamenting here just makes no difference.
ReplyDelete