Static code analysis FxCop: refer to "DB" (and others), such as "Id",

Question

All projects that I know, including the Entity Framework (which is Microsoft itself!) - use "Db" instead of "DB". Therefore, they consider "Db" as an abbreviation. But FxCop treats the term as an abbreviation, so you should call it "DB". I have similar terms that I like like abbeys. How to get FxCop to do this? I need the same behavior as with "Id". Adding a custom dictionary is the first step I think, but adding “Db” to the dictionary / Acronyms / CasingExceptions is not enough. You can still call it "DB". "Db" is accepted, but not forced. Somehow, "Id" really makes you not call it "ID".

I've already reviewed

"C: \ Program Files (x86) \ Microsoft Visual Studio 10.0 \ Command Tools \ Static Analysis Tools \ FxCop \ CustomDictionary.xml"

to find out how they did it. But "Id" is not part of this standard dictionary, maybe there is another one?

Any ideas?

---

Also, I don’t understand why “DB” is not treated as the default abbreviation, it is an abbreviation for “database”, for example “Id”, it is an abbreviation of “identifier”:

http://msdn.microsoft.com/en-us/library/ms182256(v=VS.80).aspx

Maybe due to some other exceptions, where is it an abbreviation and an abbreviation? Let's say "Doggy Bag" ("DB")?

Answer 1

Id handling is hardcoded in Microsoft.FxCop.Rules.Naming.CasingWordParser.CheckAbbreviation() (at least in VS 10), and essentially you can’t do anything to connect to this logic.

As to why the database is considered an acronym rather than an abbreviation, this is probably because the “database” was originally a “database”. (A separate form of the word is still used, although it is pretty damn rare compared to the complex form.) According to the design guidelines, we should not use "db" at all, if it is an abbreviation, so I think we should consider ourselves happy. that it is primarily considered an acronym .;)

All that said, I personally found that capitalizing two-letter abbreviations is becoming increasingly unpleasant over time. I find that it looks ugly and “exceptional,” and it seems like it meets intuition for almost everyone who is first introduced in a design guide. I have never seen an explanation of why the design team initially thought it might be a good idea, but I need to wonder if most of them want to give up the decision if they had the opportunity today.