|
程序匠人 发表于侃单片机 2001-9-5 23:13:00
程序匠人在论坛上引项高歌：“如果你的‘芯’是一座作坊，我愿作那不知疲倦的程序匠，……”
台下，MM迷倒一片，鲜花、飞吻、西红柿、烂香蕉、臭鸡蛋、西瓜皮、破鞋子、臭袜子、易拉罐、废光盘、编程器、仿真机纷纷飞向论坛……
程序匠人抱头鼠串地逃下……
斑竹忙撑着雨伞上台打圆场：“抱歉！各位大虾，小弟把关不严，让这匠人混入场内。小弟这就赶他出去，明天就吊销他的上网执照……”
……
以上情节纯属虚构，如有雷同，实属巧合。好了，轻松过后，咱们言归正传。
在单片机领域，一直有一个怪现象，就是：每个程序匠写的程序，都只有他自己看得懂。原因何也？盖因每个程序匠写程序时，都按自己的习惯来写，大家没有统一的规范。如此以来，造成诸多弊端：
1.可读性极差。读别人的一个程序，比自己写一个程序的时间还长。
2.可维护性极差。程序越写越长，越改越烂，像懒婆娘的裹脚布，又长又臭又粘。
3.可移植性极差。今天你写程序用的子程序，明天我写程序时，这些子程序又得重写一遍。众多的程序匠在程序的苦海中重复着低级劳动……
4.开发周期长。客户怨声载道，老板的MONEY不禁使唤……
5.……
（台下，众人握紧了烂香蕉和臭鸡蛋……）
（幕后，斑竹悄悄对匠人说：“老兄，拜托你废话少些，台下那帮爷又要砸场子了！”）
（程序匠人回头对斑竹道：“别打叉，头，我这就要切入主题了。”）
在此，小匠特发出倡议：让我们大家共同来制定一份程序编写规范，大家都用这种规范来写程序，并逐步推动其成为一种行业标准。各位以为如何？
（台下掌声雷动！）
（程序匠人抹着满头大汗下到台后，只见……）
（一群MM捧着签名册围追上来……）
（程序匠人再次抱头鼠串地逃走……）
（N（N>500）个西红柿、烂香蕉、臭鸡蛋……砸向程序匠人……）
（救护车的声音……）
（第2天，斑竹发出告示，鉴于程序匠人在论坛上信口嗤黄，决定吊销其上网执照半个小时，以平众怒……）
（新闻：某医院门口，昨夜聚集了100多名妙龄少女，造成交通严重堵塞……）
给程序匠人发送email
有人在吗？ - 上海 / 程序匠人 回复于2001-9-5 23:35:00
小匠吆喝了半天，怎么没人响应？
（远处，飞来一只鸡蛋...）
RE:《程序编写规范倡议书》大话篇 - xyz / 圆圈 回复于2001-9-6 0:01:00
不错，不过我喜欢用C51语言编写软件，所以按照C的规范写程序。。
RE:《程序编写规范倡议书》大话篇 - 江南 / 楚楚 回复于2001-9-6 8:37:00
既要有规范，又要有不遵守现行规范的工程师。全部都按部就班也不行吧。
RE:《程序编写规范倡议书》大话篇 - 济南 / id9527 回复于2001-9-6 12:03:00
程序匠人您好：
当我从繁重和恼人的程序调试中抬起头来，想轻松一下时，看见了你的帖子，在我被你的幽默的语言笑得前俯后仰后，我的劳累顿时飞向了九霄云外。同时也对你的提议很是佩服和欣赏。希望能得到您的联系方式。
我的email id9527◎263。net 手机13688617438
RE:《程序编写规范倡议书》大话篇 - 深圳 / samsong 回复于2001-9-6 12:28:00
程序编写规范,我们公司早就有了
RE:《程序编写规范倡议书》大话篇 - 深圳 / samsong 回复于2001-9-6 12:33:00
程序编写规范,我们公司早就有了
RE:《程序编写规范倡议书》大话篇 - 北京 / 真名张治国 回复于2001-9-6 14:14:00
楼上的兄弟，能让大家参观参观吗？吸取点经验好不好？
RE:《程序编写规范倡议书》大话篇 - 上海 / 程序匠人 回复于2001-9-6 15:47:00
各位大虾：
能否提一些具体的建议，比如程序的开头格式、子程序的开头格式、注释的格式、标号和寄存器的定义规范。关于这些东西，凡是写过程序的人，都会有些心得体会，能否贴些贴子，让大家讨论讨论？
我的邮件地址是：ZJ123@SHTEL.NET.CN
欢迎给我来邮件，交流心得体会，畅谈人生，索取签名、交换个人写真（仅限和MM交换）......
（第2天，程序匠人的邮箱被黑客们用炸弹轰了N（N>50）次......）
RE:《程序编写规范倡议书》大话篇 - shanghai / 插翅能飞 回复于2001-9-7 0:05:00
我觉得是该有一个统一得书写规范。
秦始皇都知道“书同文”得道理。
RE:《程序编写规范倡议书》大话篇 - 北京 / jmliu_27f 回复于2001-9-7 0:20:00
本人在单位就主持此项工作，写了一个完整的编程规范。
愿与同人交流。程序匠人，我会另发电邮与你的。
RE:《程序编写规范倡议书》大话篇 - 珠海 / demoway 回复于2001-9-7 7:38:00
有意思！蛮有道理可惜不能大范围实现！
可惜.......
RE:《程序编写规范倡议书》大话篇 - 南京 / bufj 回复于2001-9-7 11:25:00
人在单位就主持此项工作，写了一个完整的编程规范。
愿与同人交流。程序匠人，我会另发电邮与你的
RE:《程序编写规范倡议书》大话篇 - 北京 / jmliu_27f 回复于2001-9-7 0:20:00
能不能也给我发一份啊?谢谢
RE:《程序编写规范倡议书》大话篇 - 成都 / super_mike 回复于2001-9-7 13:20:00
C语言编程规范(仅供参考，如有异议，欢迎电子邮件与我联系)：
1. 基本要求
1.1 程序结构清析，简单易懂，单个函数的程序行数不得超过100行。
1.2 打算干什么，要简单，直接了当，代码精简，避免垃圾程序。
1.3 尽量使用标准库函数和公共函数。
1.4 不要随意定义全局变量，尽量使用局部变量。
1.5 使用括号以避免二义性。
2.可读性要求
2.1 可读性第一，效率第二。
2.2 保持注释与代码完全一致。
2.3 每个源程序文件，都有文件头说明，说明规格见规范。
2.4 每个函数，都有函数头说明，说明规格见规范。
2.5 主要变量（结构、联合、类或对象）定义或引用时，注释能反映其含义。
2.7 常量定义（DEFINE）有相应说明。
2.8 处理过程的每个阶段都有相关注释说明。
2.9 在典型算法前都有注释。
2.10 利用缩进来显示程序的逻辑结构，缩进量一致并以Tab键为单位，定义Tab为 6个
字节。
2.11 循环、分支层次不要超过五层。
2.12 注释可以与语句在同一行，也可以在上行。
2.13 空行和空白字符也是一种特殊注释。
2.14 一目了然的语句不加注释。
2.15 注释的作用范围可以为：定义、引用、条件分支以及一段代码。
2.16 注释行数（不包括程序头和函数头说明部份）应占总行数的 1/5 到 1/3 。
3. 结构化要求
3.1 禁止出现两条等价的支路。
3.2 禁止GOTO语句。
3.3 用 IF 语句来强调只执行两组语句中的一组。禁止 ELSE GOTO 和 ELSE RETURN。
3.4 用 CASE 实现多路分支。
3.5 避免从循环引出多个出口。
3.6 函数只有一个出口。
3.7 不使用条件赋值语句。
3.8 避免不必要的分支。
3.9 不要轻易用条件分支去替换逻辑表达式。
4. 正确性与容错性要求
4.1 程序首先是正确，其次是优美
4.2 无法证明你的程序没有错误，因此在编写完一段程序后，应先回头检查。
4.3 改一个错误时可能产生新的错误，因此在修改前首先考虑对其它程序的影响。
4.4 所有变量在调用前必须被初始化。
4.5 对所有的用户输入，必须进行合法性检查。
4.6 不要比较浮点数的相等，
如： 10.0 * 0.1 == 1.0 ， 不可靠
4.7 程序与环境或状态发生关系时，必须主动去处理发生的意外事件，如文件能否
逻辑锁定、打印机是否联机等。
4.8 单元测试也是编程的一部份，提交联调测试的程序必须通过单元测试。
5. 可重用性要求
5.1 重复使用的完成相对独立功能的算法或代码应抽象为公共控件或类。
5.2 公共控件或类应考虑OO思想，减少外界联系，考虑独立性或封装性。
5.3 公共控件或类应建立使用模板。
附：C＋＋ 编程规范,delphi作相应的参考
1适用范围
本标准适用于利用Visul C++ ,Borland C++进行软件程序开发的人员.。
.2变量命名
命名必须具有一定的实际意义,形式为xAbcFgh,x由变量类型确定,Abc、Fgh表示连续意
义字符串,如果连续意义字符串仅两个,可都大写.如OK.
具体例程:
BOOL类型 bEnable;
ch * char chText
c * 类对象 cMain（对象实例）
h * Handle（句柄） hWnd
i * int
n * 无符号整型
p * 指针
sz,str * 字符串
w WORD
x,y 坐标
Char或者TCHAR类型 与Windows API有直接联系的用szAppName[10]形式否则用
FileName[10]形式,单个字符也可用小写字母表示;
Int类型 nCmdShow;
LONG类型 lParam;
UINT类型 uNotify;
DWORD类型 dwStart;
PSTR类型 pszTip;
LPSTR类型 lpCmdLine
LPTSTR类型 lpszClassName;
LPVOID类型 lpReserved
WPARAM类型 wParam,
LPARAM类型 lParam
HWND类型 hDlg;
HDC类型 hDC;
HINSTANCE类型 hInstance
HANDLE类型 hInstance,
HICON类型 hIcon;
int iTmp
float fTmp
DWORD dw*
String , AnsiString str *
m_ 类成员变量 m_nVal, m_bFlag
g_ 全局变量 g_nMsg, g_bFlag
局部变量中可采用如下几个通用变量：nTemp，nResult，I，J（一般用于循环变量）。
其他资源句柄同上
.3常量命名和宏定义
常量和宏定义必须具有一定的实际意义;
常量和宏定义在＃i nclude和函数定义之间;
常量和宏定义必须全部以大写字母来撰写,中间可根据意义的连续性用下划线连接,每一
条定义的右侧必须有一简单的注释,说明其作用;
资源名字定义格式:
菜单:IDM_XX或者CM_XX
位图:IDB_XX
对话框:IDD_XX
字符串:IDS_XX
DLGINIT:DIALOG_XX
ICON:IDR_XX
.4函数命名
函数原型说明包括引用外来函数及内部函数，外部引用必须在右侧注明函数来源：模
块名及文件名, 如是内部函数，只要注释其定义文件名;
第一个字母必须使用大写字母,要求用大小写字母组合规范函数命名,必要时可用下划线
间隔,示例如下：
void UpdateDB_Tfgd (TRACK_NAME); file://Module Name :r01/sdw.c
void PrintTrackData (TRACK_NAME); file://Module Name :r04/tern.c
void ImportantPoint (void); file://Module Name :r01/sdw.c
void ShowChar (int , int , chtype); file://Local Module
void ScrollUp_V (int , int); file://Local Module
.5结构体命名
结构体类型命名必须全部用大写字母,原则上前面以下划线开始;结构体变量命名必须用
大小写字母组合，第一个字母必须使用大写字母,必要时可用下划线间隔。对于私有数
据区，必须注明其所属的进程。全局数据定义只需注意其用途。
示例如下：
typedef struct
{
char szProductName[20];
char szAuthor[20];
char szReleaseDate[16];
char szVersion[10];
unsigned long MaxTables;
unsigned long UsedTables;
}DBS_DATABASE;
DBS_DATABASE GdataBase;
6 控件的命名：
用小写前缀表示类别
用小写前缀表示类别：
fm 窗口
cmd 按钮
cob combo，下拉式列表框
txt 文本输入框
lab labal，标签
img image，图象
pic picture
grd Grid，网格
scr 滚动条
lst 列表框
frm fram
7注释
原则上注释要求使用中文;
文件开始注释内容包括:公司名称、版权、作者名称、时间、模块用途、背景介绍等,复
杂的算法需要加上流程说明;
函数注释包括:输入、输出、函数描述、流程处理、全局变量、调用样例等,复杂的函数
需要加上变量用途说明;
程序中注释包括:修改时间和作者、方便理解的注释等;
引用一: 文件开头的注释模板
/******************************************************************
** 文件名:
** Copyright (c) 1998-1999 *********公司技术开发部
** 创建人:
** 日 期:
** 修改人:
** 日 期:
** 描 述:
**
** 版 本:
**--------------------------------------------------------------------------
---
******************************************************************/
引用二: 函数开头的注释模板
/*****************************************************************
** 函数名:
** 输 入: a,b,c
** a---
** b---
** c---
** 输 出: x---
** x 为 1, 表示...
** x 为 0, 表示...
** 功能描述:
** 全局变量:
** 调用模块:
** 作 者:
** 日 期:
** 修 改:
** 日 期:
** 版本
****************************************************************/
引用三: 程序中的注释模板
/*----------------------------------------------------------*/
/* 注释内容 */
/*----------------------------------------------------------*/
8 程序
a. 程序编码力求简洁，结构清晰，避免太多的分支结构及太过于技巧性的程序，
尽量不采用递归模式。
b. 编写程序时，亦必须想好测试的方法，换句话说，”单元测试” 的测试方案应
在程序编写时一并拟好。
c. 注释一定要与程序一致。
d. 版本封存以后的修改一定要将老语句用/* */ 封闭，不能自行删除或修改,并要
在文件及函数的修改记录中加以记录。
e. 程序中每个block 的开头 ”{" 及 "}” 必须对齐，嵌套的block 每进一套，
缩进一个tab，TAB 为4个空格,block类型包括if、for、while、do等关键字引出的。
f. 对于比较大的函数，每个block 和特殊的函数调用，都必须注明其功能，举例如下
：
count.divisor = 1193280 / freq; // compute the proper count
OutByte((unsigned short)67, (unsigned char)182); // tell 8253 that a
count is coming
OutByte((unsigned short)66, count. c[0]); // send low-order byte
OutByte((unsigned short)66, count. c[1]); // send high-order byte
×××××××××××××××××××××××××××××××××××××××
bcb，delphi中的变量命名：
遵循匈牙利命名法，命
名必须有意义，制定如下规定
窗体：以大写的W开始，如About版权窗体， 命名为WAbout
文件：以大写的F开始，如About版权窗体，文件命名为FAbout.cpp
按钮(Button)：如退出按钮，命名为btnExit
……
基类：加base标记，如报表基类,窗体命名为：WBaseRep, 文件命名为FBaseRep.cpp
转贴
> 1. 在.h/.cpp的开头应有一段格式统一的说明，内容包括：
> a. 文件名 (FileName)；
> b. 创建人 (Creater)；
> c. 文件创建时间 (Date)；
> d. 简短说明文件功能、用途 (Comment)。
好习惯
> 2. 除非极其简单，否则对函数应有注释说明。内容包括：功能、入口/出口参数，必
要
> 时还可有备注或补充说明。
还是好习惯
> 3. 每列代码的长度推荐为 80列，最长不得超过120列；折行以对齐为准。
太宽了，我的限制是60列，因为文本方式下屏幕一共80列，如果你用BC这一类的编辑
器，窗口边框等又要占据一定空间，所以80列太宽
> 4. 循环、分支代码，判断条件与执行代码不得在同一行上。
很对
> 5. 指针的定义，* 号既可以紧接类型，也可以在变量名之前。
>
> 例：可写做：int* pnsize;
>
> 也可写做：int *pnsize;
>
> 但不得写做：int * pnsize;
建议采用第二种，除非附加另外一条规定：一次只声明一个变量，否则就会让人混淆，
比如：
int* a, b;
看起来b好像也是个指针，其实不是。
> 6. 在类的成员函数内调用非成员函数时，在非成员函数名前必须加上"::"。
这一条我倒觉得并不是必需的，我的看法是决不要让你的类成员函数和全局函数的名称
相同（或类似）
> 7. 函数入口参数有缺省值时，应注释说明。
>
> 例：BOOL CWpsDib::PaintDIB(CDC* pDC, CRect& rc,
> int nBrightness, file://*=0*//
> BOOL bGrayScale file://*=FALSE*// )
每个变量写一行，必要时加上/*in, out*/注释
> 8. else if 必须写在一行。
应该尽量避免else if这样的结构
> 9. 与‘{’、‘}’有关的各项规定：
>
> 9.1‘{’、‘}’应独占一行。在该行内可有注释。
> 9.2 ‘{’必须另起一行，‘{’ 之后的代码必须缩进一个Tab。‘{’与‘}’必须在
同
> 一列上。
> 9.3 在循环、分支之后若只有一行代码，虽然可省略‘{’、‘}’，但不推荐这么
> 做。若省略后可能引起歧义，则必须加上‘{’、‘}’。
持保留意见，因为GNU的代码规范是这样的：
if ( NULL == ptr )
{
// do something here
}
或者
if ( NULL == ptr ) {
// do something here
}
争论哪个更好并没有意义，关键是统一，如果用VC当然你的办法最方便，可是如果你用
emacs或者vi，就不是这样了。
> 10. 与空格有关的各项规定。
>
> 10.1 在所有两目、三目运算符的两边都必须有空格。在单目运算符两端不必空格。
但
> 在‘—>’、‘::’、‘.’、‘[’、‘]’等运算符前后，及‘&’（取地址）、‘*
> ’（取值）等运算符之后不得有空格。
> 10.2 for、while、if 等关键词之后应有1个空格，再接‘(’，之后无空格；在结
尾
> 的‘)’前不得有空格。
我认为在括号两端加空格并不是什么错误，尤其是在一个条件十分复杂的if语句里
> 10.3 调用函数、宏时，‘(’、‘)’前后不得有空格。
> 10.4 类型强制转换时，‘(’‘)’前后不得有空格
同上
> 11. 与缩进有关的各项规定
>
> 11.1 缩进以 Tab 为单位。1 个 Tab 为 4 个空格
我认为这个值应该更大，我自己使用8个空格，如果你的代码因为缩进幅度太大而导致
折行，那么几乎可以肯定你的程序设计方案有问题。
> 11.2 下列情况，代码缩进一个 Tab:
> 1. 函数体相对函数名及'{'、'}'。
> 2. if、else、for、while、do 等之后的代码。
> 3. 一行之内写不下，折行之后的代码，应在合理的位置进行折行。若有 + - * / 等
运
> 算符，则运算符应在上一行末尾，而不应在下一行的行首。
这一条我反对，运算符应该放在下一行行首，以使人能清楚的知道这一行是续上一行
的，比如
if ( something
&& somethingelse
&& otherthings )
如果写做
if ( something &&
somethingelse &&
otherthings )
反而看不清楚
> 11.3 下列情况，不必缩进：switch 之后的 case、default。
| 
《匠人手记》推荐网上购书渠道： 
社区动态：《匠人手记》义拍活动，得款直接捐献灾区
