Naming conventions in .NET?
-
I'm wondering what the real rules are behind the class naming in the .NET framework (are there?)... On the Naming Guidelines[^] page they say: When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io. Ok, that's fine. I see classes like
AsnEncodedData
,OidCollection
,CspProviderFlags
, ... On the other hand we find classes likeASCIIEncoding
,UTF7Encoding
,UTF8Encoding
,UTF32Encoding
,RNGCryptoServiceProvider
,DESCryptoServiceProvider
,DSACryptoServiceProvider
,HMAC*
(7 classes),MACTripleDES
,CryptoAPITransform
, ... Am I missing a naming rule here or are those just named inconsistently? Of course we're far away from the Java naming hell, but anyway the .NET framework doesn't seem to be perfect :~
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)ASCII, UTF, API etc are acronyms. You don't want a class called
AmericanStandardCodeForInformationInterchangeEncoding
do you? Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
ASCII, UTF, API etc are acronyms. You don't want a class called
AmericanStandardCodeForInformationInterchangeEncoding
do you? Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!No, but according to the paragraph he quoted, it should be named
AsciiEncoding
. ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸ -
I'm wondering what the real rules are behind the class naming in the .NET framework (are there?)... On the Naming Guidelines[^] page they say: When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io. Ok, that's fine. I see classes like
AsnEncodedData
,OidCollection
,CspProviderFlags
, ... On the other hand we find classes likeASCIIEncoding
,UTF7Encoding
,UTF8Encoding
,UTF32Encoding
,RNGCryptoServiceProvider
,DESCryptoServiceProvider
,DSACryptoServiceProvider
,HMAC*
(7 classes),MACTripleDES
,CryptoAPITransform
, ... Am I missing a naming rule here or are those just named inconsistently? Of course we're far away from the Java naming hell, but anyway the .NET framework doesn't seem to be perfect :~
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)Camel case = grouping of word with first letter capitalized. ASCI (American Standard Code for Information Interchange), UTF7 (7-bit Unicode Transformation Format). ASCII and UTF are not names by themselves. I find naming
ASCIIEncoding
orUTF7Encoding
proper. It would be improper to name themasciiEncoding
orutf7Encoding
. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are. -
ASCII, UTF, API etc are acronyms. You don't want a class called
AmericanStandardCodeForInformationInterchangeEncoding
do you? Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!I couldn't agree more, Nish! Anyway, the casing should be different.
ASCIIEncoding
should beAsciiEncoding
,UTF7Encoding
should beUtf7Encoding
,UTF8Encoding
should beUtf8Encoding
,UTF32Encoding
should beUtf32Encoding
,RNGCryptoServiceProvider
should beRngCryptoServiceProvider
,DESCryptoServiceProvider
should beDesCryptoServiceProvider
,DSACryptoServiceProvider
should beDsaCryptoServiceProvider
,HMAC
* should beHmac
*,MACTripleDES
should beMacTripleDes
,CryptoAPITransform
should beCryptoApiTransform
, ...
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT) -
Camel case = grouping of word with first letter capitalized. ASCI (American Standard Code for Information Interchange), UTF7 (7-bit Unicode Transformation Format). ASCII and UTF are not names by themselves. I find naming
ASCIIEncoding
orUTF7Encoding
proper. It would be improper to name themasciiEncoding
orutf7Encoding
. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.Ok, but why did they create this acronym naming guideline then? And why do they follow it in so many places? Just a few examples:
XmlSyntaxException
("XML"),AsnEncodedData
("ASN.1"),CspParameters
("CSP"),Rfc2898DeriveBytes
("RFC"), ...
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT) -
I couldn't agree more, Nish! Anyway, the casing should be different.
ASCIIEncoding
should beAsciiEncoding
,UTF7Encoding
should beUtf7Encoding
,UTF8Encoding
should beUtf8Encoding
,UTF32Encoding
should beUtf32Encoding
,RNGCryptoServiceProvider
should beRngCryptoServiceProvider
,DESCryptoServiceProvider
should beDesCryptoServiceProvider
,DSACryptoServiceProvider
should beDsaCryptoServiceProvider
,HMAC
* should beHmac
*,MACTripleDES
should beMacTripleDes
,CryptoAPITransform
should beCryptoApiTransform
, ...
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)Camel case is the practice of writing compound words or phrases where the words are joined without spaces, and each word is capitalized within the compound Camel case[^] Since ASCII, UTF are not names by themselves, they are acronyms the
ASCIIEncoding
,UTF7Encoding
casing is correct. I guess you dont have a problem withIO
so them why wouldASCII
be any different? regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are. -
Ok, but why did they create this acronym naming guideline then? And why do they follow it in so many places? Just a few examples:
XmlSyntaxException
("XML"),AsnEncodedData
("ASN.1"),CspParameters
("CSP"),Rfc2898DeriveBytes
("RFC"), ...
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)I was expecting you'd say this :). Well, I guess they just didn't follow the standards there. Those namespaces were probably developed by the rebel teams of MS. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.
-
Camel case = grouping of word with first letter capitalized. ASCI (American Standard Code for Information Interchange), UTF7 (7-bit Unicode Transformation Format). ASCII and UTF are not names by themselves. I find naming
ASCIIEncoding
orUTF7Encoding
proper. It would be improper to name themasciiEncoding
orutf7Encoding
. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.Mircea Grelus wrote:
It would be improper to name them asciiEncoding or utf7Encoding.
To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of abbreviations:
- Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
- Do not use acronyms that are not generally accepted in the computing field.
- Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface and OLAP for On-line Analytical Processing.
- When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
- Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.
-
Mircea Grelus wrote:
It would be improper to name them asciiEncoding or utf7Encoding.
To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of abbreviations:
- Do not use abbreviations or contractions as parts of identifier names. For example, use GetWindow instead of GetWin.
- Do not use acronyms that are not generally accepted in the computing field.
- Where appropriate, use well-known acronyms to replace lengthy phrase names. For example, use UI for User Interface and OLAP for On-line Analytical Processing.
- When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io.
- Do not use abbreviations in identifiers or parameter names. If you must use abbreviations, use camel case for abbreviations that consist of more than two characters, even if this contradicts the standard abbreviation of the word.
You're right. :) There are arguments for both uses. I guess they just have to make up their mind. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.
-
I couldn't agree more, Nish! Anyway, the casing should be different.
ASCIIEncoding
should beAsciiEncoding
,UTF7Encoding
should beUtf7Encoding
,UTF8Encoding
should beUtf8Encoding
,UTF32Encoding
should beUtf32Encoding
,RNGCryptoServiceProvider
should beRngCryptoServiceProvider
,DESCryptoServiceProvider
should beDesCryptoServiceProvider
,DSACryptoServiceProvider
should beDsaCryptoServiceProvider
,HMAC
* should beHmac
*,MACTripleDES
should beMacTripleDes
,CryptoAPITransform
should beCryptoApiTransform
, ...
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)Oops, I missed the acronym point in your first post. Yeah, I got you now. Man, I feel dumb! Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
No, but according to the paragraph he quoted, it should be named
AsciiEncoding
. ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸Troposphere wrote:
No, but according to the paragraph he quoted, it should be named AsciiEncoding .
Yeah, just re-read that! :doh: Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
No, but according to the paragraph he quoted, it should be named
AsciiEncoding
. ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸Yeah, I have heard several MS speakers that said there were some cases where they did not listen to their own advise :) I filed a bug with MS when 2.0 was released because the arguments for certain exception constructors were backwards in relation to one another. The bug was declined as working as designed and the reasoning was backwards compatibility with code from the 1.1 framework. I don't by that argument really but hey....
-
I was expecting you'd say this :). Well, I guess they just didn't follow the standards there. Those namespaces were probably developed by the rebel teams of MS. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.
That's basically it. While most of the groups followed the standard, others outside of DevDiv sometimes didn't - and acronyms/abbreviations were the biggest rule breakers. It depended (a lot) on whether the Naming Police (aka Brad and Krzysztof) got to that team before things got solidified. Things should be better with WinFX as there was a concerted effort to police new APIs. -------------- TTFN - Kent
-
Yeah, I have heard several MS speakers that said there were some cases where they did not listen to their own advise :) I filed a bug with MS when 2.0 was released because the arguments for certain exception constructors were backwards in relation to one another. The bug was declined as working as designed and the reasoning was backwards compatibility with code from the 1.1 framework. I don't by that argument really but hey....
Ray Cassick wrote:
I don't by that argument really but hey....
You might have bought it if you had a bunch of code compiled on 1.1 that would have broken when run on 2.0. Annoying as the out-of-order parameters are, breaking backward compatibility would be worse. For most folks, at least. Charlie if(!curlies){ return; }
-
I'm wondering what the real rules are behind the class naming in the .NET framework (are there?)... On the Naming Guidelines[^] page they say: When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io. Ok, that's fine. I see classes like
AsnEncodedData
,OidCollection
,CspProviderFlags
, ... On the other hand we find classes likeASCIIEncoding
,UTF7Encoding
,UTF8Encoding
,UTF32Encoding
,RNGCryptoServiceProvider
,DESCryptoServiceProvider
,DSACryptoServiceProvider
,HMAC*
(7 classes),MACTripleDES
,CryptoAPITransform
, ... Am I missing a naming rule here or are those just named inconsistently? Of course we're far away from the Java naming hell, but anyway the .NET framework doesn't seem to be perfect :~
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)Even Microsoft has many developers that consider them more as suggestions than rules ;) I am a bad programmer, I flipflop on this rule depending on the situation. If it is more idenifable one way, that is the way I will use regardless of the guidelines. Rocky <>< Latest Post: SQL2005 Server Managemnet Studio timeouts! Blog: www.RockyMoore.com/TheCoder/[^]
-
I'm wondering what the real rules are behind the class naming in the .NET framework (are there?)... On the Naming Guidelines[^] page they say: When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io. Ok, that's fine. I see classes like
AsnEncodedData
,OidCollection
,CspProviderFlags
, ... On the other hand we find classes likeASCIIEncoding
,UTF7Encoding
,UTF8Encoding
,UTF32Encoding
,RNGCryptoServiceProvider
,DESCryptoServiceProvider
,DSACryptoServiceProvider
,HMAC*
(7 classes),MACTripleDES
,CryptoAPITransform
, ... Am I missing a naming rule here or are those just named inconsistently? Of course we're far away from the Java naming hell, but anyway the .NET framework doesn't seem to be perfect :~
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)Brad Abrams has written much about this topic on his blog. The guidelines were put in place after a lot of code had already been written and shipped, and by that time it was too late to rename classes to fit the rules. --Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | NEW!! PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
-
Camel case is the practice of writing compound words or phrases where the words are joined without spaces, and each word is capitalized within the compound Camel case[^] Since ASCII, UTF are not names by themselves, they are acronyms the
ASCIIEncoding
,UTF7Encoding
casing is correct. I guess you dont have a problem withIO
so them why wouldASCII
be any different? regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.Because the MS recommendation is to only write acronyms that are fewer than 3 letters in uppercase. So IO is uppercase, but ASCII should be Ascii, but is not. Regards Senthil _____________________________ My Blog | My Articles | My Flickr | WinMacro
-
I'm wondering what the real rules are behind the class naming in the .NET framework (are there?)... On the Naming Guidelines[^] page they say: When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io. Ok, that's fine. I see classes like
AsnEncodedData
,OidCollection
,CspProviderFlags
, ... On the other hand we find classes likeASCIIEncoding
,UTF7Encoding
,UTF8Encoding
,UTF32Encoding
,RNGCryptoServiceProvider
,DESCryptoServiceProvider
,DSACryptoServiceProvider
,HMAC*
(7 classes),MACTripleDES
,CryptoAPITransform
, ... Am I missing a naming rule here or are those just named inconsistently? Of course we're far away from the Java naming hell, but anyway the .NET framework doesn't seem to be perfect :~
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)It's just plain silly to use pascal camel case for acronyms.
-
I'm wondering what the real rules are behind the class naming in the .NET framework (are there?)... On the Naming Guidelines[^] page they say: When using acronyms, use Pascal case or camel case for acronyms more than two characters long. For example, use HtmlButton or htmlButton. However, you should capitalize acronyms that consist of only two characters, such as System.IO instead of System.Io. Ok, that's fine. I see classes like
AsnEncodedData
,OidCollection
,CspProviderFlags
, ... On the other hand we find classes likeASCIIEncoding
,UTF7Encoding
,UTF8Encoding
,UTF32Encoding
,RNGCryptoServiceProvider
,DESCryptoServiceProvider
,DSACryptoServiceProvider
,HMAC*
(7 classes),MACTripleDES
,CryptoAPITransform
, ... Am I missing a naming rule here or are those just named inconsistently? Of course we're far away from the Java naming hell, but anyway the .NET framework doesn't seem to be perfect :~
_outp(0x64, 0xAD);
and__asm mov al, 0xAD __asm out 0x64, al
do the same... but what do they do?? ;) (doesn't work on NT)The official .NET Framework guidelines are documented in the book "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries". This book includes the guideline to use Pascal case or camel case for acronyms more than two characters, but before getting to that it says, "In general, it is important to avoid using acronyms in identifier names unless they are in common usage and are immediately understandable to anyone who might use the framework." (Section 3.2.1. Capitalizing Acronyms). In an annotation in that same section, co-author Brad Abrams acknowledges that the Framework does not consistently follow these guidelines, and states, "For the most part, our customers have seen the places in which we have diverged from these guidelines (for even the best excuse) as warts in the Framework."
-
The official .NET Framework guidelines are documented in the book "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries". This book includes the guideline to use Pascal case or camel case for acronyms more than two characters, but before getting to that it says, "In general, it is important to avoid using acronyms in identifier names unless they are in common usage and are immediately understandable to anyone who might use the framework." (Section 3.2.1. Capitalizing Acronyms). In an annotation in that same section, co-author Brad Abrams acknowledges that the Framework does not consistently follow these guidelines, and states, "For the most part, our customers have seen the places in which we have diverged from these guidelines (for even the best excuse) as warts in the Framework."
I should have given full credit to the authors and publisher when quoting that book. "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" by Krzysztof Cwalina and Brad Abrams published by Addison-Wesley as part of the Microsoft .NET Development Series