文档介绍：.net开发规
目录
使用正确的大小写风格4
使用描述性英文名称4
使用易读的名称4
尽量防止在名称中使用编码5
同义词中使用固定的单词5
保持词义的前后一致5
名词和动词必能理解。有了用英语命名的前提，我们还应该注意：一个抽象概念可能有多个表述同义词，选择一个，始终如一。如对同一动作，在不同类中选用不同的名称，比方，fetch, retrieve 和 get，则，使用你的类从事编程的人就要多费很多精力去理解它们。也就是说，我们应该通过使用一致的名称，创立统一的编程接口，简化学****的难度。
保持词义的前后一致
多数词都有不止一个意思，但在同一个系统中，应始终保持同一个意思。这和前面的原则是相对应的。使用不同的词汇，使人联想不同的接口和/或操作。同样，使用同样的词汇，使人联想一样的接口和/或操作。如果我学过使用DeviceManager::add(), 我就会期望可以使用ProtocolManager::add(). 这是根据名称产生的联想，甚至连想到可以使用*Manager::add()。要保证这种联想能成立，前后词义必须一致。如果自己设计一个系统，要尽量做到保持词义的一致。记住，在两个完全不同的畴使用一样的
名字是很不可取的。
名词和动词的选用
类和对象应当使用名词或名词短语命名。方法中强调过程用动词，返回值用名词。作为一名设计人员，可能不太在意这些命名的琐事。尝试使用你设计的类去编写一段用户程序，看看有多少别扭或混乱的地方，一定可以反过来有助你改良设计。
使用计算机专业术语
尽量使用约定成俗的惯用语、计算机科学术语、算法名称、设计模式名称、数学名词等软件编程相关名词。这样似乎有点异端，但这总好过让程序员费力找客户弄清楚自己原本清楚的概念，只是由于名称的不同使他们疑惑。我们是讲编码规，程序员大多数是计算机专业的，或对计算机专业已有了深入了解的。很少最终用户会阅读程序，即使有，也是有相当计算机软件功底的。相反，程序维护人员必须阅读程序，所以应尽可能使用计算机术语。如：运用工厂模式类的命名应该是“名词+Factory〞。
必要时可使用业务术语
如果工作的重点不在程序本身，或问题的描述比问题的解决更重要，可使用业务术语。在分析阶段，使用业务术语比使用计算机术语更好，因为容易被客户理解和承受。
防止误导
防止使用已有其它明确意义的名词。例如，"hp", "ai*", 和 "sco" 被用作UNI* 平台及其变种的名称，如果再用来作为变量或函数名称就很有问题，会引起误解。即使你在解决的问题用 "hp" 是很好的缩写也不应使用"hp"。
名词需要语境说明
只有少数情况下，孤立的一个名字有明确含义。多数情况下，名称需要置于一定的语境中才有意义。比方，在类中，函数中或注释中。换句话说，在面向对象的语言中，在类属性的名称中包含类名是多余的。例如，，而应该使用 。pany. address_ 和 Customer. address_， 同样都是address, 但仅在语境中才有意义，以下的命名是不可取的：pany. panyAddress_, 。
不要添加人为的语境
不要在类的前面冠以公司名缩写、工程名称缩写或其他标志性前缀。例如，在做知识管理系统时，把员工类命名成KmsUser。以上命名法是不可取的，这样势必造成代码重复，影响代码的重用。如使用同一个类，则KmsUser在其他系统中就显得不和谐了。
防止名称差异不明显造成混淆
这个问题源于编写程序仅仅是为了能编译通过或能解译执行。编译和解译程序不允许在同一域用一样的名字指称两个东西。所以，遇到编译问题时，就随便将其中的一个改变一下。更糟糕的是，原本同一个名称，因拼写错误变成两个名称。这里要说的关键问题是，如果要区分两样不同的东西，一定要保证名称有实质性的差异。例如，假设将一个类命名成
Product，另一个类命名成ProductInfo或ProductData, 就会因差异不明显造成混淆。因为Info和Data 没有具体的意思。同理，不要在 OO 编程中使用Class或Object作为名称的一局部。CustomerObject 和 Customer 有什么区别" NameString 比 Name 好吗" 难道一个Name 还会是浮点数或整数不成？特别要强调的是，对于大小写敏感的编程环境，我们不要使用仅有大小写区别的名字。 例如，Customer, customer 不应作为两个名字。
大写风格
.
Pascal风