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