By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,103 Members | 1,505 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,103 IT Pros & Developers. It's quick & easy.

Design Guidelines

P: n/a
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
--
Tom Stevens
Jul 31 '07 #1
Share this Question
Share on Google+
12 Replies


P: n/a
=?Utf-8?B?VG9tKys7?= <To**@newsgroup.nospamwrote in
news:99**********************************@microsof t.com:
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.

Jul 31 '07 #2

P: n/a
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-Guid...5860444&sr=8-3

"Spam Catcher" <sp**********@rogers.comschreef in bericht
news:Xn**********************************@127.0.0. 1...
=?Utf-8?B?VG9tKys7?= <To**@newsgroup.nospamwrote in
news:99**********************************@microsof t.com:
>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.

Jul 31 '07 #3

P: n/a
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/subscripti...ult.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/subscripti...t/default.aspx.
==================================================

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

Jul 31 '07 #4

P: n/a
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

"Michel Posseth [MCP]" <MS**@posseth.comschreef in bericht
news:%2****************@TK2MSFTNGP03.phx.gbl...
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-Guid...5860444&sr=8-3

"Spam Catcher" <sp**********@rogers.comschreef in bericht
news:Xn**********************************@127.0.0. 1...
>=?Utf-8?B?VG9tKys7?= <To**@newsgroup.nospamwrote in
news:99**********************************@microso ft.com:
>>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.

Jul 31 '07 #5

P: n/a
<stupidity modus >
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

"Michel Posseth [MCP]" wrote:
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-Guid...5860444&sr=8-3

"Spam Catcher" <sp**********@rogers.comschreef in bericht
news:Xn**********************************@127.0.0. 1...
=?Utf-8?B?VG9tKys7?= <To**@newsgroup.nospamwrote in
news:99**********************************@microsof t.com:
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.


Jul 31 '07 #6

P: n/a
"Michel Posseth [MCP]" <MS**@posseth.comwrote in news:#1e30Vz0HHA.1208
@TK2MSFTNGP03.phx.gbl:
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?
Jul 31 '07 #7

P: n/a
"Tom++;" <To**@newsgroup.nospamschrieb:
>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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Jul 31 '07 #8

P: n/a
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]" wrote:
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/subscripti...ult.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/subscripti...t/default.aspx.
==================================================

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

Aug 1 '07 #9

P: n/a
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

Aug 2 '07 #10

P: n/a
>
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

Aug 2 '07 #11

P: n/a

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

"Spam Catcher" <sp**********@rogers.comschreef in bericht
news:Xn**********************************@127.0.0. 1...
"Michel Posseth [MCP]" <MS**@posseth.comwrote in news:#1e30Vz0HHA.1208
@TK2MSFTNGP03.phx.gbl:
>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?

Aug 2 '07 #12

P: n/a
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

Aug 6 '07 #13

This discussion thread is closed

Replies have been disabled for this discussion.