C#基本书写规范

C#标记规则一、命名为了理解应用的逻辑流，命名方案是最有影响的帮助。 名字需要解释“什么”，而不是“方法”。 通过避免使用更改的公共基础实现的名称，可以保留简化了复杂性的抽象层。 例如，可以使用GetNextStudent ()，而不是GetNextStudent ()。命名原则如下：选择正确的名称可能很难表示需要进一步分析和定义项目。 使名称足够长以具有一定的意义，并足够短以避免冗馀。 唯一的名称在编程中只用于区分各项目. 表现力强的名字是为了帮助人们阅读，因此提供人们能理解的名称是有意义的。 但是，请确保所选名称符合适用语言的规则和标准。以下是建议的命名方法。1 .方法、属性和变量规范请避免主观上很难解释的名称，如AnalyzeThis ()和属性名称xxK8。 这样的名字会招致多义性。在面向对象的语言中，在类属性的名称中包含类名称太多，如Book.BookTitle。 应该使用Book.Title。动词-使用名词方法命名对特定对象执行特定操作的例程，例如CalculateInvoiceTotal ()。在允许重新加载函数的语言中，所有重新加载都必须执行相同的函数。如果合适，在变量名称的末尾或开头附加计算修饰符(Avg、Sum、Min、Max、Index )。对于变量名称，请使用min/max、begin/end、open/close等互补对。因为大多数名称都是由多个单词连接而成的，所以请使用大小写混合的格式来容易阅读。 此外，要区分变量和例程，请在例程名称中使用Pascal大小写。 每个单词的第一个字母是大写的。 变量名称使用camel大小写。 除了第一个单词以外，所有单词的第一个字符都是大写的。布尔变量名称必须包含Is。 也就是说，是/否或True/False值(例如fileIsFound )。命名状态变量时，请勿使用Flag等术语。 状态变量与布尔变量的不同之处在于有两个或多个可能的值。 使用文档格式等有意义的名称，而不是文档标志。 (这是作为参考用的)即使只出现在某些代码行中的生存时间较短的变量也使用有意义的名称。 仅对短循环索引使用单个字符变量名称，如I和j。尽可能不要使用原义数字或原义字符串(For i=1 To 7等)。 而是使用命名常数(如For i=1 To NUM_DAYS_IN_WEEK )来促进维护和理解。二、代码表示规范格式明确了代码的逻辑结构. 花费时间将源代码以一致的逻辑格式格式化，对你和你的开发团队以及将来保持源代码的其他开发者都是非常有用的。以下是推荐的格式化方法。创建标准缩进大小(如四个空间)，并始终使用此标准。 按规定的缩进排列代码节。在公开源代码的硬拷贝版本时，使用特定的字体和尺寸(新宋体，小五号)。在括号对齐中垂直对齐左括号和右括号，如下所示for (i=0； i 100； PS )举止灬以下也可以使用倾斜样式，如下所示。 左括号显示在行的末尾，右括号显示在行的开头for (i=0； i 100； 表示I )灬以下无论选择哪种样式，都应该在整个源代码中使用该样式。沿着逻辑结构行缩进代码。 如果没有缩进，以下代码就很难理解if(expression )举止/在这里填写你的代码块/以下if(expression )举止/在这里填写你的代码块/以下else举止/在这里填写你的代码块/以下缩进代码会生成一个易读的代码，如if(expression )举止if(expression )举止/在这里填写你的代码块/以下else举止/在这里填写你的代码块/以下以下设置注释和代码的最大行长，使源代码编辑器不得不滚动，以便提供准确的硬拷贝表示。在大多数运算符前后使用空格，以避免改变代码的意图。 但是，在c中使用的指针表现是例外的。使用空白为源代码提供结构性线程. 这将创建代码“段”，有助于读者理解软件的逻辑段。如果行内容太长，需要换行，请在后续换行代码中使用缩进格式stringinserstring= insert into tablename (用户名称、密码、电子邮件、sex、地址) Values(Soholife、chenyp、、male、深圳福田) ；如果合适，放置在每行上的语句不要超过一个。 例外是for (i=0； i 100； I )。创建HTML时，会创建标准标签和属性格式，例如所有标签是大写的还是所有属性都是小写的。 另一种方法是坚持XHTML规范，以确保所有HTML文档都有效。 创建网页时，必须折中文件大小，但为了便于管理，必须使用引号中的属性值和结束标记。在编写SQL语句时，所有关键字都使用大写，而数据库元素(如表、列和视图)则使用大写和小写的混合。在物理文件之间逻辑分割源代码。将主要的SQL子句放置在单独的行上，可以更容易地阅读和编辑语句，如下所示选择第一个名称，最后一个名称从客户公司WHERE State=WA将大的复杂代码段分成小的、容易理解的模块。三、注释软件文档以外部和内部两种形式存在。 规范、帮助文件和设计文档等外部文档在源代码外部进行管理。 内部文档由开发者在开发时在源代码中描述的注释组成。无论外部文档的可用性如何，硬拷贝的文档都可能是错误的，所以源代码列表必须独立存在。 外部文档必须由规范、设计文档、变更请求、错误历史记录和要使用的编码标准组成。内部软件文档的一个难题是确保注释的维护和更新与源代码同时进行。 正确评论源代码在运行时没有任何目的，但是对需要保持复杂、麻烦的软件段的开发者来说尤其重要。建议的评论方法如下：使用C#开发时，使用以下XML文档格式/得到某人的年龄/用户名/用户年龄publicintgetuserage (字符串用户名称)举止/在这里写你的程序代码/以下修改代码时，总是使代码周围的注释最新。在每个例程开始时，提供标准注释样本以指示例程的目的、前提条件和限制很有用。 注释样本应该是说明为什么存在和可以做什么的简单介绍。不要在代码行的末尾添加注释行末的注释使代码很难阅读。 但是，如果声明了注释变量，则行尾注释是适当的，在这种情况下，所有行尾注释都将与公共制表位对齐。避免像行星号码一样杂乱的注释。 相反，必须使用空白将注释与代码分离。请不要在块注释的周围加印刷框。 也许看起来很漂亮，但很难维护。在部署之前，请删除所有临时和不相关的评论，以防止在以后的维护工作中出现混乱。如果需要用注释说明复杂的代码段，请检查此代码以确定是否需要复盖。 为了不评论难以理解的代码，应该尽量重写。 一般来说，为了使代码更易于使用，不应该牺牲性能，但必须在性能和可维护性之间保持平衡。创建注释时，请使用完整的语句。 评论不应该明确代码，增加多义性。写代码时评论是因为以后很可能没有时间了。 另外，如果有机会再研究写的代码的话，今天变得清楚的东西可能6周后就不会变得清楚了。避免多馀或不适当的注释，如非幽默的主要注释。使用注释来说明代码的意图。 这些并不是代码的在线翻译.评论代码中有不太清楚的东西。为了不重复