命名规范
前言
良好的命名规范可以为团队合作开发推波助澜,无论在项目开发,还是产品维护上都起到了至关重要的作用。应该说命名规范是一种约定,也是程序员之间良好沟通的桥梁。
数据库中的命名规则
数据库涉及字符规则
采用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等。
Dreamweaver文件的命名规则
在Dreamweaver中用户可以对一系列不同类型的对象进行命名,这些对象包括图片、层、表单、文件、数据库域等,这些对象将会被许多不同的工作引擎进行分析处理,这些工具包括各种浏览器、JavaScript脚本解析器、网络服务器、应用程序服务器、查询语言等等。
如果某个对象的名称无法被某个解析器识别,就有可能会导致故障的发生,更加麻烦的是用户可能很难发现问题的原因,例如某个具体的特效无法正确显示,或者是在某个特殊阶段无法正确显示,有时故障可能只会在某种特殊情况或在使用某个浏览器时发生,而在其它情况下保持正常,用户将很难分析出故障是由于命名问题而导致的。
由于需要命名的对象的种类很多,对这些对象进行解析的引擎工具也很多,因此用户在给这些对象命名时应该遵循一个常规的标准,以确保普遍兼容性。命名的基本原则就是:使用独一无二的、小写、不带空格的名称,名称应由字母和数字组成,并以字母开始,名称中可以包含"_"符号。
1、独一无二
请确保某对象的名称与其它对象不同,保证其独一无二的属性。
例如:你可以将某对象命名为"feedback_button_3"
2、小写
有些服务器和脚本解析器对文件名的大小写也进行检查,而为了避免因大小写引起的不兼容问题,建议用户在命名时全部使用小写文件名。
3、不带空格
不同的解析器对空格等符号的解析结果不同,例如某些解析器会把空格视为某个十六进制的数值,因此建议用户使用不带空格的单词作为文件对象的名称。
4、词数混合
用户在命名中可以随意使用26个罗马字母以及10个阿拉伯数字,而不建议使用其它标点符号。
5、以字母开始
有些解析器不喜欢以数字开头的文件名。
例如: 在某些浏览器中的JavaScript脚本内部,如果使用"alpha23"这样的名称就不会出现问题,而如果使用"23alpha"这样的名称就可能会发生故障。
6、可包含"_"符号
为了使某个对象的文件名独一无二,用户可以通过使用"_"符号来更加详细地描述文件名。
例如: 某对象的文件名可以是"jd_background_17"。
除了上述原则标准之外,我们还需要注意一些其它情况,如文件名与系统的冲突。某些文件名可能满足上述标准,但可能还会导致故障的发生,原因是因为它们与系统产生了冲突。
例如:当在使用JavaScript脚本函数时,不建议用户将某个变量命名为"for",因为"for"在本系统下是一个工作语言字串,使用其命名某个变量可能会导致解析器工作出错。许多程序都有一些保留名称,这些名称一般不建议用户使用。
例如:用户使用某个SQL程序保留的名称来命名某个数据库域,SQL对其进行分析时就可能会报错。
此外,用户在将不同来源的代码编到一起时,应该注意文件名的冲突情况。
例如: 用户把来自不同资源的两个JavaScript行为代码编至同一网页内,而这两个行为代码的变量名相同,这时就有可能出现问题。
因此做为查询故障的一个技巧,在出现故障时,用户可以查询一下相同网页中是否存在相同文件名的变量名称。
CSS类及id中的命名规则
Web开发人员可以通过创建CSS类及id名称并使用这些名称来对div以及其他的格式页面元素进行标识。对开发人员来说,在命名重新定义XHTML标记(tags)的CSS selectors时,必须保证其与预定义的标记准确匹配,但就类以及id选择器名称而言,则仁者见仁,智者见智。然而随心所欲的为这些类以及id命名则并不是个好的习惯。
1、直观命名
当在设计Web页面以及需要对一个div进行标识的时候,最自然的想法就是使用可以描述元素所在页面位置的词汇来对其命名。
例如:top-panel
horizontal-nav
left-side
center-column
right-col
这些是CSS以及XHTML类和id的有效命名方式。这些词汇简单并且能够使人顾名思义,因此满足了标识页面元素以及相应的CSS样式的需要。
但问题是这样的名称同页面内容的特定表达方式相关联。这些命名参考了某种特定页面布局中的页面元素位置,因此在这样的布局之外使用就会显得不合适甚至造成理解混乱。这些命名没有涉及文档内容的结构。因此,下面给出了对CSS类以及ID命名更好的方法。
2、结构化命名
这些是CSS以及XHTML类和id的有效命名方式。这些词汇简单并且能够使人顾名思义,因此满足了标识页面元素以及相应的CSS样式的需要。 这些是CSS以及XHTML类和id的有效命名方式。这些词汇简单并且能够使人顾名思义,因此满足了标识页面元素以及相应的CSS样式的需要。
有标记的相关信息都是用来描述文档的结构而不是外观。这样的特点使得我们可以通过简单的改变CSS的方式来对不同外观格式下的内容(content)以及标记(markup)进行重用。当你理解这种方式时,很容易就可以发现采用页面位置来为类以及id命名的方式在处理如音频(audio)等外观格式上显得非常不合适。因此,应当根据在文档中的使用目的而非出现位置来对类以及id进行结构化命名。
可以按照如下所示的结构化方式来对类以及id名称命名:
例如:branding
main-nav
subnav
main-content
sidebar
这些名字同直观命名方式一样非常易懂,但他们描述了页面元素的作用而非位置。这使得代码更加符合使用纯粹的结构化标记(structural markup)的初衷,即开发人员可以在不改变标记的情况下对各种各样媒体下的显示格式进行处理。
即使你不打算在其他的媒体上对Web页面进行格式修改,使用结构化命名方式还可以帮助你在日后的站点升级或重新设计中更为轻松。例如,结构化命名避免了当一个div同id right-column移动到页面左边后所带来的混乱。对div sidebar的采用这样的命名方式就显得更加适当,因为无论它出现在页面的哪一边,这个名字仍然对开发人员来说直观易懂。
3、惯例
Andy Clarke分析了40份由推崇标准化Web设计理念的开发人员所设计的Web站点的源代码。尽管类以及id名称很不统一,但是还是发现了一些频繁出现的常用名称。这里给出了最常用类/id名称的示例列表:
例如:header
content
nav
sidebar
footer
后记
良好的命名对于软件开发起着至关重要的作用,能够对资源进行合理的命名,可以达到事半功倍的效果。无论是哪种命名规则,无论是对哪种资源进行命名,其核心思想都是“用最少的字母进行最全面的描述”。正如本文开始时强调的,“唯一性+描述性”是命名的灵魂。所以,在您对程序的各个方面进行命名的时候,不妨去参照着这两大原则去进行,切记不可图一时之快,却为日后的修改或维护带来巨大的困难。