Lets Try Again, Writing Properties

  • Thread starter Thread starter Rasika Wijayaratne
  • Start date Start date
R

Rasika Wijayaratne

What does everybody think of the below:
==========================================
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
 
Rasika Wijayaratne said:
What does everybody think of the below:
==========================================
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.

Yes - but you should at least *almost* never have non-private variables
anyway.
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.

Something like that, yes.
 
Rasika,
I've seen the following naming conventions for VB.NET:

Private _colour As Color
Private mColour As Color
Private m_colour As Color

With different variations on casing. I prefer the third "m_colour" as its
more distinctive, however as Jon stated, the variables are private, so as
long as you are consistent within your Project, Solution, Team, Department,
Organization. I don't think naming convention on private variables really
matters...

Hope this helps
Jay
 
What does everybody think of the below:
==========================================
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


I agree with all, but what was your question?
 
Back
Top