成为一个优秀的开发人员首先要有良好的编码习惯,以下文章摘自
http://www.cnblogs.com/tqsummer/archive/2011/03/07/1974795.html
1..NET中的命名规则 2. 3. 4. 5.名称空间的命名 6. 7. 命名名称空间的一般规则如下: 8. CompanyName.TechnologyName 9. 这样,我们看到的名称空间应该是这样的: 10. Microsoft.Office 11. PowerSoft.PowerBuilder 12. 13. 注意:这只是一个原则。第三方公司可以选择其它的名字。 14. 避免用公司名称或其它著名品牌的名称作为名称空间的前缀,这样会造成两个公布的名称空间有同一个名称的可能性。 15. 例如: 将微软提供的Office自动类命名为Microsoft.Office 16. 17. 使用Pascal大写方式,用逗号分隔逻辑成分。 18. 例如:Microsoft.Office.PowerPoint 19. 20. 如果你的品牌使用的是非传统大写方式,那么一定要遵循你的品牌所确定使用的大写方式,即使这种方式背离了通常的名称空间大写规则。 21. 例如:NeXT.WebObjects 22. ee.cummings 23. 24. 25.类和类成分的命名 26. 27. 类的命名原则是用名词或名词短语命名类,使用Pascal大写。减少类名中缩写的使用量。不要使用任何类前缀(比如C),不要使用带下划线的字符。 28. 例如:public class FileStream {} 29. public class Button {} 30. public class String {} 31. 32.变量的命名 33. 34. 名称中各单词首字母均为大写。 35. 例如:FindLastRecord 36. RedrawMyForm 37. 在内部范围中避免使用与外部范围中的名称相同的名称。若访问错误变量,则会产生错误结果。若变量与同一名称的关键字冲突,则必须在关键字前加适当的类型库以作标识。 38. 例如:若有一个名为 date 的变量,只能通过调用 System.Date 来使用内部 Date 函数。 39. 40.函数和方法的命名 41. 42. 函数和方法的命名应该以动词开始,使用Pascal大写。不要使用带下划线的字符。 43. 例如:InitNameArray 44. CloseDialog 45. 46.接口命名原则 47. 48. 使用名词或名词短语,或者描述行为的形容词来命名接口,使用Pascal大写。 减少接口名中缩写的使用量,在接口名前加前缀I,以表示这个类型是一个接口。 49. 例如: IComponent(描述性名词) 50. ICustomAttributeProvider(名词短语) 51. IPersistable(形容词) 52. 53.参数的命名 54. 55. 使用描述性参数名。参数名应该具有足够的描述性,这样在大多数情况下参数名和它的种类可以用来确定它的意思。根据参数的意思来命名参数,而不是根据参数的种类来命名。我们希望开发工具可以用很方便的方式提供关于参数种类的信息,这样参数名可以得到更好的使用,可以对语义而不是对种类进行描述。但是偶尔使用根据类型命名的参数名也是完全可以的。不要使用保留参数。如果在下一个版本中需要更多的数据,可以增加进来。 56. 例如:Type GetType (string typeName) 57. string Format (string format, object [ ] args) 58. 59.属性的命名 60. 61. 用名词或名词短语命名属性,属性与类型要一样。 用与一个类型的名称相同的名字来命名属性时,就使这个属性的类型成为那个类型。虽然听起来有些奇怪,但这是正确的。 62. 例如:public enum Color {...} 63. public class Control { 64. public Color Color {get {...} set {...}} 65. } 66. 67.事件的命名 68. 69. 用EventHandloer后缀命名事件处理程序,使用名为sender和e的两个参数,Sender参数代表提出事件的对象。Sender参数永远是一个类型对象,即使它可能使用了更为特定的类型,与事件相关的状态被封装在一个名为e的事件类范例中。要使用这个类型的正确的、特定的事件类。 70. 例如:public delegate void MouseEventHandler(object sender, MouseEvent e); 71. 命名事件名时,需要有之前和之后的时态概念,因此要使用现在时态和过去时态(不要使用BeforeXxx\\AfterXxx的方式)。例如,可以被取消的结束事件就有Closing事件和Closed事件。 72. 73.长项和常用项的命名 74. 75. 可使用缩写使名称长度适中,通常,多于 32 个字符的变量名在低分辨率的监视器上难以阅读。同时,请确保缩写在整个应用程序中保持一致。 76. 例如:可以使用“HTML”代替“HyperText Markup Language”。 77. 78.代码书写格式规范 79. 80.文件之中不得存在无规则的空行,比如说连续十个空行。一般来讲函数与函数之间的空行为2-3行。 81.在函数体内部,在逻辑上独立的两个函数块可适当空行,一般为1-2行。 82.每行长度尽量避免超过屏幕宽度,应不超过80个字符。 83.尽量用公共过程或子程序去代替重复的功能代码段。 84.使用括号清晰地表达算术表达式和逻辑表达式的运算顺序。如将 x=a*b/c*d 写成 x=(a*b/c)*d可避免阅读者误解为x=(a*b)/(c*d)。 85.避免采用过于复杂的条件测试。 86.避免过多的循环嵌套和条件嵌套。 87.一个函数不要超过200行。一个文件应避免超过2000行。 88.避免使用goto语句。 89.避免采用多赋值语句,如x = y = z;。 90.代码注释规范 91. 92. .cs文件的注释 93. 所有.cs文件开头都要加上注释,写明文件创建时间、作者、用途概述等 94. 例如: 95. 96.//******************************************************** 97. 98.//新增日期:2004.7.19 99. 100.//作者:XXX 101. 102.//內容说明: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 103. 104.//******************************************************** 105. 106. 函数过程注释 107. 所有的函数体开头都要加上注释,所以注释使用.NET注释规范。 108. 例如: 109. 110./// <summary> 111. 112./// 构造函数 113. 114./// </summary> 115. 116./// <param name='is_xxx1'>示例参数1</param> 117. 118./// <param name='is_xxx2'>示例参数2</param> 119. 120.public UpgradeThread(string is_xxx1, string is_xxx2) 121. 122.{ 123. 124.//… 125.} 126. 127. 常量变量注释 128. 所有的常量变量,无论是全局还是局部使用的,凡是对代码整体起到关键性做用的都需要加上注释。 129. 例如: 130. 131./// <summary> 132. 133./// 当前线程指向的备份文件本地保存路径 134. 135./// </summary> 136. 137.public string StorePath = ''; 138. 139. 代码修改注释 140. 当开发者维护以前的程序代码时,需要在修改处的开始及结尾,加上自己的注释信息。 141. 例如: 142. 143.//BEGIN 2004-7-19 Jayson 修正了XXX问题 144.略… 145.//END 2004-7-19 Jayson 146. 147.
1.网站文件命名规则 2. 3. 关于文件的命名,看似无足重轻,但实际上如果没有良好的命名规则进行必要的约束,一味的乱起名称,最终导致的结果就是整个网站或是文件夹无法管理。所以,命名规则在这里同样非常重要。 需要特别注意的时候,网站文件或文件夹命名请尽量避免使用中文字符命名。 4. 5.文件的命名 6. 7. 以最少的字母达到最容易理解的意义。 8. 索引文件统一使用index.html文件名(小写) index.html文件统一作为"桥页",不制作具体内容,仅仅作为跳转页和meta标签页。主内容页为main.html。 9. 按菜单名的英语翻译取单一单词为名称。所有单英文单词文件名都必须为小写,所有组合英文单词文件名第二个起第一个字母大写; 所有文件名字母间连线都为下划线。 10. 例如: 关于我们 \aboutus 11. 信息反馈 \feedback 12. 产 品 \product 13. 14.图片的命名 15. 16. 以图片英语字母为名。以最少的字母达到最容易理解的意义。 17. 对于较小的图片,我们使用如下格式的命名 : 18. sm.kahn.gif 19. 其中,sm 代表“small”,kahn 代表图片的内容。较大图像的命名规则也一样,不过是以 bg 开头的: 20. bg.kahn.gif 21. 用以区分不同图像的命名规则应当是全站通用的,这样可以尽量避免将不同的名称搅混。 22. 23.网站目录的命名 24. 25. 目录建立的原则是以最少的层次提供最清晰简便的访问结构。 26. 服务器的ftp上传目录默认为html 根目录文件 根目录只允许存放index.html和main.html文件,以及其他必须的系统文件。 27. 每个语言版本存放于独立的目录。已有版本语言设置为: 简体中文 \gb 繁体中文 \big5 英 语 \en 日 语 \jp 每个主要功能(主菜单)建立一个相应的独立目录。 根目录下的images为存放公用图片目录,每个目录下私有图片存放于各自独立images目录. 28. 例如: \menu1\images 29. \menu2\images 30. 另外,所有的js文件存放在根目录下统一目录\script 所有的CSS文件存放在根目录下的style目录 所有的CGI程序存放在根目录并列目录\cgi_bin目录。 31. 对于一些信息更新量比较大的站点或是栏目,还可以采用一种更为特殊的方式来进行文件架的命名,这样能使得日后的维护更加方便,这样的方式就是使用“单一单词命名的目录”+“年年年年_月月_日日”的方式命名,最后的“日日”是根据更新量大小可选择的,如果每日更新量很大则可以加上“日日”。 32. 例如: \news\2005_08\ 33. \news\2005_09\ 34. \news\2005_10_12\
1.CSS类及id中的命名规则 2. 3. 4. Web开发人员可以通过创建CSS类及id名称并使用这些名称来对divs以及其他的格式页面元素进行标识。对开发人员来说,在命名重新定义XHTML标记(tags)的CSS selectors时,必须保证其与预定义的标记准确匹配,但就类以及id选择器名称而言,则仁者见仁,智者见智。然而随心所欲的为这些类以及id命名则并不是个好的习惯。 5. 6.直观命名 7. 8. 当在设计Web页面以及需要对一个div进行标识的时候,最自然的想法就是使用可以描述元素所在页面位置的词汇来对其命名。 9. 例如:top-panel 10. horizontal-nav 11. left-side 12. center-column 13. right-col 14. 15. 这些是CSS以及XHTML类和id的有效命名方式。这些词汇简单并且能够使人顾名思义,因此满足了标识页面元素以及相应的CSS样式的需要。 16. 17. 但问题是这样的名称同页面内容的特定表达方式相关联。这些命名参考了某种特定页面布局中的页面元素位置,因此在这样的布局之外使用就会显得不合适甚至造成理解混乱。这些命名没有涉及文档内容的结构。因此,下面给出了对CSS类以及ID命名更好的方法。 18. 19.结构化命名 20. 21. 22. 这些是CSS以及XHTML类和id的有效命名方式。这些词汇简单并且能够使人顾名思义,因此满足了标识页面元素以及相应的CSS样式的需要。 这些是CSS以及XHTML类和id的有效命名方式。这些词汇简单并且能够使人顾名思义,因此满足了标识页面元素以及相应的CSS样式的需要。 23. 24. 有标记的相关信息都是用来描述文档的结构而不是外观。这样的特点使得我们可以通过简单的改变CSS的方式来对不同外观格式下的内容(content)以及标记(markup)进行重用。当你理解这种方式时,很容易就可以发现采用页面位置来为类以及id命名的方式在处理如音频(audio)等外观格式上显得非常不合适。因此,应当根据在文档中的使用目的而非出现位置来对类以及id进行结构化命名。 25. 26. 可以按照如下所示的结构化方式来对类以及id名称命名: 27. 例如:branding 28. main-nav 29. subnav 30. main-content 31. sidebar 32. 33. 这些名字同直观命名方式一样非常易懂,但他们描述了页面元素的作用而非位置。这使得代码更加符合使用纯粹的结构化标记(structural markup)的初衷,即开发人员可以在不改变标记的情况下对各种各样媒体下的显示格式进行处理。 34. 35. 即使你不打算在其他的媒体上对Web页面进行格式修改,使用结构化命名方式还可以帮助你在日后的站点升级或重新设计中更为轻松。例如,结构化命名避免了当一个div同id right-column移动到页面左边后所带来的混乱。对div sidebar的采用这样的命名方式就显得更加适当,因为无论它出现在页面的哪一边,这个名字仍然对开发人员来说直观易懂。 36. 37. 38.惯例 39. 40. 41. Andy Clarke分析了40份由推崇标准化Web设计理念的开发人员所设计的Web站点的源代码。尽管类以及id名称很不统一,但是还是发现了一些频繁出现的常用名称。这里给出了最常用类/id名称的示例列表: 42. 43. 例如:header 44. content 45. nav 46. sidebar 47. footer
数据库涉及字符规则
采用26个英文字母(区分大小写)和0 -9这十个自然数,加上下划线_组成,共63个字符。不能出现其他字符(注释除外)。
据库对象命名规则
数据库对象包括表、视图(查询)、存储过程(参数查询)、函数、约束。对象名字由前缀和实际名字组成,长度不超过30。前缀:使用小写字母。
例如:
表 tb 视图 vi 存储过程 sp 函数 fn
实际名字
实际名字尽量描述实体的内容,由单词或单词组合,每个单词的首字母大写,其他字母小写,不以数字和_开头。 例如:
表 User_Info 视图 UserList 存储过程 UserDelete 因此,合法的对象名字类似如下。
表 tbUser_Info、tbMessage_Detail 视图 vi_MessageList 存储过程 sp_MessageAdd
数据库表命名规则
字段由前缀和实际名字组成。实际名字中首单词一个系统尽量采取同一单词。 前缀:使用小写字母tb,表示表。 例如:tbMember tbMember_Info tbForum_Board tbForum_Thread1
字段命名规则
数字、字符、日期/时间、lob(大对象)、杂项,字段由表的简称、下划线,实际名字加后缀组成。 后缀:使用小写字母,代表该字段的属性。 例如: User_Idint User_Namestr User_RegDatedtm
视图命名规则
字段由前缀和实际名字组成,中间用下划线连接。 前缀:使用小写字母vi,表示视图。 例如:vi_User vi_UserInfo
存储过程命名规则
字段由前缀和实际名字组成,中间用下划线连接。 前缀:使用小写字母sp,表示存储过程。 例如:sp_User
数据库设计文档规则
所有数据库设计要写成文档,文档以模块化形式表达。大致格式如下: '------------------------------------------- ' 表名: tbUser_Info ' 建立人:UAM_Richard ' 日期: 2004-12-17 ' 版本: 1.0 ' 描述: 保存用户资料 ' 具体内容: ' UserId int,自动增量 用户代码 ' UserName char(12) 用户名字 ' ...... '--------------------------------------------
sql语句规则
所有sql关键词全部大写,比如SELECT,UPDATE,FROM,ORDER,BY等。
后记:
良好的命名对于软件开发起着至关重要的作用,能够对资源进行合理的命名,可以达到事半功倍的效果。无论是哪种命名规则,无论是对哪种资源进行命名,其核心思想都是“用最少的字母进行最全面的描述”。正如本文开始时强调的,“唯一性+描述性”是命名的灵魂。所以,在您对程序的各个方面进行命名的时候,不妨去参照着这两大原则去进行,切记不可图一时之快,却为日后的修改或维护带来巨大的困难。