Java语言编码规范
1 介绍(Introduction)
1.1为什么要有编码规范(Why Have Code Conventions)
编码规范对于程序员而言尤为重要，有以下几个原因：
可读性：编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码
规范性：编码规范可以提高代码的规范性，使程序逻辑更加清晰
可维护性：一个软件的生命周期中，80%的花费在于维护；几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护
产品发布：如果你将源码作为产品发布，就需要确认它是否被很好的打包并且清晰无误，一如你已构建的其它任何产品
为了执行规范，每个软件开发人员必须一致遵守编码规范。
2.文件组织(File Organization)
超过2000行的Java程序文件难以阅读，应该尽量避免。
2.1JAVA源文件(Java Source Files)
每个Java源文件都包含一个单一的公共类或接口。若私有类和接口与一个公共类相关联，可以将它们和公共类放入同一个源文件。公共类必须是这个文件中的第一个类或接口。
Java源文件还遵循以下规则：
开头注释(Beginning Comments)
包和引入语句(Package and Import Statements)
类和接口声明(Class and Interface Delarations)
2.1.1开头注释(Beginning Comments)
所有的源文件都应该在开头有一个的注释，其中列出类名、版本信息、日期和版权声明：
/*
Classname
*
Version information
*
Date
*
Copyright notice
*/
2.1.2包和引入语句(Package and Import Statements)
在多数Java源文件中，第一个非注释行是包语句，在它之后可以跟引入语句。例如：
package java.awt;
import java.awt.peer.CanvasPeer;
2.1.3类和接口说明(Class and Interface Delarations)
下表描述了类和接口声明的各个部分以及它们出现的先后次序。
类/接口声明的各部分及注解(其中注释部分不是必须的)：
类或接口的声明
类/接口实现注释(/*……*/)：该注释应包含任何关于整个类或接口的信息(，而这些信息又不适合作为类/接口文档注释。)
类的(静态Static)变量：首先是类的公共变量(public)，随后是保护变量(protected),再后是包一级别的变量(没有访问修饰符，access modifier)，最后是私有变量(private)
实例(Instance)变量：首先是公共级别的，随后是保护级别的，再后是包一级别的(没有访问修饰符)，最后是私有级别的。
构造器
方法：方法应该按功能分组，而不是按照作用域或访问权限分组。例如，一个私有的类方法可以置于两个公有的实例方法之间。其目的是为了更便于阅读和理解代码。
3.缩进排版(Indentation)
我们规定，4个空格常被作为缩进排版的一个单位。
3.1行长度(Line Length)
尽量避免一行的长度超过80个字符，因为很多终端和工具不能很好处理。
3.2换行(Wrapping Lines)
当一个表达式无法容纳在一行内时，可以依据如下一般规则断开之：
在一个逗号后面断开
在一个操作符前面断开
尽量选择在较高级别(higher-level)运算之后断开，而非较低级别(lower-level)的断开
新的一行应该与上一行同一级别表达式的开头处对齐
以下是断开方法调用的一些例子：
someMethod(longExpression1, longExpression2, longExpression3,
longExpression4, longExpression5);
var = someMethod1(longExpression1,
someMethod2(longExpression2,
longExpression3));
longName1 = longName2 * (longName3 + longName4 - longName5)
+ 4 * longname6; //PREFFER
4.注释(Comments)
注释的规范：
注释目的：注释应该使你的代码更清晰，增强程序的可读性和可维护性。
数量标准：注释应占程序代码的比例达到20%左右，即100行程序中包含20行左右的注释。
概括性：注释应被用来给出代码的总括以及代码自身没有提供的附加信息，它仅包含与阅读和理解程序有关的信息。
简洁性：只对设计中重要的或者不是显而易见的地方进行说明，而避免提供代码中己清晰表达出来的重复信息。
同步修改：修改程序代码时，一定要同时修改相关的注释，保持代码和注释的同步。
避免频繁注释：频繁的注释有时反映出代码的低质量。当你觉得被迫要加注释的时候，考虑一下重写代码使其更清晰。
注释在编译代码时会被忽略，不编译到最后的可执行文件中，所以注释不会增加可执行文件的大小。
4.1 注释的格式(Comment Formats)
程序可以有4种注释的风格：块(block)、单行(single-line)、尾端(trailing)和行末(end-of-line)。
4.1.1 块注释(Block Comments)
块注释通常用于提供对文件，方法，数据结构和算法的总体描述。块注释一般被置于每个文件的开始处以及每个方法之前。
块注释之首应该有一个空行，用于把块注释和代码分割开来，并以/*-开头，比如：
/*
Here is a block comment.
*/
4.1.2 单行注释(Single-Line Comments)
短注释可以显示在一行内，并与其后的代码具有一样的缩进层级。如果一个注释不能在一行内写完，可采用块注释。单行注释之前应该有一个空行。
4.1.3 尾端注释(Trailing Comments)
极短的注释可以与它们所要描述的代码位于同一行，但是应该有足够的空白来分开代码和注释。若有多个短注释出现于大段代码中，它们应该具有相同的缩进。
4.1.4 行末注释(End-Of-Line Comments)
注释界定符"//"，可以注释掉整行或者一行中的一部分。而对于连续多行文本的注释，建议使用"/**/"。
5.声明(Declarations)
5.1 每行声明变量的数量(Number Per Line)
推荐一行一个声明，因为这样以利于写注释
不要将不同类型变量的声明放在同一行
5.2 初始化(Initialization)
尽量在声明局部变量的同时初始化；如果变量的初始值依赖于某些先前发生的计算，可在相应处进行初始。
5.3 布局(Placement)
只在代码块的开始处声明变量(一个块是指任何被包含在大括号"{"和"}"中间的代码)，而不要在首次用到该变量时才声明之。因为这样会影响代码的可读性及其在该作用域内的可移植性。
该规则的一个例外是for循环的索引变量。
避免声明的局部变量覆盖上一级声明的变量。例如，不要在内部代码块中声明与外部相同的变量名。
5.4 类和接口的声明(Class and Interface Declarations) 类和接口的编写，应该遵守以下格式规则：
在方法名与其参数列表之前的左括号"("间不要有空格
左大括号"{"位于声明语句同行的末尾
右大括号"}"另起一行，与相应的声明语句对齐，除非是一个空语句，"}"应紧跟在"{"之后
方法与方法之间以空行分隔
class Sample extends Object {
int ivar1;
int ivar2;
Sample(int i, int j) {
ivar1 = i;
ivar2 = j;
}
int emptyMethod() {}
...
}
6.语句(Statements)
6.1 简单语句(Simple Statements)
每行至多包含一条语句
6.2 复合语句(Compound Statements)
复合语句是包含在大括号中的语句序列，形如"{ 语句}"
被括其中的语句应该较之复合语句缩进一个层次
左大括号"{"应位于复合语句起始行的行尾，右大括号"}"应另起一行并与复合语句首行对齐
大括号可以被用于所有语句，为了提高程序可读性也可对单个语句使用大括号，比如if-else或for控制结构
6.3 if-else语句(if-else Statements)
if-else语句应该具有如下格式：
if (condition) {
statements;
}
if (condition) {
statements;
} else {
statements;
}
if (condition) {
statements;
} else if (condition) {
statements;
} else{
statements;
}
注意：if语句总是用"{"和"}"括起来，为避免引起错误，即使仅有一条语句也应尽量用"{"和"}"括起来。
6.4 for语句(for Statements)
一个for语句应该具有如下格式：
for (initialization; condition; update) {
statements;
}
一个空的for语句(所有工作都在初始化，条件判断，更新子句中完成)应该具有如下格式：
for (initialization; condition; update);
当在for语句的初始化或更新子句中使用逗号时，避免因使用三个以上变量，而导致复杂度提高。若需要，可以在for循环之前(为初始化子句)或for循环末尾(为更新子句)使用单独的语句。
6.5 while语句(while Statements)
一个while语句应该具有如下格式
while (condition) {
statements;
}
一个空的while语句应该具有如下格式：
while (condition);
6.6 do-while语句(do-while Statements)
一个do-while语句应该具有如下格式：
do {
statements;
} while (condition);
6.7 switch语句(switch Statements)
一个switch语句应该具有如下格式：
switch (condition) {
case ABC:
statements;
/* falls through */
case DEF:
statements;
break;
case XYZ:
statements;
break;
default:
statements;
break;
}
每当一个case顺着往下执行时(因为没有break语句)，通常应在break语句的位置添加注释。上面的示例代码中就包含注释/* falls through */。
6.8 try-catch语句(try-catch Statements)
一个try-catch语句应该具有如下格式：
try {
statements;
} catch (ExceptionClass e) {
statements;
}
一个try-catch语句后面也可能跟着一个finally语句，不论try代码块是否顺利执行完，它都会被执行。
try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
}
7.空白(White Space)
7.1 空行(Blank Lines)
空行将逻辑上相对独立的代码段分隔开，以提高可读性。
下列情况应该总是使用两个空行：
一个源文件的两个片段(section)之间
类声明和接口声明之间
下列情况应该总是使用一个空行：
两个方法之间
方法内的局部变量和方法的第一条语句之间
块注释(参见"4.1.1")或单行注释(参见"4.1.2")之前
一个方法内的两个逻辑段之间，用以提高可读性
7.2 空格(Blank Spaces)
下列情况应该使用空格：
一个紧跟着括号的关键字应该被空格分开；但方法名与其左括号之间不应有空格，这将有助于区分关键字和方法调用。
空白应该位于参数列表中逗号的后面
除了"."以外的所有的二元运算符，应该使用空格将之与操作数分开；一元操作符和操作数之间不加空格，比如：负号("-")、自增("++")和自减("--")。
for语句中的表达式应该被空格分开
强制转型后应该跟一个空格
参考范例如下：
while (true) {
...
}
String s = Function1(para1, para2, para3);
while (d++ = s++) {
n++;
}
for (expr1; expr2; expr3)
myMethod((byte) aNum, (Object) x);
8.命名规范(Naming Conventions)
规范的命名使程序更易读，从而更易于理解；它们可以提供一些有关标识符功能的信息，使各种常量、变量、包、类、接口、方法等便于识别，以助于理解代码。另外，应尽量避免用中文命名。
9.编程惯例(Programming Practices)
9.1 提供对实例以及类变量的访问控制(Providing Access to Instance and Class Variables)
若没有足够理由，不要把实例变量或类变量声明为公有。通常，实例变量无需显式的设置(set)和获取(gotten)，通常这作为方法调用的边缘效应(side effect)而产生。
一个具有公有实例变量的恰当例子，是类仅作为数据结构，没有行为。亦即，若你要使用一个结构(struct)而非一个类(如果java支持结构的话)，那么把类的实例变量声明为公有是合适的。
9.2 引用类变量和类方法(Referring to Class Variables and Methods)
避免用一个对象访问一个类的静态变量和方法。应该用类名替代。例如：
classMethod(); //OK
AClass.classMethod(); //OK
anObject.classMethod(); //A VOID!
9.3 常量(Constants)
位于for循环中作为计数器值的数字常量，除了-1,0和1之外，不应被直接写入代码。
9.4 变量赋值(Variable Assignments)
避免在一个语句中给多个变量赋相同的值，这将降低程序的可读性。
不要将赋值运算符用在容易与相等关系运算符混淆的地方。
不要使用内嵌(embedded)赋值运算符试图提高运行时的效率，这是编译器的工作。
参考范例如下：
fooBar.fChar = barFoo.lchar = ''c''; // A VOID!
if (c++ = d++) { // A VOID! (Java disallows)
...
}
应该写成
if ((c++ = d++) != 0) {
...
}
d = (a = b + c) + r; // A VOID!
应该写成
a =
b + c;
d = a + r;
9.5其它惯例(Miscellaneous Practices)
9.5.1 圆括号(Parentheses)
在含有多种运算符的表达式中，尽量使用圆括号来避免运算符优先级问题；即便你对运算符的优先级很清楚，依然建议你这样做，因为这样可以提高你程序的可读性。
if (a == b && c == d) // A VOID!
if ((a == b) && (c == d)) // RIGHT
9.5.2 返回值(Returning Values)
设法让你的程序结构符合目的。例如：
if (booleanExpression) {
return true;
} else {
return false;
}
应该代之以如下方法：
return booleanExpression;
if (condition) {
return x;
}
return y;
应该写做：
return (condition ? x : y);
9.5.3 条件运算符"?"前的表达式(Expressions before '?' in the Conditional Operator)
如果一个包含二元运算符的表达式出现在三元运算符" ? : "的"?"之前，那么应该给表达式添上一对圆括号。例如：
(x >= 0) ? x : -x;
1.如何处理单元测试产生的数据，下列哪些说法是正确的？ABC A .测试数据入库时加特殊前缀标识。 B .测试数据使用独立的测试库。 C .自动回滚单元测试产生的脏数据。 D .无须区别，统一在业务代码中进行判断和识别。 多选2.关于并发处理，下列哪些说法符合《阿里巴巴Java开发手册》：ABC A .线程资源必须通过线程池提供，不允许在应用中自行显式创建线程。 B .同步处理时，能锁部分代码区块的情况下不要锁整个方法；高并发时，同步调用应该考虑到性能损耗。 C .创建线程或线程池时，推荐给线程指定一个有意义的名称，方便出错时回溯。 D .推荐使用Executors.newFixedThreadPool(int x)生成指定大小的线程池。(线程池不允许使用Executors 去创建，而是通过ThreadPoolExecutor 的方式) 多选3.下列哪些说法符合《阿里巴巴Java开发手册》：ACD A .对于“明确停止使用的代码和配置”，如方法、变量、类、配置文件、动态配置属性等要坚决从程序中清理出去，避免造成过多垃圾。 B .永久弃用的代码段注释掉即可，即不用加任何注释。 C .对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)来说明注释掉代码的理由。 D .不要在视图模板中加入任何复杂的逻辑。 多选4.关于分页查询，下列哪些说法符合《阿里巴巴Java开发手册》：ABC A .分页查询，当统计的count为0时，应该直接返回，不要再执行分页查询语句。 B .iBATIS自带的queryForList(String statementName,int start,int size)分页接口有性能隐患，不允许使用。 C .定义明确的sql查询语句，通过传入参数start和size来实现分页逻辑。 D .可使用存储过程写分页逻辑，提高效率。 多选5.根据《阿里巴巴Java开发手册》，以下功能必须进行水平权限控制校验的有：ABCD A .订单详情页面。 B .类目管理后台。 C .店铺装修后台。 D .订单付款页面 多选1.关于多线程并行处理定时任务的情况，下列哪些说法符合《阿里巴巴Java开发手册》：BCD A .推荐使用Timer方式处理。 B .推荐使用ScheduledExecutorService方式处理。 C .Timer运行多个TimeTask时，只要其中之一没有捕获抛出的异常，其它任务便会自动终止运行。 D .ScheduledExecutorService并发运行多个定时任务时，其中某线程抛出异常，不会影响到其它线程的继续运行。
编码规范 1.编写目的 本规范的目的在于编写可靠的、一致的、便于理解的JAVA源代码，并且写出的代码被其他人阅读，所有的JAVA代码保持良好的致性，容易在以后的阶段中进行维护和升级。同时，也是为了通过一定时间的实践，增加我们的软件产品的投入产出量，以提高我们的工作效率。 2.适应范围 适用于JAVA程序开发人员，或后续开发人员。可以方便系统的开发与维护，使系统开发与维护可以顺利展开。 3.代码命名一般原则 我们开发的是一个JSP新闻发布系统，用的编码方式是JAVA，因此用的命名总原则是： 3.1.用全英文单词命名的方式，准确地描述变量、属性、类等。 如：使用firstNname、grandTotal、等命名就比x1、y1、fn等更容易让人理解其含义，尽管它们的长度要大一些。 3.2．采用一些更加准确的术语来命名。 例如：如果我们的用户称他们的clients为customers ，那么我们就应该用customer来命名，而不是采用client来命名。这是一些细微的地方，但也希望能注意。 3.3．采用大小写混合的方式来命名，以便命名有很好的可读性。 在JAVA代码中，将采用如下原则：类或接口命名中每个单词的首字母均大写，而单词的剩余部分均小写。其它像变量、成员方法、属性等除第一个单词全部小写以外，其它单词的首写字母均大写，而单词的剩余部分均小写。 3.4．尽量少用单词的缩写形式，但如果一定要用，则选择大家通用的缩写方式，并且要在本JAVA源代码中坚持用它，而不要一会用这种缩写方式，一会用那种 缩写方式。 比如，如果要用“number”的缩写方式，则可用“no”或“num”两种缩写方式，而不要用“nu”这种大家不常用的缩写方式，并且要保持不变。 3.5．尽量避免太长的命名，一般以少于20个字符为宜。
中国移动通信企业标准 中国移动网络代维管理系统技术规范 编码规范分册 版本号：1.1.0 2012年9月发布2012年9月实施 中国移动通信集团公司
目录 1 编号规范 (2) 1.1 省级代维组织编号 (2) 1.2 地市级以下代维组织编号 (2) 1.3 人员编码 (2) 1.4 工单编号 (2) 1.5 公告编号 (2) 1.6 业务联系函编号 (2) 1.7 代维资料编号 (3) 2 编码规范 (3) 2.1 省份代码 (3) 2.2 地市 (4) 2.3 工作类别 (5) 2.4 代维专业类型 (6) 2.5 紧急程度 (6) 2.6 满意度 (6) 3 修订记录 (6)
前言 《中国移动网络代维管理系统技术规范》规定了中国移动网络代维管理系统的建设目标、建设原则、体系结构、功能结构、接口要求、技术要求，供中国移动内部和系统开发、集成厂商共同使用；是中国移动网络代维管理系统建设所依据的技术规范，用于指导全网代维管理IT化手段建设、开发与应用。 本分册是《中国移动网络代维管理系统技术规范》系列分册之一。《中国移动网络代维管理系统技术规范》系列分册的结构、名称如下： 本规范由中国移动通信集团公司网络部制订，由集团公司网络部归口和解释。 本规范起草单位：中国移动通信集团公司网络部。 本规范主要起草人：王晓琦、石晓萍、王烨、周林、夏凡超、王鹏、徐智岳、杜传业、马松、吴丹、贺军、云雅琼、杜珍祥、童克波、吕晓敏、周云斌、陈为国、陆旻、许贤、周敏、郭艺娴、赵珺、陈宏宇、于洪亮、吕敏、徐铁瑛、诸圣勇、谭凌凯、文晓林、唐继志、霍廷瑞、杨竹。
1 编号规范 1.1省级代维组织编号 DW+3位自增序号，如：DW001；建议加移动标识，如：CMJSDW001、CMZJDW001 1.2地市级以下代维组织编号 以江苏为例，5级组织结构进行参考，如下： 办事处：上级组织编号+所属地市编码+2位自增序号，如：DW0011401 项目部：上级组织编号+ 2位自增序号，如：DW001140101 驻点：上级组织编号+ 2位自增序号，如：DW00114010101 小组：上级组织编码+3位自增序号，如：DW00114010101001 1.3人员编码 DW+12位人员编码，关于代维人员编码规则（共计12位数字）如下： 1－3位代维公司编码； 4－5位地市编码； 6－9位代维人员加入系统年月，如0902； 10－13位代表入职代维公司的第几个员工。从0001开始的4位自增序号。 1.4工单编号 1.5公告编号 1.6业务联系函编号
QB ****公司企业标准 信息分类和编码 第3分册工程信息分类和编码 （初稿） 20XX-XX-XX 发布 20XX -XX -XX 发行 *****有限责任公司 发 布 ICS XXX 备案号XXX
目次 前言 (3) 引言 (4) 1范围 (5) 2规范性引用文件 (5) 3术语和定义 (5) 4分类原则和方法 (6) 4.1基本原则 (6) 4.2分类对象的层面划分 (6) 4.3工程信息分类 (7) 4.4工程信息整体框架 (8) 5编码方法 (9) 5.1基本原则 (9) 5.2码值 (9) 5.3代码组结构和层次 (10) 5.3.1交互定位码 (10) 5.3.2项目编码 (10) 5.3.3管理属性编码 (11) 5.3.4设计属性编码 (11) 5.3.5合同属性编码 (12) 5.3.6档案属性编码 (12) 5.3.7采购、财务、招标信息属性编码 (13) 5.3.8非项目信息编码 (13) 6分类与代码表 (14) 6.1非项目信息分类标识码(30301) (14) 6.2省电网公司及直属单位编码(30302) (14) 6.3工程项目建设管理单位代码(30303) (15) 6.4项目属性代码(30304) (18) 6.5综合指标(30305) (19) 6.6立项时间(30306) (20) 6.7批次项目标识码(30307) (21) 6.8信息属性码分类(30308) (21) 6.9项目阶段代码((30309) (22) 6.10工作分解代码(30310) (22) 6.11信息创建部门代码(30311) (23) 6.12设计资料分类代码(30314) (24) 6.13设计阶段代码(30315) (24) 6.14类目代码(30316) (25)
C#通用编码规范 Posted on 2010-11-03 15:31 gczhao阅读(71) 评论(0)编辑收藏 本文转自https://www.doczj.com/doc/d6799159.html,/usernam egaorn/archive/2007/10/20/1834275.aspx 基本命名规范 注记： Pascal 大小写形式：所有单词第一个字母大写，其他字母小写。 Cam el 大小写形式：除了第一个单词，所有单词第一个字母大写，其他字母小写。 对于在页面中的类，类名使用Pascal大小写形式，当然，这个类名通常情况下与前台页面的文件名是一致的，比如，对于一个页面HelloWorld.aspx，其类名会如下定义： public class HelloWorld : Page { … } 对于类库中的类，则应按照约定加一定的前缀，通常是小写字母c，比如一个通用类可以如下定义：public class cHelloWorld { … } 自然的，相应文件名也是遵循此定义格式，在本例中，为cHelloWorld.cs 类中的方法都使用Pascal大小写形式 public class HelloWorld { void SayHello ( string userName ) { … } } 变量和方法中的参数使用Cam el 大小写形式 public class HelloWorld { int totalCount = 0; void SayHello ( string userName ) { string fullMessage = "Hello " + userName; … } } 常量的定义 常量名通常全部采用单词的大写，单词之间以下划线“ _ ”隔开。
医疗保障定点医疗机构等10项信息业务 编码规则和方法 一、定点医疗机构编码规则和方法 定点医疗机构编码分3个部分共12位，通过大写英文字母和阿拉伯数字按特定顺序排列表示。其中，第1部分是定点医疗机构标识码，第2部分是行政区划代码，第3部分是定点医疗机构顺序码。定点医疗机构编码结构见图1： 图1 定点医疗机构编码结构 第1部分：定点医疗机构标识码，用1位大写英文字母“H”表示。 第2部分：行政区划代码，采用《中华人民共和国行政区划代码》（GB/T2260)，用6位阿拉伯数字表示。其中，前两位代码表示省级行政区（省、自治区、直辖市），中间两位代码表示市级行政区（市、地区、自治州、盟），后两位代码表示县级行政区（县、自治县、县级市、旗、自治旗、市辖区、林区、特区）。 第3部分：定点医疗机构顺序码，对同一市级行政区（市、地区、自治州、盟）下的定点医疗机构赋予的顺序码，用5
位阿拉伯数字表示。 二、医保医师编码规则和方法 医保医师编码分3部分共13位，通过大写英文字母和阿拉伯数字按特定顺序排列表示。其中，第1部分是医保医师标识码，第2部分是行政区划代码，第3部分是医保医师顺序码。医保医师编码结构见图2： 图2 医保医师编码结构 第1部分：医保医师标识码，用1位大写英文字母“D”表示。 第2部分：行政区划代码，采用《中华人民共和国行政区划代码》（GB/T2260)，用6位阿拉伯数字表示。其中，前两位代码表示省级行政区（省、自治区、直辖市），中间两位代码表示市级行政区（市、地区、自治州、盟），后两位代码表示县级行政区（县、自治县、县级市、旗、自治旗、市辖区、林区、特区）。 第3部分：医保医师顺序码，对同一市级行政区（市、地区、自治州、盟）下的医保医师赋予的顺序码，用6位阿拉伯数字表示。 三、医保护士编码规则和方法
黄金定律 永远遵循同一套编码规范 -- 可以是这里列出的，也可以是你自己总结的。如果你发现本规范中有任何错误，敬请指正。通过为本规范添加或贡献内容。 不管有多少人共同参与同一项目，一定要确保每一行代码都像是同一个人编写的。HTML 语法 ?用两个空格来代替制表符（tab） -- 这是唯一能保证在所有环境下获得一致展现的方法。 ?嵌套元素应当缩进一次（即两个空格）。 ?对于属性的定义，确保全部使用双引号，绝不要使用单引号。 ?不要在自闭合（self-closing）元素的尾部添加斜线 -- HTML5 规范中明确说明这是可选的。 ?不要省略可选的结束标签（closing tag）（例如， 或
