Re: Private variables question

In article <xn0fpsjg367j5vi000@xxxxxxxxxxxxxxxxxxxxxx>,
omtay.oreycay@xxxxxxxxxxxxxxx says...
Jolyon Smith wrote:

If a method is so lengthy that the local variable declarations are so
distantly removed from the code that uses them that it makes human
scope resolution difficult, then the length of the procedure code is
the thing that needs addressing, not the variable names.


That wasn't quite the purpose. The thinking behind using a consistent
local variable name prefix is to guard against using a name that is
already in use at a higher scope.

You might have a method that's only three lines long - easy to see the
local variables declared for it. But still not so easy to see the
variables declared at the object level, which may be several hundred
lines away.


Right, but if those three lines reference a variable that is declared
locally then that is almost certainly the variable that they MEANT to
reference, so there is no problem.

Surely the only problem arises when the body of the method references
something that it intends to reference as a local variable and that
variable is then removed, thereby "exposing" the "outer" identifier.

For myself, a simple case convention sorts that problem out.

Local variables are always named and referenced with a lower case
initial, camel case thereafter.

If I see "width" in code and no "width" variable then that provides a
red-flag: if the code resultingly references some Width property of
self, is that deliberate or the accidental result of a "width" variable
having been deleted.

Of course, the compiler can't help in that case, but then neither can it
help in such cases even if you have a prefix.

Does having an "l" prefix help?

The answer is yes in that specific case, but only a little and not
enough to warrant the intrusion on readbility (imho).

It changes the potential for dilemma slightly, it doesn't actually
comprehensively eliminate it.

Where there is a local lWidth variable AND an outer "Width" property,
how does one tell whether a "Width" reference in the code is correct or
is inadvertently missing an intended "L" prefix.

You still can't know for sure.

(and all of that without getting into the extent to which this then
makes font choice an important factor in being able to correctly - and
easily - read code that uses "l" and "1" etc)


Combining shorter-names, allowing abbreviations etc in local variables
that are not allowed in (e.g.) property names, creates the
distinctiveness that is required, and encouraging/promoting/or indeed
demanding short, concise methods, allows the distinctiveness to be
workable (lots of local variables requires greater verbosity in those
variables names and as the length of the life of a variable increases,
so it starts to take on the characteristics of other long lived
identifiers, i.e. properties etc).

e.g. 'w' would be an acceptable local variable name to hold some width
working value, but would absolutely NOT be acceptable as a property
name.

Arguably "width" should not be a natural choice for a local variable
anyway where an outer Width identifier is also in scope. tmpWidth or
workWidth etc maybe.


I do use an 'a' prefix on method parameter names (note the lower case
'a' for consistency with "localness" of the name), not as a mnemonic for
"argument", but simply because it actually reads quite "normally".

i.e. a procedure that works on any string provided to it via a parameter
is only required to act on a single occurence of a string for any
particular invocation.

That is, it acts on "a string". So if that string is a name: aName.
The code acts on "a Name".
.

Relevant Pages

  • Re: To Hungarian or not to Hungarian
    ... prefix that denotes whether the item is a parameter, ... The type, but not the scope. ... I personally do not use prefixes for local variables. ... "Death is one of the few things that can be done as easily lying ...
    (borland.public.delphi.non-technical)
  • Re: VB 6.0 Desktop - Global Variables
    ... variables are not "slower" than local variables. ... wide scope", then this kind of variables only can live in a module. ... standard code module. ... without needing a reference to an object. ...
    (microsoft.public.vb.general.discussion)
  • Re: finalize() newbie question
    ... that is not a newbie question at all. ... Although the reference variable "a" has gone out of scope in the ... at the binary level local variables aren't ...
    (comp.lang.java)
  • Re: Newbie Q: Declare variable IN the loop or BEFORE the loop?
    ... when in fact it's the other local variables that they (via the ... anonymous delegates) reference that are of concern. ... and "expensive" are tied in lifetime by their being in the same scope, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: ~Destructor equivalent in java?
    ... Assuming myObj was the last reference to the object, ... is only "eligible for garbage collection" and in general, ... allow local variables to go ...
    (comp.lang.java.programmer)