怎样编写格式优美的代码
怎样编写格式优美的代码
作者：yangw80
序
很多初学者会被人一眼就看出来是初学者，为什么？原因很多。其中，代码格式是很重要的一项。不注重代码格式，不仅别人看起来不舒服，还会影响自己对代码的阅读。虽然错误的格式不会产生编译错误，但却会让你更容易犯错，并且更难排查错误。所以，学会编写格式优美的代码，是初学者必须要学的一课。
优秀的代码格式并不是唯一的，有很多种风格。本文仅讲解常见的 C/C++ 语言编码规则，而其它规则相信大家在学习工作中会慢慢接触到。
以下讲解编写代码时在格式上一些常见的注意事项。
1. 正确缩进
所谓缩进，是指在某一行代码的左端留出一部分空白。采用缩进的目的为了清楚的定义一个块的开始和结束，这样会使程序更加清晰易读。虽然目前主流的开发平台都具备智能缩进的功能，但是很多时候修改代码还是需要自己注意缩进问题。
下面的范例代码是求解 100 以内的质数，该范例中有多种缩进情况的例子：
#include
#include
void main()
{
printf("2");
int col = 1;
for (int n = 3; n <= 100; n += 2)
{
for (int m = 3; m <= sqrt(n); m += 2)
if (n % m == 0)
break;
if (m > sqrt(n))
printf("%c%d", (col++ % 5) ? '\t' : '\n', n);
}
printf("\n");
}
除此以外，还有很多地方的范例代码有正确缩进，例如 MSDN、VC 自带的范例等。
可以看到，每行代码前的缩进清晰的表明了代码的结构，正确的缩进可以帮助开发者更清晰有效地阅读代码并发现逻辑错误。所以，掌握正确的缩进格式，是编写规范代码的第一课。
2. 学会用 tab 键缩进和对齐代码
当代码中需要缩进时，简单的按一下 tab 键就好。通常一个 tab 符占用 4 个空格的位置。每个 tab 符可以准确的将光标定位到下一个 tab 位，即 4 的整倍数的位置后面。例如，光标在行首时，按 tab 键，光标将会定位到第 4 个字符后面；光标在第 6 个字符后面时，按 tab 键，光标将会定位到第 8 个字符后面。
根据 tab 符的这个特性，除了用来缩进外，tab 键还可以用在很多地方，比如用来对齐代码。下面的范例片段用 tab 符将代码排列得很整齐：
switch(item)
{
case EMPTY: setfillstyle(BLACK); break;
case WALL: setfillstyle(LIGHTGRAY); break;
case PLAYER_A: setfillstyle(BLUE); break;
case PLAYER_B: setfillstyle(RED); break;
case PLAYER_DEAD:setfillstyle(MAGENTA); break;
}
3. 适当增加空行
虽然空行在 C/C++ 语言中没有多大实际的目的，但是通过适当的插入空行能大大提高代码的可读性。一般情况下，在逻辑上相关联的代码块之间会插入一个或多个空行。例如，头文件组、宏定义组、全局变量组之间、两个函数之间，还有函数之间以及函数内部的逻辑片断之间，都可以适当插入空行。插入空行的数量并没有严格规定，而是根据程序的规模和代码风格来适度调整。比如，一个只有 30 行左右的代码，不同的函数间插入一个空行就可以；如果是 300 行左右的代码，可以在函数间插入 3 个空行。
第 1 点的范例代码比较简短，含有少量插入空行的范例。在 EasyX 官网有更多的范例，插入空行的情况也不尽相同。这些需要在学习编程的过程中慢慢体会。
4. 适当增加空格
除了使用空行外，通过使用空格来提高代码的可读性性也是程序员常用的手段。和空行一样，空格的使用也没有强制性的规定，仅仅是为了增强代码的可读性。一般情况下，以下位置可以适当插入空格：
(1) 等号的前后；
(2) 数学运算符的前后，关键字和括号之间插入空格；
(3) 比较运算符的前后；
(4) 后面有代码的分号后面；
(5) 分割不同参数的逗号后面；为了和上下行的代码对齐，有时候需要插入两个空格；如果需要插入更多空格才能和上下代码对齐，通常会使用 tab 键。
5. 适当增加注释
不写注释的编码习惯是不可取的。在较关键的语句、函数或代码片段周围以一定方式增加注释，会令代码简洁易懂，描述清晰的注释可以让阅读代码的人像阅读散文一样舒心。
注释的方式有很多种，以下列举常见的注释方式。
(1) 语句之前的注释，例如：
// 初始化绘图窗口
initgraph(640, 480);
(2) 语句右边的注释，例如：
while(true)
{
int cmd = GetCmd();
// 获取用户命令
if (!DealCmd(cmd)) break; // 处理命令
if (!DealGame()) break; // 处理游戏
Sleep(200); // 延时
}
(3) 语句内的注释，例如：
double springF = SPRINGK /* 弹力系数 */ * (len - SEGLEN);
(4) 代码首部的描述性注释，例如，easyx 官网的很多范例顶部都有这么一段：
///////////////////////////////////////////////////
// 程序名称：xxxxxxxx
// 编译环境：Visual C++ 6.0 / 2010，EasyX_20120603(beta)
// 作者：xxxx
// 最后修改：2012-x-xx
//
(5) 函数首部的描述性注释，例如：
// 获取用户命令
int GetCmd()
{
......
}
(6) 变量后面的描述性注释（对齐注释会更漂亮），例如：
struct Mover
{
COLORREF color; // 颜色
float x, y; // 坐标
float vX, vY; // 速度
};
Phil Haack曾经说过：“一旦一行代码被敲到文件中, 你就已经要开始维护那一行代码了。”所以，我们自己就是好（或者坏）注释的第一个受益者（或者受害者）。
6. 太长的代码要折行
当一行代码很长的时候（比如函数的参数比较多、判断语句的条件比较多），为了更清晰，可以把一行长代码分成多行书写，例如：
(1) 分行写多个判断语句。看以下代码：
if (ball.x > field.width || ball.x < 0 || ball.y > field.height || ball.y < 0)
{
......
}
可以分行写成这样（其实这个例子中的代码不算长，不分行也没事，这里只是举个例子）：
if (ball.x > field.width || ball.x < 0 // 判断 x 坐标
|| ball.y > field.height || ball.y < 0) // 判断 y 坐标
{
...
}
(2) 分行写多个参数。微软在MSDN 中的很多例子都是这样做的，例如下面这段摘自MSDN 的代码：
hwnd = CreateWindow(
"MainWClass", // name of window class
"Sample", // title-bar string
WS_OVERLAPPEDWINDOW, // top-level window
CW_USEDEFAULT, // default horizontal position
CW_USEDEFAULT, // default vertical position
CW_USEDEFAULT, // default width
CW_USEDEFAULT, // default height
(HWND) NULL, // no owner window
(HMENU) NULL, // use class menu
hinstance, // handle to application instance
(LPVOID) NULL); // no window-creation data
7. 适当调整代码的表达方式
一些语句功能是相似的，适当将一些语句换一个表达方式，可以令代码更清晰。看以下代码：
ball.x = 320;
ball.y = 240;
if (new)
ball.color = BLACK;
else
ball.color = NEW;
ball.dx = rand() % 6 - 3;
ball.dy = rand() % 6 - 3;
前面这段代码没有错，但是如果修改为下面这样，会更清晰：
ball.x = 320;
ball.y = 240;
ball.color = new ? BLACK : NEW;
ball.dx = rand() % 6 - 3;
ball.dy = rand() % 6 - 3;
8. 习惯很重要
代码的格式不是要最后修改，而是要在书写代码的时候就写正确。包括注释，都要在写代码的同时就写注释，甚至还可以先写注释然后补充代码。但是，一定不要在写完代码后再补充注释。
结束
编码习惯是一种感觉，只有经常写代码、经常和伙伴们分享代码，才能熟练掌握，运用自如。
代码编写规范
知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范，为保证代码风格的一致性和后期的可维护性，文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了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）转义都是允许的。唯一需要考虑的是，何种方式更能使代码容易阅读和理解。
软件代码编写规范
? 软件销售代理合同范本软件代码编写规范 草稿 2005.2
? 软件销售代理合同范本 1 命名规则 https://www.wendangku.net/doc/b519029715.html,命名规则 一致的命名模式是托管类库中可预知性与可发现性最重要的元素之一。对这些命名指南广泛的使用和理解将消除许多最常见的用户问题。本主题提供.NET Framework 类型的命名指南。对于每个类型，还应该注意关于大写样式、区分大小写和措词的一些通用规则。 1.1.1大写样式 描述用于在类库中命名标识符的Pascal 大小写、Camel 大小写和全部大写样式。 使用下面的三种大写标识符约定。 Pascal 大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。可以对三字符或更多字符的标识符使用Pascal 大小写。例如： B ack C olor Camel 大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如： b ack C olor 大写 标识符中的所有字母都大写。仅对于由两个或者更少字母组成的标识符使用该约定。例如： System.IO System.Web.UI 可能还必须大写标识符以维持与现有非托管符号方案的兼容性，在该方案中所有大写字母经常用于枚举和常数值。一般情况下，在使用它们的程序集之外这些字符应当是不可见的。 下表汇总了大写规则，并提供了不同类型的标识符的示例。 标识符大小写示例 类Pascal AppDomain 枚举类型Pascal ErrorLevel 枚举值Pascal FatalError 事件Pascal ValueChange 异常类Pascal WebException 注意总是以Exception后缀结尾。 只读的静态字段Pascal RedValue 接口Pascal IDisposable 注意总是以I 前缀开始。 方法Pascal ToString 命名空间Pascal System.Drawing 参数Camel typeName 属性Pascal BackColor
java程序代码书写风格及一些简单的注意事项
1. 风格务必保持一贯性(Consistent) 一位同胞顶着我的鼻子问，为什么我们的Java代码缩进格式非得是这样，而不能是他那样，他就是喜欢他自己的这一种，因此他写的代码总是用他自己习惯的风格。结果在Code Review里被大家毙掉，责令修改。因此他是大大地不服。就是风格一贯性问题。其实他的风格，本来也没有什么问题，但在项目里，和其他程序员的程序的风格，显得扃异，那就存在问题了。比如这个缩进，又比如变量命名方法，不同的类，不同的Methods里，各自不同，这程序就很难看了。所以一旦你选择了某种风格，一定要贯彻始终。如果一个项目里规定了一个风格，即便很不符合你自己的习惯，也要贯彻始终，绝不应该有标新立异。 2. 缩进风格(indent) 既然是从缩进说起，就先说说缩进风格;一般来说，象Java这样的类C 语言，都采用缩进风格。而常用的，有四种 A.K&R风格 这是C程序最早的缩进风格，由C的发明者Ritchie和他的合作者Kernighan率先使用： if (
其特点，是大括号和if判断在同一行。通常，缩进为8个空格或一个tab键，但在C++和Java里，也常缩进4个空格。有人喜欢用两个空格，窃以为不好，不明显。 B. BSD风格 又称Allman Style，源自Unix BSD程序员Eric Allman--他为BSD 写过很多程序： if (
程序代码注释编写规范
百度文库- 让每个人平等地提升自我 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() */ 意:与溢出中断写初值不同}
代码编写安全规范
代码编写安全规范 一、本总则提供编码的总体要求与遵循原则。 二、本总则制订是为了规范程序的编码风格，使项目开发过程中所有开发人员的编码有一个良好的、规范的、统一的编码风格，确保在开发成员或开发团队之间的工作可以顺利交接，同时不必花费大力气便能理解已编写的代码，以便继续维护和改进以前的工作。 三、本总则对所有技术开发部编码人有效。 四、本总则对所有开发语言有效，凡任何开发规范与本总则相冲突，以本总则为准。 五、本总则提供各种语言的编码规范，编码人员开发（编码）前应选取相应的语言编码规范进行编码。具体的“开发语言编码规范”请参见附件。 六、若总则附件中无所规范的开发语言规范，请先制订出（一般由项目经理制订）该语言的编码规范后再进行编码。 七、编码命名准则： 1、使用可以准确说明变量/字段/类的完整的英文描述符。例如，采用类似firstName，grandTotal 或CorporateCustomer 这样的名字。禁止使用一些象x1，y1 或fn 这样的名字很简短，输入起来容易，辨别含义困难的命名，使得代码难以理解、维护和改进。 2、采用领域的术语命名。如果用户称他们的“客户”(clients) 为“顾客”(customers)，那么就采用术语Customer 来命名这个类，而不用Client。保证命名使用行业或领域里已经存在着很完美的术语，避免生造词汇。
3、采用大小写混合，提高名字的可读性。一般应该采用小写字母，但类名、接口名以及任何非初始单词的第一个字母要大写，一些特殊场合以具体规范为准。 4、尽量少用缩写，但如果一定要使用，必须使用一个统一遵守的缩写，并且在使用时保持一致。例如，如果要对单词“number”采用缩写，那么可从nbr，no 或者num 中选取一个，采用其中一个（具体是哪个倒无所谓），并且只使用这一种形式。 5、避免使用长名字（最好不超过20 个字母）。避免类似如PhysicalOrVirtualProductOrService 之类的超长命名。 6、避免使用相似或者仅在大小写上有区别的名字。例如，不应同时使用变量名persistentObject 和persistentObjects，以及anSqlDatabase 和anSQLDatabase。 7、避免使用下划线作为名字的首末字母。以下划线为首末字母的名字通常为系统保留，除预处理定义之外，一般不用作用户命名。 八、编码注释准则： 1、必须明确注释的重要性。如果你的程序不值得注释，那么它也不值得运行。 2、注释应该增加代码的清晰度。代码注释的目的是要使代码更易于被同时参与程序设计的开发人员以及其他后继开发人员理解。如果不能被他人所理解，则代码的注释是失败的注释，等同于无注释。 3、避免使用装饰性内容，不要使用象广告横幅那样的注释语句。
代码规范
目录 一．规范简介 1.1 目的 所有的程序开发手册都包含了各种规则。一些习惯自由程序人员可能对这些规则很不适应，但是在多个开发人员共同写作的情况下，这些规则是必需的。这不仅仅是为了开发效率来考虑，而且也是为了后期维护考虑。 本规范正是为培养规范设计和编程，养成良好的习惯，增强软件产品的稳定，健壮，可靠性；同时也为了提高软件的可读性，可以让程序员尽快而彻底地理解新的代码，使产品可维护性提高而制定的规范。 1.2 开发规范的重要性 （1）减少维护成本； 一个软件的生命周期中，80%的花费在于维护，另一方面，几乎没有任何一个软件，在其整个生命周期中，均由最初的开发人员来维护，规范的编码减少人员变动带来的维护成本。 （2）改善软件的可读性 可以让程序员尽快而彻底地理解新的代码。在一个团队中，代码也容易在程序员之间共享。 （3）维护部门交付产品的规范形象。 二．具体规范 2.1 注释 注释是软件可读性的具体表现。程序注释量一般占程序编码量的20%，软件工程要求不少于20%。程序注释不能用抽象的语言，要精确表达出程序的处理说明。避免每行程序都使用注释，可以在一段程序的前面加一段注释，具有明确的处理逻辑。 注释必不可少，但也不应过多，不要被动得为写注释而写注释。
2.1.1 需要注释的部分 （1）文件头注释，文件创建及修改记录，版权归属，作者以及修订者，以及对文件的简短描述。 （2）类的目的（即类所完成的功能）、设置接口的目的以及应如何被使用。 （3）成员方法注释（对于设置与获取成员方法，在成员变量已有说明的情况下，可以不加注释；普通成员方法要求说明完成功能，参数含义以及返回值）。 （4）普通成员方法内部注释（控制结构、代码所起到的作用以及如此编写代码的原因，处理顺序等）。 （4）参数的含义以及其他任何约束或前提条件、字段或属性描述。而对于局部变量，如无特别意义的情况下则不加注释。 2.1.2 具体注释 （1）文件头注释 要求：遵循JavaDoc的规范，在每一个源文件的开头注明该文件的作用, 作简要说明, 并写上源文件的作者,版权信息编写日期。如果是修改别人编写的源文件，要在修改信息上注明修改者和修改日期。 例子： /** * @Title: 文件名 * @Copyright (C) 年份龙图软件 * @Description: 文件信息描述 * @Revision History: * @Revision 版本号日期作者. */ （2）类和接口的注释 要求：遵循JavaDoc的规范，在每一个类的开头注明该类的作用，作简要说明，并写上作者，编写日期。 例子： /** * @ClassName: 类（或接口）名 * @Description: Description of this class
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#版） 拟制:日期：2007-2-13审核:日期： 审核:日期： 批准:日期： 版权所有 ********有限公司
修订纪录
目录 注：Pascal命名法则：即名称中所有单词的第一个字母大写其他字母使用
小写形式。 Camel命名法则：即名称中第一个单词各个字母全部小写，其他部分遵循Pascal命名法则。 1、第一章命名规范 1.1、第一节总则 1．本命名规则除特殊提及外统一使用Camel命名法则。 如：controlMenu 2．命名时尽量不使用拼音，更不可使用拼音缩写（专有名词除外）。 3．如果使用品牌名称命名时其大小写尽量保持和品牌名称一致的样式。 如：LuX则命名时，不要写成LUX，或者Lux，而应该保持与原品牌名称风格一致使用LuX 4．使用专有名词或英文缩写命名时采用大写形式。 如：CNNIC 5．禁止使用仅区分大小写的方式命名。 如：Abc与abc仅用大写A来区分，这样写在类C系语言中不会出错，但是不利于系统的迁移
、第二节变量命名规范 1.2.1、CodeBehind内部命名规范 1．公有字段/属性使用Pascal 命名规则，私有变量/保护变量/局部变量使用Camel命名规则，遵循动宾结构。 例： public class Hello { private string userName; private DateTime loginTime; private bool isOnline; public string UserName { get { return ; } } } 2．即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用意义描述性的名称。仅对于短循环索引使用单字母变量名，如 i 或 j 3．在变量名中使用互补对，如 Min/Max、Begin/End 和 Open/Close。 4．当一个方法内部变量繁多的时候，可以使用Camel命名法则，其中第一个单词可以使用变量类型的缩写来说明以示区别。 例：
安全代码编写规范
安全代码编写规范 一、编写目的 为加强武汉楚烟信息技术有限公司在软件开发中的安全规范要求，减少应用上线后带来潜在的安全风险，特拟定安全代码编写规范。二、使用范围 本规范适用于武汉楚烟信息技术有限公司承建的各类开发类的软件类项目。 三、应用安全设计 在总体架构设计阶段，需明确与客户方沟通确认甲方对于软件安全的相关要求，对于有明确安全要求的（例如授权管理要求、用户认证要求、日志审计要求等），须在设计文档中予以详细说明。对于互联网应用，务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上，应采用表现层、服务层、持久层分类的架构，实现对底层业务逻辑进行有效隔离，避免将底层实现细节暴露给最终用户。 在部署架构上，应采用应用服务器、数据库服务器的分离部署模式，在应用服务器被攻击时，不会导致核心应用数据的丢失。如软件产品具备有条件时，应优先采用加密数据传输方式（例如https协议）。 在外部接口设计方面，应采用最小接口暴露的原则，避免开发不必要的服务方法带来相关安全隐患，同时对于第三方接口，应共同商定第三方接入的身份认证方式和手段。
四、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证，除常见的数据格式、数据长度外，还需要对特殊的危险字符进行处理。特殊字符包括<> " ' % ( ) & + \ \' \"等 对于核心业务功能，除在客户端或浏览器进行数据验证外，还必须在服务器端对数据进行合法性检验，规避用户跳过客户端校验，直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据，需要进行验证核实，确认重定向地址是否在可信，并且需要对换行符（\r或\n）进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容，应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交，需对 嵌套的节点应该缩进; 在属性上使用双引号（字符串拼接除外）; 属性名全小写，用“-”做分隔符; 自动闭合标签处不能使用斜线。
FORTRAN 90 程序编程规范
FORTRAN 90 程序编程规范 Fortran 90 编程规范，使程序代码高度组织化，更加易读、易懂、易于维护，程序更加高效。使编出的程序更易懂、易于维护。 1 语言选择 数值预报创新系统软件开发应避免使用Fortran77 的某些过时特征以Fortran 90不一致的特征。选择Fortran 90 作为开发语言，并采用Fortran 90 的新功能，如动态内存的分配(dynamic memory allocation)、递归（recursion ）, 模块(modules)、POINTER 、长变量名、自由格式等。 Fortran 77其中某些只是一些冗余的功能，这些功能已经过时，另外，还有一些在Fortran90 中被证明是不好的用法，建议不要使用。 2 Fortran 90 的新特性 2.1.1 建议使用的Fortran 90 新特性 建议使用Fortran 90 提供的模块（module ），并用Use ONLY 指定module 中哪些变量或派生类型定义可用于调用程序。 尽量使用数组下标三元组，这样可优化并减少所需的代码行数。为提高可读性，要在括号内表明数组的维数，例如： 1dArrayA(:) = 1dArrayB(:) + 1dArrayC(:) 2dArray(: , :) = scalar * Another2dArray(: , :) 当访问数组的子集时，例如在有限差分等式中，可以通过使用下标三元组实现。例如：2dArray(: , 2:len2) = scalar *（ & Another2dArray(:, 1:len2 -1) & - Another2dArray(:, 2:len2) & ) 对程序单元（program units ）命名，并使用End program ，End subroutine ，End interface ，End module 等结构再次指定“program unit ”的名称。 在逻辑表达式中使用>、 >=、 ==、 <、 <=、 /=，它们分别代 替.gt.、.ge.、.eq.、.lt.、.le.、.ne. 。新的表示方法更接近标准的数学符号 在变量定义中始终使用“：：”；始终用“DIMENSION ”定义数组形状；始终用（len=）的语法格式声明字符变量的长度。
代码编写规范说明书
代码编写规范说明书（c#.net与https://www.wendangku.net/doc/b519029715.html,）目录 1 目的 2 范围 3 注释规范 3.1 概述 3.2 自建代码文件注释 3.3 模块（类）注释 3.4 类属性注释 3.5 方法注释 3.6 代码间注释 4 命名总体规则 5 命名规范 5.1 变量（Variable）命名 5.2 常量命名 5.3 类（Class）命名 5.4 接口（Interface）命名 5.5 方法（Method）命名 5.6 名称空间Namespace）命名 6 编码规则 6.1 错误检查规则 6.2 大括号规则 6.3 缩进规则 6.4 小括号规则 6.5 If Then Else规则 6.6 比较规则 6.7 Case规则 6.8 对齐规则 6.9 单语句规则 6.10 单一功能规则 6.11 简单功能规则 6.12 明确条件规则 6.13 选用FALSE规则 6.14 独立赋值规则 6.15 定义常量规则 6.16 模块化规则 6.17 交流规则 7 编程准则 7.1 变量使用 7.2 数据库操作 7.3 对象使用 7.4 模块设计原则 7.5 结构化要求 7.6 函数返回值原则 8 代码包规范 8.1 代码包的版本号
8.2 代码包的标识 9 代码的控制 9.1 代码库/目录的建立 9.2 代码归档 10 输入控制校验规则 10.1 登陆控制 10.2 数据录入控制 附件1：数据类型缩写表 附件2：服务器控件名缩写表 1 目的 一.为了统一公司软件开发设计过程的编程规范 二.使网站开发人员能很方便的理解每个目录,变量，控件，类，方法的意义 三.为了保证编写出的程序都符合相同的规范，保证一致性、统一性而建立的程序编码规范。 四.编码规范和约定必须能明显改善代码可读性，并有助于代码管理、分类范围适用于企业所有基于.NET平台的软件开发工作 2 范围 本规范适用于开发组全体人员，作用于软件项目开发的代码编写阶段和后期维护阶段。 3 注释规范 3.1 概述 a) 注释要求英文及英文的标点符号。 b) 注释中，应标明对象的完整的名称及其用途，但应避免对代码过于详细的描述。 c) 每行注释的最大长度为100个字符。 d) 将注释与注释分隔符用一个空格分开。 e) 不允许给注释加外框。 f) 编码的同时书写注释。 g) 重要变量必须有注释。 h) 变量注释和变量在同一行，所有注释必须对齐，与变量分开至少四个“空格”键。 如：int m_iLevel,m_iCount; // m_iLevel ....tree level // m_iCount ....count of tree items string m_strSql; //SQL i) 典型算法必须有注释。 j) 在循环和逻辑分支地方的上行必须就近书写注释。 k) 程序段或语句的注释在程序段或语句的上一行 l) 在代码交付之前，必须删掉临时的或无关的注释。 m) 为便于阅读代码，每行代码的长度应少于100个字符。 3.2 自建代码文件注释 对于自己创建的代码文件（如函数、脚本），在文件开头，一般编写如下注释： /****************************************************** FileName: Copyright (c) 2004-xxxx *********公司技术开发部 Writer: create Date: Rewriter:
良好的代码编写风格(二十五条)
[VHDL+Verilog]良好的代码编写风格（二十五条） 良好代码编写风格可以满足信、达、雅的要求。在满足功能和性能目标的前提下，增强代码的可读性、可移植性，首要的工作是在项目开发之前为整个设计团队建立一个命名约定和缩略语清单，以文档的形式记录下来，并要求每位设计人员在代码编写过程中都要严格遵守。良好代码编写风格的通则概括如下：（1）对所有的信号名、变量名和端口名都用小写，这样做是为了和业界的习惯保持一致；对常量名和用户定义的类型用大写； （2）使用有意义的信号名、端口名、函数名和参数名； （3）信号名长度不要太长； （4）对于时钟信号使用clk 作为信号名，如果设计中存在多个时钟，使用clk 作为时钟信号的前缀；（5）对来自同一驱动源的信号在不同的子模块中采用相同的名字，这要求在芯片总体设计时就定义好顶层子模块间连线的名字，端口和连接端口的信号尽可能采用相同的名字； （6）对于低电平有效的信号，应该以一个下划线跟一个小写字母b 或n 表示。注意在同一个设计中要使用同一个小写字母表示低电平有效； （7）对于复位信号使用rst 作为信号名，如果复位信号是低电平有效，建议使用rst_n； （8）当描述多比特总线时，使用一致的定义顺序，对于verilog 建议采用bus_signal[x:0]的表示； （9）尽量遵循业界已经习惯的一些约定。如*_r 表示寄存器输出，*_a 表示异步信号，*_pn 表示多周期路径第n 个周期使用的信号，*_nxt 表示锁存前的信号，*_z 表示三态信号等； （10）在源文件、批处理文件的开始应该包含一个文件头、文件头一般包含的内容如下例所示：文件名，作者，模块的实现功能概述和关键特性描述，文件创建和修改的记录，包括修改时间，修改的内容等；（11）使用适当的注释来解释所有的always 进程、函数、端口定义、信号含义、变量含义或信号组、变量组的意义等。注释应该放在它所注释的代码附近，要求简明扼要，只要足够说明设计意图即可，避免过于复杂； （12）每一行语句独立成行。尽管VHDL 和Verilog 都允许一行可以写多个语句，当时每个语句独立成行可以增加可读性和可维护性。同时保持每行小于或等于72 个字符，这样做都是为了提高代码得可读性；（13）建议采用缩进提高续行和嵌套语句得可读性。缩进一般采用两个空格，如西安交通大学SOC 设计中心2 如果空格太多则在深层嵌套时限制行长。同时缩进避免使用TAB 键，这样可以避免不同机器TAB 键得设置不同限制代码得可移植能力； （14）在RTL 源码的设计中任何元素包括端口、信号、变量、函数、任务、模块等的命名都不能取V erilog 和VHDL 语言的关键字； （15）在进行模块的端口申明时，每行只申明一个端口，并建议采用以下顺序： 输入信号的clk、rst、enables other control signals、data and address signals。然后再申明输出信号的clk、rst、enalbes other control signals、data signals； （16）在例化模块时，使用名字相关的显式映射而不要采用位置相关的映射，这样可以提高代码的可读性和方便debug 连线错误； （17）如果同一段代码需要重复多次，尽可能使用函数，如果有可能，可以将函数通用化，以使得它可以复用。注意，内部函数的定义一般要添加注释，这样可以提高代码的可读性； （18）尽可能使用循环语句和寄存器组来提高源代码的可读性，这样可以有效地减少代码行数； （19）对一些重要的always 语句块定义一个有意义的标号，这样有助于调试。注意标号名不要与信号名、