C#书写规范

  C#书写规范 

    

 

一、命名

 

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

 

命名原则是：

 

选择正确名称时的困难可能表明需要进一步分析或定义项的目的。使名称足够长以便有一定的意澹⑶易愎欢桃员苊馊叱ぁＮㄒ幻圃诒喑躺辖鲇糜诮飨钋挚１硐至η康拿剖俏税镏嗣窃亩粒灰虼耍峁┤嗣强梢岳斫獾拿剖怯幸庖宓摹２还肴繁Ｑ≡竦拿品鲜视糜镅缘墓嬖蚝捅曜肌?SPAN lang=EN-US>

 

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

 

1、方法、属性、变量规范

避免容易被主观解释的难懂的名称，如方面名 AnalyzeThis()，或者属性名 xxK8。这样的名称会导致多义性。

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

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

在允许函数重载的语言中，所有重载都应该执行相似的函数。

只要合适，在变量名的末尾或开头加计算限定符（Avg、Sum、Min、Max、Index）。

在变量名中使用互补对，如 min/max、begin/end 和 open/close。

鉴于大多数名称都是通过连接若干单词构造的，请使用大小写混合的格式以简化它们的阅读。另外，为了帮助区分变量和例程，请对例程名称使用 Pascal 大小写处理 (CalculateInvoiceTotal)，其中每个单词的第一个字母都是大写的。对于变量名，请使用 camel 大小写处理 (documentFormatType)，其中除了第一个单词外每个单词的第一个字母都是大写的。

布尔变量名应该包含 Is，这意味着 Yes/No 或 True/False 值，如 fileIsFound。

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

即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。仅对于短循环索引使用单字母变量名，如 i 或 j。

可能的情况下，尽量不要使用原义数字或原义字符串，如 For i = 1 To 7。而是使用命名常数，如 For i = 1 To NUM_DAYS_IN_WEEK 以便于维护和理解。

 

二、代码书写规范

 

    格式化使代码的逻辑结构很明显。花时间确保源代码以一致的逻辑方式进行格式化，这对于您和你的开发小组，以及以后维护源代码的其他开发人员都有很大的帮助。

 

以下几点是推荐的格式化方法。

 

建立标准的缩进大小（如四个空格），并一致地使用此标准。用规定的缩进对齐代码节。

在发布源代码的硬拷贝版本时使用特定的字体以及字号（新宋体、小五号）。

在括号对对齐的位置垂直对齐左括号和右括号，如：

 

      for (i = 0; i < 100; i++)

      {

           ;          

      }

也可以使用倾斜样式，即左括号出现在行尾，右括号出现在行首，如：

 

      for (i = 0; i < 100; i++){

;

   }

无论选择哪种样式，请在整个源代码中使用那个样式。

 

沿逻辑结构行缩进代码。没有缩进，代码将变得难以理解，如：

              if(expression )

 

              {

 

                   //

 

                   //此处填写你的代码块;

 

                   //

 

              }

 

 

 

              if(expression )

 

              {

 

                   //

 

                   //此处填写你的代码块;

 

                   //

 

              }

 

              else

 

              {

 

                   //

 

                   //此处填写你的代码块;

 

                   //

 

              }

 

缩进代码会产生出更容易阅读的代码，如：

 

if(expression )

 

        {

 

              if(expression )

 

              {

 

                   //

 

                   //此处填写你的代码块;

 

                   //

 

              }

 

              else

 

              {

 

                   //

 

                   //此处填写你的代码块;

 

                   //

 

              }

 

         }

 

为注释和代码建立最大的行长度，以避免不得不滚动源代码编辑器，并且可以提供整齐的硬拷贝表示形式。

在大多数运算符之前和之后使用空格，这样做时不会改变代码的意图。但是，C++ 中使用的指针表示法是一个例外。

使用空白为源代码提供结构线索。这样做会创建代码“段”，有助于读者理解软件的逻辑分段。

当一行内容太长而必须换行时，在后面换行代码中要使用缩进格式，如下：

string inserString = "Insert Into TableName(username,password,email,sex,address)"

 

+ "Values('Soholife','chenyp','soholife@sina.com','male','深圳福田')";

 

 

 

只要合适，每一行上放置的语句避免超过一条。例外是 C、C++、C# 或 JScript 中的循环，如 for (i = 0; i < 100; i++)。

编写 HTML 时，建立标准的标记和属性格式，如所有标记都大写或所有属性都小写。另一种方法是，坚持 XHTML 规范以确保所有 HTML 文档都有效。尽管在创建 Web 页时需折中考虑文件大小，但应使用带引号的属性值和结束标记以方便维护。

编写 SQL 语句时，对于关键字使用全部大写，对于数据库元素（如表、列和视图）使用大小写混合。

在物理文件之间在逻辑上划分源代码。

将每个主要的 SQL 子句放在不同的行上，这样更容易阅读和编辑语句，例如：

      SELECT FirstName, LastName

      FROM Customers

          WHERE State = 'WA'

将大的复杂代码段分为较小的、易于理解的模块。

 

 

 

 

三、注释

 

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

 

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

 

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

 

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

 

如果用 C# 进行开发，请使用 XML 文档格式，如下面方法的注释：

/// <summary>

 

         /// 得到某人的年龄

 

         /// </summary>

 

         /// <param name="userName">用户名</param>

 

         /// <returns>用户年龄</returns>

 

         public int GetUserAge(string userName)

 

         {

 

              //

 

              //此处写你的程序代码

 

              //

 

     }

 

 

 

 

 

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

在每个例程的开始，提供标准的注释样本以指示例程的用途、假设和限制很有帮助。注释样本应该是解释它为什么存在和可以做什么的简短介绍。

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

避免杂乱的注释，如一整行星号。而是应该使用空白将注释同代码分开。

避免在块注释的周围加上印刷框。这样看起来可能很漂亮，但是难于维护。

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

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

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

在编写代码时就注释，因为以后很可能没有时间这样做。另外，如果有机会复查已编写的代码，在今天看来很明显的东西六周以后或许就不明显了。

避免多余的或不适当的注释，如幽默的不主要的备注。

使用注释来解释代码的意图。它们不应作为代码的联机翻译。

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

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

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

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

用空白将注释同注释分隔符分开。在没有颜色提示的情况下查看注释时，这样做会使注释很明显且容易被找到。