C#编码的命名与注释方法

C#编码的命名与注释方法：(microsoft官方，比较全面) 

　　命名 注释 格式 

　　命名对于理解应用程序的逻辑流，命名方案是最有影响力的一种帮助。名称应该说明“什么”而不是“如何”。通过避免使用公开基础实现(它们会发生改变)的名称，可以保留简化复杂性的抽象层。例如，可以使用GetNextStudent()，而不是GetNextArrayElement()。

 

　　命名原则是：选择正确名称时的困难可能表明需要进一步分析或定义项的目的。使名称足够长以便有一定的意义，并且足够短以避免冗长。唯一名称在编程上仅用于将各项区分开。表现力强的名称是为了帮助人们阅读;因此，提供人们可以理解的名称是有意义的。不过，请确保选择的名称符合适用语言的规则和标准。

 　　以下几点是推荐的命名方法。

 

1. 避免难懂的名称，如对于AnalyzeThis()，或者对于变量的xxK8。这样的名称会导致多义性，而不仅仅是抽象。

2. 在面向对象的语言中，在类属性的名称中包含类名是多余的，如Book.BookTitle。而是应该使用 Book.Title。

3. 使用动词-名词的方法来命名对给定对象执行特定操作的方法，如CalculateInvoiceTotal()。

4. 在允许方法重载的语言中，所有重载都应该执行相似的方法。对于那些不允许方法重载的语言，建立使相似方法发生关系的命名标准。

5. 变量只要合适，在变量名的末尾追加计算限定符(Avg、Sum、Min、Max、Index)。在变量名中使用互补对，如min/max、begin/end 和open/close。

6. 鉴于大多数名称都是通过连接若干单词构造的，请使用大小写混合的格式以简化它们的阅读。另外，为了帮助区分变量和方法，请对方法名称使用Pascal大小写处理 (CalculateInvoiceTotal)，其中每个单词的第一个字母都是大写的。对于私有变量名，请使用camel大小写处理 (documentFormatType)，其中除了第一个单词外每个单词的第一个字母都是大写的。布尔变量名应该包含Is，这意味着 Yes/No 或 True/False 值，如 fileIsFound。对于属性名，也建议使用Pascal大小写处理。

7. 在命名状态变量时，避免使用诸如 Flag的术语。状态变量不同于布尔变量的地方是它可以具有两个以上的可能值。不是使用documentFlag，而是使用更具描述性的名称，如documentFormatType。

8. 即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。仅对于短循环索引使用单字母变量名，如i 或 j。不要使用原义数字或原义字符串，如 For i = 1 To 7。而是使用命名常数，如 For i = 1ToNUM_DAYS_IN_WEEK 以便于维护和理解。 

9. 表在命名表时，用单数形式表示名称。例如，使用Employee，而不是Employees。 在命名表的列时，不要重复表的名称;例如，在名为 Employee的表中避免使用名为EmployeeLastName 的字段。不要在列的名称中包含数据类型。如果后来有必要更改数据类型，这将减少工作量。

10. Microsoft SQL Server不要给存储过程加sp 前缀，这个前缀是为标识系统存储过程保留的。 不要给用户定义的方法加fn_ 前缀，这个前缀是为标识内置方法保留的。不要给扩展存储过程加 xp_前缀，这个前缀是为标识系统扩展存储过程保留的。杂项尽量减少使用缩写，而是使用以一致方式创建的缩写。缩写应该只有一个意思;同样，每个缩写词也应该只有一个缩写。例如，如果用min作为 minimum 的缩写，那么在所有地方都应这样做;不要将 min 又用作 minute的缩写。在命名函数时包括返回值的说明，如GetCurrentWindowName()。与过程名一样，文件和文件夹的名称也应该精确地说明它们的用途。避免对不同的元素重用名称，如名为 ProcessSales()的函数和名为 iProcessSales 的变量。在命名元素时避免同音异义词(如 write 和center)，以防在检查代码时发生混淆。在命名元素时，避免使用普遍拼错的词。另外，应清楚区域拼写之间存在的差异，如color/colour 和 check/cheque。避免用印刷标记来标识数据类型，如用 $ 代表字符串或用 %代表整数。

 

    注释软件文档以两种形式存在：外部的和内部的。外部文档(如规范、帮助文件和设计文档)在源代码的外部维护。内部文档由开发人员在开发时在源代码中编写的注释组成。　　

不考虑外部文档的可用性，由于硬拷贝文档可能会放错地方，源代码清单应该能够独立存在。外部文档应该由规范、设计文档、更改请求、错误历史记录和使用的编码标准组成。　　

.内部软件文档的一个难题是确保注释的维护与更新与源代码同时进行。尽管正确注释源代码在运行时没有任何用途，但这对于必须维护特别复杂或麻烦的软件片段的开发人员来说却是无价的。

 

　　以下几点是推荐的注释方法：　　

1． 如果用 C# 进行开发，请使用 XML 文档功能。有关更多信息，请参见：XML 文档。（最终目标是生成类似vs msdn的chm文档，大公司可能会用到）

2．修改代码时，总是使代码周围的注释保持最新。

3．在每个方法的开始，提供标准的注释样本以指示方法的用途、假设和限制很有帮助。

4．注释样本应该是解释它为什么存在和可以做什么的简短介绍。

5．避免在代码行的末尾添加注释;行尾注释使代码更难阅读。不过在批注变量声明时，行尾注释是合适的;在这种情况下，将所有行尾注释在公共制表位处对齐。

6．避免杂乱的注释，如一整行星号。而是应该使用空白将注释同代码分开。避免在块注释的周围加上印刷框。这样看起来可能很漂亮，但是难于维护。

7．在部署之前，移除所有临时或无关的注释，以避免在日后的维护工作中产生混乱。

8．如果需要用注释来解释复杂的代码节，请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码，而应该重写它。尽管一般不应该为了使代码更简单以便于人们使用而牺牲性能，但必须保持性能和可维护性之间的平衡。

9．在编写注释时使用完整的句子。注释应该阐明代码，而不应该增加多义性。

10．在编写代码时就注释，因为以后很可能没有时间这样做。

11．另外，如果有机会复查已编写的代码，在今天看来很完美或理所应当的代码六周以后或许就不会那样看待了。

12．避免多余的或不适当的注释，如幽默的不主要的备注。使用注释来解释代码的意图。

13．注释代码中不十分明显的任何内容。

14．为了防止问题反复出现，对错误修复和解决方法代码总是使用注释，尤其是在团队环境中。

15．对由循环和逻辑分支组成的代码使用注释。这些是帮助源代码读者的主要方面。

16．在整个应用程序中，使用具有一致的标点和结构的统一样式来构造注释。

 

　　格式格式化使代码的逻辑结构很明显。花时间确保源代码以一致的逻辑方式进行格式化，这对于您和必须解密源代码的其他开发人员都有帮助。

 

　　格式格式化使代码的逻辑结构很明显。花时间确保源代码以一致的逻辑方式进行格式化，这对于您和必须解密源代码的其他开发人员都有帮助。