Design Guidelines

[Guest]

I have been reading "Design Guidelines for Developing Class Libraries" at
http://msdn2.microsoft.com/en-us/library/ms229042.aspx. Is it correct that
they are recommending camelCase for private member variables? Doesn't this
create problems for case-insensitive languages when we create a private
member variable along with properties?

For example

Private thisIsAVariable As Int32

Public Property ThisIsAVariable As Int32
Get
Return thisIsAVariable
End Get
Set(ByVal Value As Int32)
thisIsAVariable = Value
End Set
End Property

 

[Guest]

I have been reading "Design Guidelines for Developing Class Libraries"
at http://msdn2.microsoft.com/en-us/library/ms229042.aspx. Is it
correct that they are recommending camelCase for private member
variables? Doesn't this create problems for case-insensitive languages
when we create a private member variable along with properties?

For example

Private thisIsAVariable As Int32

Public Property ThisIsAVariable As Int32
Get
Return thisIsAVariable
End Get
Set(ByVal Value As Int32)
thisIsAVariable = Value
End Set
End Property

VB is case insensitive, so the code above will not compile.

Similar code in C# will compile (since it's case sensitive) but it won't
cause a problem in VB.NET since one of the variables is private, thus not
accessible when referenced.

 

[Michel Posseth [MCP]]

AFAIK the code will compile , however if you access the property it wil
overflow ( stack overflow , eg out of memory exception )

most common is :

Private m_thisIsAVariable As Int32
Public Property ThisIsAVariable As Int32
Get
Return m_thisIsAVariable
End Get
Set(ByVal Value As Int32)
m_thisIsAVariable = Value
End Set
End Property


i found this to be a verry valuable book

http://www.amazon.com/Practical-Gui...1864831?ie=UTF8&s=books&qid=1185860444&sr=8-3

 

[Linda Liu [MSFT]]

Hi Tom,

VB.NET is a case-insensitve language, and on the contrary C# is a
case-sensitive language.

Doesn't this create problems for case-insensitive languages when we

create a private member variable along with properties?

Yes, it would create a compilation error when a private member variable has
a same name as a public property ignoring the case. The sample code you
showed would generate a compilation error.

Is it correct that they are recommending camelCase for private member

variables?

Could you please tell me where you read it from?

Sincerely,
Linda Liu
Microsoft Online Community Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Cor Ligthert[MVP]]

Michel,

As addition I never use an underscore in VB.Net.

For me is an underscore a kind of mix between Hungarian notation and Pascal
case in my opinion and hard to use on the US keyboard because it needs a
shift and I can not reach that because I have learned and use forever blind
typing and than that underscore is reachable for me but not common.

I just use only the m in this case.

(Just to give another opinion for others)

Cor

 

[Cor Ligthert[MVP]]

Tom,

Be aware that in this case it is going well when you use a class from C# in
VB.Net because one of the members is private. However if you use two public
members with only case difference, than it is not fulfilling the CLR rules
and give an error, although it can be used in C# and C++. (Probably a kind
of legancy of those languages that is stayed because it is impossible to
change that use).

I write too very much C# and use it there in the same way as you (otherwise
it would look strange to people only knowing C languages), although I always
have the idea that it is not as documentive as using that m before a
fieldname.

Cor

 

[Guest]

AFAIK the code will compile , however if you access the property it wil
overflow ( stack overflow , eg out of memory exception )

</stupidity modus >

No it wil NOT compile , although Sharpdevelop wil only show a message when
you compile the code VS.Net 2005 refuses to compile the code and shows the
messages inmediatly


To Cor :

Well i guess it is just a mather of taste

in VB6 i used mVar_Propertyname
the VB.Net C# best practices and guidelines book says m_Propertyname
i also see a lot of code with _Propertyname ( probably because COM hides _
prefixed names to the outside world )

but i guess m ( module member ) allone would also be clear and uniform
enough

 

[Guest]

AFAIK the code will compile , however if you access the property it wil
overflow ( stack overflow , eg out of memory exception )

I dont' think so?

Private thisIsAVariable As Int32

Public Property ThisIsAVariable As Int32
Get
Return thisIsAVariable
End Get
Set(ByVal Value As Int32)
thisIsAVariable = Value
End Set
End Property

Won't it say thisIsAVariable has already been declared?

 

[Herfried K. Wagner [MVP]]

I have been reading "Design Guidelines for Developing Class Libraries" at
http://msdn2.microsoft.com/en-us/library/ms229042.aspx. Is it correct that
they are recommending camelCase for private member variables?

No, there is no recommendation for naming private variables because these
variables are not part of the interface.

Doesn't this create problems for case-insensitive languages
when we create a private member variable along with properties?

Yes, it would not be possible in VB at all, and it's a bad idea in other
programming languages too because it can lead to nasty mistakes when
identifiers get mixed up, potentially bypassing validation code, and code
still compiles.

 

[Guest]

The following link refers to "Member Design Guidelines"

http://msdn2.microsoft.com/en-us/library/ms229057.aspx

The code sample shows "dataValues" being defined camelCase (although it is
defined as public). they show the property that accesses the array has the
name "Data". It is an example of bad design, but it is the only place that I
could find an example of a member variable.

I have always defined a member variable as follows:

Private m_Data As Integer()

and named the property the name without the "m_" prefix (for example, "Data")

The "General Naming Conventions" in the ".NET Framework Developer's Guide"
state that I should not use an underscore '_' character. What is the naming
convention for a private member variable that will work with the CLR and all
languages?

 

[Linda Liu [MSFT]]

Hi Tom,

Thank you for your reply.

I look into the MSDN library for naming fields, but don't find a recommeded
way to name a field. Perhaps, there's no recommended way to name a field.

I find a sample provided in MSDN library which implements a composite
control. The private fields of the composite control are defined as follows:

Private colFColor as Color
Private colBColor as Color

And the corresponding public properties are defined as below:

Property ClockBackColor() as Color
' Retrieves the value of the private variable colBColor.
Get
Return colBColor
End Get
' Stores the selected value in the private variable colBColor, and
' updates the background color of the label control lblDisplay.
Set(ByVal Value as Color)
colBColor = Value
lblDisplay.BackColor = ColBColor
End Set

End Property

Property ClockForeColor() as Color
Get
Return colFColor
End Get
Set(ByVal Value as Color)
colFColor = Value
lblDisplay.ForeColor = ColFColor
End Set
End Property

In my opinion, as long as the name of a field doesn't break the rules that
the 'General Naming Conventions' makes, the name should be good.

If you have any concern, please feel free to let me know.

Sincerely,
Linda Liu
Microsoft Online Community Support

 

[Cor Ligthert[MVP]]

I look into the MSDN library for naming fields, but don't find a
recommeded
way to name a field. Perhaps, there's no recommended way to name a field.

But that is for sure in the MSDN library Pascal case with some exceptions as
'I' for interface like that.

Cor

 

[Michel Posseth [MCP]]

Yes you are right ,,,, ( i stand corrected


I had given the answer from a computer without a dev environment , and so
did not test it

 

[Linda Liu [MSFT]]

Hi Tom,

How about the problem now?

If you have any concern, please feel free to let me know.

Thank you for using our MSDN Managed Newsgroup Support Service!

Sincerely,
Linda Liu
Microsoft Online Community Support