Naming conventions in .NET?
-
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, aldo 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, aldo 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,UTF7Encodingcasing is correct. I guess you dont have a problem withIOso them why wouldASCIIbe 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, aldo 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, aldo 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
-
ASCII, UTF, API etc are acronyms. You don't want a class called
AmericanStandardCodeForInformationInterchangeEncodingdo you? Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!I hate to be a stickler, but since we're picking at nits: word-objects like "UTF", "RNG", "DSA", etc are not acronyms, they are initialisms. An acronym is technically an initialism where the initials constitute a pronounceable word, like "GUI" or "ASCII". Not that anybody cares... Courtesy of the Ben Hunter school of useless knowledge...
-
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
ASCIIEncodingorUTF7Encodingproper. It would be improper to name themasciiEncodingorutf7Encoding. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.Completly agree! There is rules, but there is also exception to the rule! UTF7*, ACSI* - is right, becouse it's exceptions...
-
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
ASCIIEncodingorUTF7Encodingproper. It would be improper to name themasciiEncodingorutf7Encoding. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.Interesting debate, but unless you plan to distribute your components, classes etc to third-parties, does it really matter? Having said that, I believe that most of us are intelligent enough to work out that ASCIIEncoding and AsciiEncoding are the same thing. Steve Jowett. Wait for my first born to arrive, any day now :-D
-
Interesting debate, but unless you plan to distribute your components, classes etc to third-parties, does it really matter? Having said that, I believe that most of us are intelligent enough to work out that ASCIIEncoding and AsciiEncoding are the same thing. Steve Jowett. Wait for my first born to arrive, any day now :-D
Of course that the naming convension wouldn't get in the way of doing our job. But it can cause impediments if one project is split among more development groups. When all the parts must be combined it is really a pain in the a** to start renaming classes and namespaces. It could introduce bugs into the project and also it's just stupid wasted time. Of course this doesn't happen that often if the project management is good, but it was just an example. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.
-
Of course that the naming convension wouldn't get in the way of doing our job. But it can cause impediments if one project is split among more development groups. When all the parts must be combined it is really a pain in the a** to start renaming classes and namespaces. It could introduce bugs into the project and also it's just stupid wasted time. Of course this doesn't happen that often if the project management is good, but it was just an example. regards, Mircea Many people spend their life going to sleep when they’re not sleepy and waking up while they still are.
I take your point. But what I was trying to say (badly) is if you are coding only for your in house development then you to free to dictate any coding standard you choose. When developing within a group, the coding standards should be agreed by all concerned and implemented accordingly. Having said that, you should also keep in mind that your company my employ other developers after you leave, who may pick up your work. I they do not understand your coding methods and standards then the chances are they'll bin your work and do it again. Most importantly, your code should be easy to follow, and the best test for that is give it to a non-developer and ask them what each section does. Ideally they should be able to tell from the procedure name. Steve Jowett
-
I hate to be a stickler, but since we're picking at nits: word-objects like "UTF", "RNG", "DSA", etc are not acronyms, they are initialisms. An acronym is technically an initialism where the initials constitute a pronounceable word, like "GUI" or "ASCII". Not that anybody cares... Courtesy of the Ben Hunter school of useless knowledge...
