Writing Properties

[Rasika Wijayaratne]

6.10 Writing Properties
In C# name the property name should "shadow" the private variable name
that it represents differing only by case; Colour and colour for
example. But this would only apply when the variable that the property
represents is private, otherwise case-insensitive languages like
Visual Basic would have trouble accessing two members inside the type.

It is not possible to "shadow" the property name in Visual Basic, as
the language is case-insensitive. So the private variable can have an
alternate name or an underscore at the beginning, e.g. _colour.

[C#]
public string Colour
{
get
{
return colour;
}
set
{
colour = value;
}
}

[Visual Basic]
Public Property Colour As String
Get
Return _colour ' Can't use colour VB is case-insensitive
End Get
Set(ByVal _colour As String)
Me._colour = _colour
End Set
End Property

[Konrad L. M. Rudolph]

Rasika Wijayaratne wrote:

It is not possible to "shadow" the property name in Visual Basic, as
the language is case-insensitive. So the private variable can have an
alternate name or an underscore at the beginning, e.g. _colour.

Which should be the norm anyway, also in C#: using case distinction for
the distinction between differen variables / types is extremely
ambiguous. It makes code harder to read, harder to write and harder to
debug. An underscore in front of private members' names has been one of
the C++-conventions for a long time now and in my opinion it's one of
the better ones.

--
Konrad -
http://madrat.net/

[Jon Skeet [C# MVP]]

Konrad L. M. Rudolph <ko************@madrat.net> wrote:

Rasika Wijayaratne wrote:

It is not possible to "shadow" the property name in Visual Basic, as
the language is case-insensitive. So the private variable can have an
alternate name or an underscore at the beginning, e.g. _colour.

Which should be the norm anyway, also in C#: using case distinction for
the distinction between differen variables / types is extremely
ambiguous. It makes code harder to read, harder to write and harder to
debug. An underscore in front of private members' names has been one of
the C++-conventions for a long time now and in my opinion it's one of
the better ones.

I've never found it at all hard to disambiguate between (say) colour
and Colour. I also find it significantly easier to read that than
_colour - the extra underscore makes my brain judder slightly when
reading it.

Each to their own (when it comes to naming conventions for private
variables) but I've never found it to be a problem.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[cody]

> > It is not possible to "shadow" the property name in Visual Basic, as

the language is case-insensitive. So the private variable can have an
alternate name or an underscore at the beginning, e.g. _colour.

Which should be the norm anyway, also in C#: using case distinction for
the distinction between differen variables / types is extremely
ambiguous. It makes code harder to read, harder to write and harder to
debug. An underscore in front of private members' names has been one of
the C++-conventions for a long time now and in my opinion it's one of
the better ones.

I disagree. if you see a variable starting with a small letter you
immediately know that it is a private field.
If you see oen starting with uppercase letter you know that its a property
or public.
Anyway, the uppercase and lowercase versions should have the same meaning
(as long as your properties does not have sideeffects).

--
cody

Freeware Tools, Games and Humour
http://www.deutronium.de.vu || http://www.deutronium.tk