C# 编码规范
南方软件精英实验室
二零一三年十月
目录
1目标 (4)
2概述 (4)
3总体要求 (4)
3.1程序结构化 (4)
3.2代码可读性 (4)
3.3代码结构化 (4)
3.4正确性与容错性 (5)
4编码规范 (5)
4.1文件结构 (5)
4.1.1C# 文件 (5)
4.1.2目录结构 (5)
4.2缩进 (5)
4.2.1换行 (5)
4.2.2空格 (6)
4.3注释 (6)
4.3.1模块注释 (6)
4.3.2单行注释 (7)
4.3.3类注释 (7)
4.3.4方法注释 (7)
4.4声明 (7)
4.4.1单行声明变量数 (7)
4.4.2初始化 (8)
4.4.3类和接口声明 (8)
4.5功能语句 (9)
4.5.1简单逻辑 (9)
4.5.2if-else语句 (9)
4.5.3For / Foreach 语句 (9)
4.5.4While/do-while 语句 (9)
4.5.5Switch 语句 (10)
4.5.6Try-catch 语句 (10)
4.6空白 (11)
4.6.1空白行 (11)
4.6.2参数条件之间的空白 (11)
4.6.3表格式的样式 (12)
4.7命名规范 (12)
4.7.1大写 (12)
4.7.1.1Pascal 风格 (12)
4.7.1.2驼峰规则 (12)
4.7.1.3大写风格 (12)
4.7.2命名方法 (12)
4.7.2.1类命名 (13)
4.7.2.2接口命名 (13)
4.7.2.3枚举命名 (13)
4.7.2.4常量命名 (13)
4.7.2.5参数命名 (13)
4.7.2.6变量命名 (13)
4.7.2.7方法命名 (13)
4.7.2.8属性命名 (14)
4.7.2.9事件命名 (14)
4.7.2.10大写风格 (14)
4.8开发习惯 (14)
4.8.1可见性 (14)
4.8.2不要硬编码数字 (15)
4.9代码示例 (15)
4.9.1作用域（“{}”）示例 (15)
5附录 (16)
5.1XML注释标记的使用 (16)
6版本记录 (19)
1目标
为新宇DotNet组的C#程序员制定一个统一的编码规范，最大限度减少不同程序员开发的代码间的差异。
2概述
为了使应用程序的结构和编码风格标准化，便于阅读和理解编码，以提高开发效率和产品的标准化，制订一套开发规范和标准势在必行。此外，好的编码约定可使源代码严谨、可读性强且意义清楚，与其它语言约定相一致，并且尽可能的直观。希望开发人员严格遵守此套开发规范和标准，并落实到自己的程序中。
本规范主要针对C#程序员，但是其中许多规则同时适用于其他语言的程序员。
3总体要求
3.1程序结构化
?程序结构清晰，函数功能简单易懂（单个函数的代码行数不超过100行）
3.2代码可读性
?保持注释与代码完全一致
?每个源程序文件，都有文件头说明，详细见下节
?每个函数，都有函数头说明，详细见下节
?主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义
?处理过程的每个阶段都有相关注释说明
?在典型算法前都有注释, 同时算法在满足要求的情况下尽可能简单
?利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为 4个字节
?循环、分支层次一般不应超过五层
?代码简单的分支应该写在前面
?不允许同行出现两个语句
?空行和空白字符也是一种特殊注释
?一目了然的语句不加注释
?注释的作用范围可以为：定义、引用、条件分支以及一段代码
?常量定义（DEFINE）有相应说明
3.3代码结构化
?禁止GOTO语句
?用 CASE 实现多路分支
?避免不必要的分支
?用 IF 语句来强调只执行两组语句中的一组。尽量不使用 ELSE RETURN
?尽量避免从循环引出多个出口
3.4正确性与容错性
?所有变量在调用前必须被初始化
?不要比较浮点数的相等，如： 10.0 * 0.1 == 1.0 ，不可靠
?访问外部资源(数据库，外部文件)时使用规范的容错语句
例如:
try
{
}
catch
{
}
finally
{
}
4编码规范
4.1文件结构
4.1.1C# 文件
尽量不要让你的类或者文件太长,一般不应超过2000行代码。请按照功能划分你的代码，使结构保持清晰。一般情况下，一个文件应当只有一个类，并且文件名应该与类名保持一致。
4.1.2目录结构
应该为每个名称空间(namespace)建立一个目录(例如，我们可以为名称空间MyProject.TestSuite.TestTier建立这样的目录：MyProject/TestSuite/TestTier)。这样做可以让你很快定位到指定名称空间下的类文件。
4.2缩进
4.2.1换行
如果表达式太长而一行无法写下时，请按照下列规范进行换行：
●可以在逗号后面进行换行
●可以在操作符号后进行换行
●尽量选择在较高层处进行换行
●换行后的新行应当与前一行中同级别的运算符对齐
例子：
方法调用换行：
longMethodCall(expr1, expr2,
expr3, expr4, expr5);
算术表达式换行：
规范的:
var = a * b / (c - g + f) +
4 * z;
不规范的:
var = a * b / (c - g +
f) + 4 * z;
上面第一个表达式的换行方式是符合规范的，它换行在括号外面（较高
层）。另外请注意，换行后的新行应使用tab和空格保持与前一行的同级运算符对齐，例如:
> var = a * b / (c - g + f) +
> ......4 * z;
'>'表示Tab符， '.'表示空格。你可以设置你的编辑环境，使Tab和空格在编辑时是可见的，这是一个不错的习惯。
4.2.2空格
我们选择Tab缩进作为缩进时采用的标准。
[请不要使用空格代替Tab键!]
4.3注释
4.3.1模块注释
在一个程序模块的开始，应用注释说明模块的名字、功能、开发者和日期和版本变更历史，如下所示：
/******************************************************************
* Copyright(c) Suzsoft DotNet Group
* Description : Tenant access class
* CreateDate : 2006-06-02 05:03:46
* Creater : Johnson Cao
* LastChangeDate:
* LastChanger :
* Version Info : 1.0
* ******************************************************************/
4.3.2单行注释
程序员应当在算法比较复杂的表达式前、特殊含义的变量前或者在一整段功能代码开始之前添加适当的注释。我们要求这样的单行注释采用”//”符号，例如：
// Calculate subTotal
Decimal subTotal = 0;
4.3.3类注释
在定义一个类之前，应用“///”注释说明类的功能、使用方法和特殊的属性，如下所示：
///
/// This class...
///
/// Please note …
///
///
详细的xml注释标记的使用请参见附录。
4.3.4方法注释
在定义类成员方法前，应说明该过程/函数的名字、功能、输入/输出和版本变更历史，如下所示：
///
/// This method ….
///this is a param of the method SomeMethod.
///
///
//-------------------------------------------------------------------------------------------------
// Change History:
// Date Who Changes Made
// 2000-5-1 Author1 Initial creation
// 2000-5-15 Author2 Add some code
//-------------------------------------------------------------------------------------------------
public object SomeMethod(object param1)
{
}
4.4声明
4.4.1单行声明变量数
我们推荐每行只声明一个变量，因为这样你可以在声明后面写上该变量的注释，例如：
int level; // indentation level
int size; // size of table
请不要在同一行声明不同含义的变量，比如：
int a, b; //What is 'a'? What does 'b' stand for?
上面的例子同样可以说明了没有意义的变量名称会让人很难理解，因此，在定义变量的时候，我们一定要给它们一个有含义的名字。
4.4.2初始化
最好在一定义后就初始化变量，例如：
string name = https://www.doczj.com/doc/4718740781.html,;
or
int val = time.Hours;
注意：如果你想要初始化对话框变量，建议使用using 声明方式
例如：
using (OpenFileDialog openFileDialog = new OpenFileDialog())
{
...
}
4.4.3类和接口声明
在声明类和接口的时候应当遵照下列规范：
●方法名称和放置参数的括号”(”之间不应该有空格
●类名声明之后应另起一行写作用域开始符”{”
●作用域结束符”}”应当单独占一行，并与对应的开始符”{”处在同一缩进位置
上
示例：
Class MySample : MyClass, IMyInterface
{
int myInt;
public MySample(int myInt)
{
this.myInt = myInt ;
}
void Inc()
{
++myInt;
}
void EmptyMethod()
{
}
}
4.5功能语句
4.5.1简单逻辑
每一行代码应当只实现一个逻辑
4.5.2if-else语句
if-else应该按照这种格式书写：
if(condition)
{
DoSomething();
...
}
else
{
DoSomethingOther();
...
}
4.5.3For / Foreach 语句
For循环语句格式：
for(int i = 0; i < 5; ++i)
{
...
}
或者，如果循环只有一个简单执行语句的话：
for (initialization; condition; update) ;
foreach循环格式:
foreach(int i in IntList)
{
...
}
注意：即使循环中只有一句执行语句，我们也要求使用”{}”
4.5.4While/do-while 语句
While循环格式：
while (condition)
{
...
}
对于空循环可以这样写：while (condition) ; do-while循环格式：
do
{
...
}while(condition);
4.5.5Switch 语句
switch格式：
switch (condition)
{
case A:
...
break;
case B:
...
break;
default:
...
break;
}
4.5.6Try-catch 语句
try-catch格式：
try
{
...
}
catch (Exception) {} 或者：
try
{
...
}
catch (Exception e)
{
...
}
或者：
try
{
...
}
catch (Exception e)
{
...
}
finally
{
...
}
4.6空白
4.6.1空白行
空白行有增强可读性的作用。它们隔离了逻辑上相互独立的模块。
●在下列情况中我们还可以使用双空白行：
?源文件中的两个独立的逻辑片断之间
?类和接口之间（但一般情况下我们还是建议一个文件一个类或接口）
●下列情况中我们可以使用单空白行：
?方法之间
?属性之间
?方法内局部变量第一出声明前
?方法内相对独立的逻辑之间
注意，尽量保持空白行和其他行具有同样的缩进，可以使今后插入代码能够保持相同的缩进。
4.6.2参数条件之间的空白
通过这些空白，可以使代码更容易被阅读，例如：
TestMethod(a, b, c);
而不应该这样：TestMethod(a,b,c)
但是也不应有过多的空格，比如：
TestMethod( a, b, c );
操作符和变量或数字之间应该有空格：
a = b; // don't use a=b;
for (int i = 0; i < 10; ++i)
// don't use for (int i=0; i<10; ++i)
// or
// for(int i=0;i<10;++i)
4.6.3表格式的样式
连续的多行付值语句可以这样子写：
string strName = "Mr. Ed";
int nValue = 5;
Test aTest = Test.TestYou;
利用空格对齐所有的“=”，使代码块看起来像表格一样。
4.7命名规范
4.7.1大写
4.7.1.1Pascal 风格
变量的首字母大写，如：Name
4.7.1.2驼峰规则
除了首个单词，每个单词的首字母大写，如：TestName
4.7.1.3大写风格
只在少于两个字母的缩写中使用大写。三个以上字母的缩写都应该使用PASCAL 风格。
4.7.2命名方法
通常我们采用匈牙利命名法来为变量命名。
匈牙利命名法通常采用变量类型的缩写作为前缀，变量含义的全拼作为后缀的方法来命名变量。这种命名方法被广泛的采用在windows程序开发中，它因由一匈牙利程序员创立而得名。
注意：好的变量命名不是突出其类型，而是突出其含义。
对于UI控件，我们强制要求缩写前缀，例如：
System.Windows.Forms.Button btnCancel;
System.Windows.Forms.TextBox txtName;
4.7.2.1类命名
●使用名词或名词短语命名类。
●使用Pascal风格.
●谨慎使用缩写命名类。.
●不要使用任何类前缀（如C）.
4.7.2.2接口命名
●使用名词或名词短语命名接口.(例如 IComponent 或 IEnumberable)
●使用Pascal风格
●使用大写的I作为首字母，表示为接口
4.7.2.3枚举命名
●使用Pascal风格
●不使用前缀
●使用单数名词命名
4.7.2.4常量命名
●采用有意义的单词命名
●使用全部大写字母拼写
4.7.2.5参数命名
●相对变量而言，参数更注重本身的含义作为命名
●使用驼峰规则命名
4.7.2.6变量命名
●作为循环中的运算子的变量，更适合采用简单的命名，如i, j, k, l, m, n
4.7.2.7方法命名
●采用动词命名，或者动词词组
●使用Pascal风格
4.7.2.8属性命名
●使用名词或名词短语命名属性
●使用Pascal风格
4.7.2.9事件命名
●使用EventHandler作为事件句柄的后缀
●使用两个参数：sender 和e
●使用Pascal风格
●使用EventArgs 作为Event Argument类型名的后缀
●使用进行时动词和过去式动词作为事件的名称
4.7.2.10大写风格
Type Case Notes
Class / Struct Pascal Casing
Interface Pascal Casing Starts with I
Enum values Pascal Casing
Enum type Pascal Casing
Events Pascal Casing
Exception class Pascal Casing End with Exception
public Fields Pascal Casing
Methods Pascal Casing
Namespace Pascal Casing
Property Pascal Casing
Protected/private Fields Camel Casing
Parameters Camel Casing
4.8开发习惯
4.8.1可见性
请避免将类变量或一个实例声明为公共类型的变量，而应该将其声明为私有变量。
如果你确实需要公开一个类变量或者实例的话，可以使990用属性(Property)来公开它。
4.8.2不要硬编码数字
也就是说，在你的逻辑代码中，不要采用数字直接参与计算，尤其是那些可能需要改变的数字。你应该将它付值给一个常量，使用该常量参与计算。这样做得好处是，如果这个数字改变的时候，你不必在代码中将他找出并修改，而只需修改常量的值。
public class MyMath
{
public const double PI = 3.14159...
}
4.9代码示例
4.9.1作用域（“{}”）示例
namespace ShowMeTheBracket
{
public enum Test
{
TestMe,
TestYou
}
public class TestMeClass
{
Test test;
public Test Test
{
get
{
return test;
}
set
{
test = value;
}
}
void DoSomething()
{
if (test == Test.TestMe)
{
//...stuff gets done
}
else
{
//...other stuff gets done
}
}
}
}
作用域（"{}”）应该在下列代码后另起一行开始：
●Namespace声明后
●Class/ Interface / Struct 的声明后
●Method声明后
●循环或者判断(if…else…)后
5附录
5.1XML注释标记的使用
5.1.1Section 标记
Section 标记用于定义不同的代码文档的区域。它们都是顶级标记，Block 标记、Inline 标记都应包含在某个 Section 标记的内部。（除非自定义了扩展 XSLT 转换，否则，在Section 标记外部的 Block 标记或 Inline 标记都被忽略。）
标记说明
[NDoc 扩充]
对某个成员可能引发的事件的说明。
为“重载列表”页面准备摘要、备注、示例等文档内容。只需在重载成员的第一个成员前面书写此区域即可。
?简单的形式，直接在 overload 中写文本，这些文本被处理为“重载列表”页面的摘要。没有备注、示例等区域。
?复杂的形式，在 overload 内部，包含 summary, remarks, example 等标记分别表示“重载列表”页面的摘要、备注、示例等。
标记说明
示例:
///
///
public void SayHello() { ... }
///
public void SayHello(string toSomeone) { ... }
成员的参数说明。
将某类型/成员标记为“预发布”。内部的文本被当作警告文本用红色显示，可以包含
如果需要把全部类型/成员都标记为“预发布”，请使用文档引擎的Preliminary 配置项。
请不要将此标记包含在
两种可选的语法:
? href="https://www.doczj.com/doc/4718740781.html,/china/msdn/">MSDN(CHS) ealso> ? NDoc 提供static和instance两个布尔的属性，可以自动生成像 .NET Framework SDK 类库文档中那样的标准文本。 threadsafety 标记内部可以包含额外的文本，会被显示到标准文本的下方，说明额外的信息。例如: /// SafeClass. /// /// /// public class SafeClass() { ... } 5.1.2Block 标记 Block 标记用于 Section 标记的内部，它们将显示在单独的行中。 标记说明 “注意”块。 例如: /// /// public class SomeClass() { ... } 将生成: 注意 This is a note in the summary. 5.1.3Inline 标记 Inline 标记可以用于其他 Section 标记或 Block 标记内部，它们将和前后的文本显示 在同一行中。 标记说明 两种可选的语法: ? href="https://www.doczj.com/doc/4718740781.html,/china/msdn/">MSDN(CHS) ? ? 其中xxx可以是null, sealed, static, abstract或virtual。 6版本记录 文件修改控制 版本作者日期修改说明 1.00 Bill 2013.10.10 初建版本 阅读与确认记录 文件状态确认日期确认人 阅读日期阅读人阅读意见和建议处理人处理结果 数据库设计和编码规范 Version 目录 简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。 6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如： 软件配置项标识编码规则设计方案 刘宏 2011-9-18 Mail:lh@https://www.doczj.com/doc/4718740781.html, 1.背景 1.1.服务外包中迁移 在服务外包中，难度较大的阶段为——服务外包的迁移工程。 服务迁移工程难度大的主要原因之一，是没有实施迁移前准备标准和迁移后的验收标准。也就是在服务成熟到何种程度——包括管理与技术成熟度，服务才能够向外包方进行迁移，以便发包方有效控制服务外包中的风险，达到服务外包的目的。 服务外包迁移前应达到的准备标准——包括管理标准与技术标准，技术标准是管理标准的基础。技术标准是在服务外包迁移中的必要条件，管理标准是服务外包迁移中的充分条件。 不同服务业务在外包迁移中，具有不同的技术标准，但是具有相同的管理标准——ISO20000规定了管理相关的内容。 因为不同的服务业务具有不同的服务技术标准要求，因此正对IT服务外包业务应根据业务的特点编制相关的技术标准要求。IT服务外包业务可以包括： ●IT系统基础平台维护服务外包 ●IT系统支撑环境维护服务外包 ●应用系统的维护服务外包 1.2.服务外包迁移标准内容 每类服务有可以分成：运营服务（一线服务）、支持性服务（二线服务）、变更性服务（三线服务）。 在IT服务外包中风险较大的是运营服务，因为运营服务一直是直接在客户的生产环境实施，一旦发生错误，有可能给客户造成无法挽回的损失。目前一般风险较大的运营服务，有客户自己承担，不进行外包。 支持性服务也是在客户生产环境实施，但是一般需要进行策划与实施结果测试。由于支 持服务具有一定的技术性，因此这种服务外包迁移前应按照技术标准要求通过验收。只有通过技术标准验收的服务才能够实施服务外包的迁移。 变更性服务是在其他环境中测试完成后，在反映到生产环境中。因此变更性服务与系统建设期的系统开发存在不同的风险。在系统建设期，可以进行充分的测试与试运行测试。在变更性服务由于工期与成本的原因，可能不能充分进行测试与试运行。 1.3.服务外包迁移中标准需求 服务外包方为了及时提供服务需要将分包方的技术成果迁移到外包方处，因此分包方向服务外包方进行服务迁移时，在服务迁移时，迁移哪些内容，迁移的内容在迁移前应到技术标准要求应进行验证与确认。若是没有达到服务外包迁移技术标准，很显然是增加服务外包迁移的风险。 在服务外包迁移实施中，需要对服务外包迁移内容结果进行验证，因此需要服务外包迁移结果验证与确认的技术标准要求。 1.4.应用软件服务迁移标准需求分析 在应用软件系统维护服务外包的迁移中，技术标准主要是针对分包方迁移给外包方的所有技术成果物。对这些成果物需要相关的技术标准要求，以便在服务外包迁移过程，分包方与外包方能够有效沟通与交接，确保服务能够连续，不因为服务外包迁移发生中断或服务水平下降。 为了确保分包方与外包方能够有效进行技术沟通，首先需要明确出工程成果物的标识标准——配置项标识编码标准。这一标准能够是双方能够正确地在配置管理库中找到所需要的配置项。 为了能够有效避免交付过程中，使用错误的成果物。就需要双方共同承认的成果物的编码规则或标准。 由此得出结论：软件配置项标识编码规则，是IT应用系统维护服务外包的技术标准中的基础。 2.方案的目的与目标 2.1.目的 通过提供一般软件配置项编码规则，为企业的软件配置项的管理提供自动化处理的解决 ASTM标准的编号方法及其标准资料类型 ASTM标准编号形式为： 标准代号+字母分类代码+标准序号+制定年份+标准英文名称。 示例： 说明： 1. 标准序号后带字母M的为米制单位标准，不带字母M的为英制单位标准。 2. 制定年限后面括号内的年代为标准重新审定的年代。 3. a.b.c......表示修订版次。 4. 字母分类代码为： A ——黑色金属 B ——有色金属（铜，铝，粉末冶金材料，导线等） C ——水泥，陶瓷，混凝土与砖石材料 D ——其它各种材料（石油产品，燃料，低强塑料等） E ——杂类（金属化学分析，耐火试验，无损试验，统计方法等） F ——特殊用途材料（电子材料，防震材料，外科用材料等） G ——材料的腐蚀，变质与降级 ASTM标准的资料类型： Technical Specification (技术规范) Guidance (指南) Test Method (试验方法) Classification (分类法) Standard Practice (标准惯例) Terminology (术语) Definition (定义) 还包括：Test Report (试验报告)及试验方法可使用性 美国钢铁产品牌号表示方法 美国钢铁产品的标准比较多，主要有以下几种： ANSI美国国家标准 AISI 美国钢铁学会标准 ASTM美国材料与试验协会标准 ASME美国机械工程师协会标准 AMS航天材料规格（美国航空工业最常用的一种材料规格，由SAE制定）API美国石油学会标准 AWS美国焊接协会标准 SAE美国机动车工程师协会标准 MIL美国军用标准 QQ美国联邦政府标准 【最新整理，下载后即可编辑】 1程序结构 所有源代码的结构均采用以下顺序布局，对于没有的部分可以省略，便于阅读代码。 //============================================== ================================================ #region Constant #endregion Constant //---------------------------------------------------------------------------------------------- #region Members #endregion Members //---------------------------------------------------------------------------------------------- #region Defaults #endregion Defaults //---------------------------------------------------------------------------------------------- #region Properties #endregion Properties //============================================== ================================================ #region Constructors #endregion Constructors //---------------------------------------------------------------------------------------------- #region InterfaceMethods #endregion InterfaceMethods //---------------------------------------------------------------------------------------------- #region StaticMethods #endregion StaticMethods //---------------------------------------------------------------------------------------------- #region OverrideMethods #endregion OverrideMethods //---------------------------------------------------------------------------------------------- #region PrivateMethods #endregion PrivateMethods //---------------------------------------------------------------------------------------------- #region ProtectedMethods #endregion ProtectedMethods //---------------------------------------------------------------------------------------------- #region PublicMethods #endregion PublicMethods //============================================== ================================================ #region Events #endregion Events //============================================== ================================================ 2命名规则和风格 ⑴类、方法、常量采用Pascal风格命名 public class SomeClass { const int DefaultSize = 100; 华泰汽车集团技术规范 YF-GF-A0—001 标 准 件 编 号 技 术 规 范 2010-07-01发布 2010-07-01实施 华泰汽车集团研发中心发布 标准件编号技术规范 1、概述 根据公司各项目实际运行情况，为规范所有项目产品零部件编号，为今后产品的设计、制造、生产、采购、销售等提供规范性基础文件，特制定本规范。 2、参考标准 QCT326-1999 汽车标准件产品编号规则 3、标准件编号规则 3.1 标准件和准标准件 3.1.1 标准件：标准编号及标准名称完全符合国家或行业标准的标准件称为标准件。 标准件的编号中不能表达性能等级的信息时，标准件性能等级在备注中注明。例：Q150B0680 8.8级。如标准件代号中已表达了性能等级、表面处理信息的，在备注栏不必再注明。 3.1.2 准标准件：可以用标准件进行表达的非标件称准标准件，准标准件编号为：在标准编号尾增加更改标识。但准标准件只限于： a）螺纹螺距规格的更改（P） 一个标准的螺母或螺栓没有所需的螺距： 例：Q1841025 六角法兰面螺栓标准规格为M10×1.5如设计需要M10×1.25的，表示方法如下：准标准件编号：Q1841025P1.25。 b）螺纹长度规格的更改（b） 标准件螺纹长度的变化： 如一个标准件Q1841280，其中螺杆的长度为80，螺纹长度为30。根据设计要求，螺纹长度要50，表示方法如下：准标准件编号：Q184128050b其中：b是螺纹的长度。标准名称不变。 c）螺栓长度规格的更改（L） 选用的标准螺栓没有需要的长度： 例：如果一个选用的标准螺栓，长度系列最长为60，而实际需要的长度为80，表示方法如下：准标准件编号：Q150B0680L；标准名称不变。 d）平垫圈规格的更改 组合标准件更改平垫圈规格： 例：Q1460820 六角头螺栓、弹簧垫圈和平垫圈组合件。其中垫圈为Q407是标准垫圈，因需要改为Q402大垫圈，表示方法如下： 准标准件编号：Q1460820Q402；标准名称不变。 e）标准件组合 几个单个标准件组合成一个组合件： 准标准中的组合件均不可拆分，各种垫圈和弹簧垫圈的内径应随主件变更，外径等其它参数按取选垫圈的规格确定。 例：一个标准六角法兰面螺栓Q1841080和一个标准垫圈Q402组合，表示方法如下： 准标准件编号：Q1841080Q402；准标准件名称：六角发兰面螺栓和平垫圈组合件。 f) 准标准件编号字符超过18位 例：一个标准内六角花形圆柱头螺钉Q2100620、平垫圈Q401和弹簧垫圈Q403三个标准件组合，表示方法如下： 准标准件编号：Q2100620Q401403F32； 项目开发规范文档修订历史记录 1.简介 目的 1、用于规范指导开发组进行开发 2、便于成员间的沟通与交流。 3、有助于项目质量和稳定。 4、为后期维护提供支持 2. 项目开发流程 项目开发过程归纳分为以下步骤： 1. 建立SVN项目版本控制。包括文档，源码，Lib包等。 2. 了解需求，并对需求文档的书写。(见文档结构规则附录)。 3. 详细设计文档。(见文档结构规则附录)。 功能模块设计，重要模块的算法设计。 数据库设计等。 根据需求定义开发平台及环境。 4. 编码。 搭建开发平台，配置开发环境。 编码。 单元测试案例。 5. 书写软件安装手册文件，数据库脚本文件，以及注意事项(release notes)。 6. 交互测试组测试。根据测试组测试结果是否回归第4步（测试回归最好不要超过2 次）。 7. 测试通过，交付上线使用。 维护手册 使用手册 3. 代码规范 Java 代码规范 3.1.1 Java类名 类名可由：英文字母，数字，下划线组成。（数字，下划线不能够开头） 类名由一个或者多个单词组成。单词通常要求简洁明了达意。能够通过类名能够大致了解此类的作用和用途。 类名要求首字母大写，多个单词组成类名时，单词的首字母要求大写。 建议：类名不要过于简单或者太长。可以对单词采用简化的名称：入： Number 简化为：num 。 3.1.2 Java类结构 类仅作为数据结构，没有行为，他封装了一组或者相似的一些行为方法。所以一个类尽量功能单一，或者功能类似共有行为的。一个类不要过于庞大。 通常情况下： 一般逻辑类中应该有构造方法和main方法，main方法中应该有测试代码。 每个类应该有 toString() 方法。 3.1.2.1 包和引入语句 在多数Java源文件中，第一个非注释行是包语句。在它之后可以跟引入语句。 报名的定义全部是小写字母。具体定义依据项目而定。 引入包时候，同一类型的归纳到一块，用空行隔开。例如： import 3.1.2 类注释 Java类开头应该有相应的注释：类版本描述，作者签名，日期时间，公司备注，类的功能作用相关描述等。（详细查看：注释） 3.1.2.2 类成员变量 a) 类变量要求放在类的开始声明。一行声明一个。 b) 变量名称首字母要求小写。其他命名规则类似与类名。 c) static , final 类型的变量，字母要求全部大写。 d) 尽量在声明局部变量的同时初始化。 e) 避免局部变量和成员变量同名，覆盖了成员变量。 f) 尽量变量私有化，缩小变量的作用域。 3.1.2.3 类成员方法 a) 方法名命名规则类似于成员变量命名规则。 b) 成员方法尽量私有化。 质量管理体系过程文件 软件设计编码过程 文件版本信息： 目录 1.目的 设计编码的目的在于设计和实现关于需求的解决方案。保证《需求规格说明书》中的各项要求在设计时都能够得到满足；对项目的编码实现进行质量控制，保证编码实现活动按计划顺利完成并与设计相一致。 2.范围 适用于公司的各类软件项目的系统设计编码过程。 3.术语 无 4.角色与职责 5.入口准则 ●《需求规格说明书》已通过评审。 6.输入 ●《需求规格说明书》 7.流程图 图1: 系统设计编码过程 8.主要活动 系统设计编码过程包括系统设计、系统实现。系统设计是指设计软件系统的体系结构、数据库、模块等，在需求和代码之间建立桥梁，一般分概要设计和详细设计两个阶段；系统实现是指开发人员按照系统设计去编码开发，并进行单元测试、代码走查；在设计编码过程中同时进行用户文档的编制。 8.1.概要设计 概要设计是分析各种设计方案和定义软件体系结构的过程。设计人员在充分了解需求的基础上，依据《需求规格说明书》选用适当的设计方法，分析与设计软件的结构、模块功能。通过系统分解，确定子系统的功能和子系统之间的关系，以及模块的功能和模块之间的关系，编写《概要设计说明书》。《概要设计说明书》必须经过技术评审。 8.1.1.解决方案选择 系统设计时可能会涉及到多种解决方案的选择，如： ●系统实现路线； ●采用的工具和技术； ●产品架构； ●设计模式； ●模块的制作、购买或重用等。 当出现多种候选方案，难以通过简单的方法判断出方案的优劣时，应按照《S_DAR00_决策分析和决定过程》进行决策。 8.1.2.概要设计 概要设计是建立整个软件的体系结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义等。概要设计的主要步骤有： ?选择设计方法； ?识别解决方案的主要组件：根据解决方案的技术架构和分析方法（面向对象、面向结 构），相应确定解决方案的组件模块； ?对候选技术和工具、组件进行评估，确定是进行开发、购买还是复用已有技术（工具 或者组件）。评估开发、购买或复用方案时需要考虑的事项包括：业务方面：可行性、产品成本、经验、投资回报、成熟度及其他因素；企业体系结构方面：解决方案必须 与当前状态和远景状态计划的约束相适应。包括与企业现有系统的集成等；技术方面：安全、组件模块交互标准、数据访问、数据存储、系统服务、开发工具、操作系统等。 ?识别解决方案主要组件的重要属性和关键关系：在前一任务的基础上，对解决方案主 要组件的重要属性和关键关系进行识别； ?进行数据库设计，建立数据库的逻辑模型和物理模型； ?进行用户界面设计，确定整个系统的界面框架以及界面风格； ?形成《概要设计说明书》。 8.1.3.概要设计评审 概要设计的结果应进行技术评审。技术评审由设计人员提出，由项目经理组织召开。技术评审会议应邀请需求分析师、公司的技术专家、开发人员、测试人员等参加。 关于技术评审会议的要求详见《评审过程》。 8.2.详细设计 详细设计可以和概要设计并行进行，但应考虑并行设计不会因概要设计而导致较大的详细设计返工。 8.2.1.详细设计 详细设计是从开发需求的角度描述解决方案的组件、服务和技术的过程。详细设计定义了解决方案的各个组成部分，以及这些组成部分的开发方法和交互方式。详细设计的步骤包括： ?选择用于开发解决方案的技术并完善设计模型：在概要设计的基础上，选择开发解决 方案采用的技术，并且完善对应的设计模型。 一、类名命名规范及使用约定 类名命名规范 根据各种类的类型和用途，采用不同前缀+名词的命名方式。名词采用波浪法，必须使用可以明确表达变量意义的英文名词。 前缀 UE封装类 ?模板类以T 为前缀。 ?继承UObject 的类以U 为前缀。 ?继承AAtor 的类以A 为前缀。 ?继承SWidget 的类以S 为前缀。 ?抽象接口类以I 为前缀。 ?枚举类由E 为前缀 ?布尔变量必须以b 为前缀（比如“bPendingDestruction”，或 “bHasFadedIn”） ?大部分其他类都以F 为前缀, 但某些子系统使用其他字母。 ?Typedef 应该由相应的类型来前缀：F 则说明是struct 的typedef，U 则是UObject 的typedef，以此类推 o对于一个模板的特定化实例来做的typedef 则不再是模板，应该用相应的前缀来定义。比如： typedef TArray 接口类(I) 对于无任何实现的纯虚类，称为接口类，这些类的特点都是无任何成员变量，存在需要其他实现类实现的纯虚函数。 接口类必须采用I+名词的方式命名。 例如： class IDataInput { Public : virtual ~IDataInput() {}; virtual void read() = 0; } 结构体(T) Struct，结构体，必须以T+名词的方式命名。 例如： typedef struct _t_mystruct { Unsigned int number; Unsigned int value; Char name[255]; }TMyStruct,* TMyStructPtr; 模板类 模板类，必须以全小写命名。 例如： template https://www.doczj.com/doc/4718740781.html, C#开发规范 第一部分 第一章ASP编码规范通述 ASP编码分为两大部分，一部分为静态文件编码，一部分为包含服务器端脚本的动态文件编码。 静态文件编码分Script编码和HTML编码两部分。 服务器端编码则分为服务器脚本、客户端脚本、HTML脚本三部分。 编码规范采用如下约定： 所有客户端脚本一律使用JavaScript 所有服务器端脚本一律使用c# 静态页面输出一律使用HTML脚本 本规范不适用于由服务器端脚本所产生的客户端脚本代码。 第二章静态文件编码规范： 静态文件脚本部分采用JavaScript编写。输出部分采用HTML标记语言。 1. HTML标记语言编码规范 1.1 标记的换行规范： * 一个标记必须占用一行。不得出现两个标记在同一行的情况(同一标记的关闭标记除外)，如： 多行的代码块。 一个列表或表格。
数据库设计和编码规范
软件配置项标识编码规则设计方案解读
ASTM标准的编号方法及其标准资料类型
C#编码规范(完整资料).doc
标准件编号技术规范
项目开发及编码规范
软件设计编码规范
编码规范
https://www.doczj.com/doc/4718740781.html,c#开发规范
text text 1.2 标记的关闭规范 * 静态文件内容必须包含在标记中间 * 标记必须包含在标记中间 * 对于需要关闭的标记，如：