编程规则
A. 为建立良好的编程风格应遵循什么原则
一、程序内部文档应具备的规则
1、标识符应含有含义鲜明的文字。
含义鲜明的文字，能正确地提示程序对象所代表的实体。这对于帮助阅读者理解程序是非常重要的。如果用缩写的形式，那么缩写规则应该一致，并且应该给每个名字加注解。在VB中，主要有如下的约定：
（一）对象命名约定
应该使用一致的前缀来命名对象，使人们容易识别对象的类型。例如我们常用控件CommandButton(命令按钮)可用cmd做为其前缀。Form以frm,Image以 img ,Label以 lbl,List Box 以lst,PictureBox以 pic,Timer以 tmr，等等，在我们编程的过程中，我们看到下面的名称cmdExit我们就知道这一定是一个命令按钮了。如果是第三方提供的控件，我们的说明最好要清晰地标出制造商的名称，以区别于我们的常用控件。
（二）常量和变量命名约定
除了控件以外，常量和变量也是我们编程过程中经常遇到的，我们和他们打交道也是通过名字。
（1）给变量加范围前缀
变量按其作用范围可分做三类，过程级，模块级和全局，所以我们在编程的过程中应将三者加以区别。我们在使用变量时，为了更好地体现代码重用和可维护原则，其定义范围应尽量缩小，这样将使我们的应用程序更加容易理解和易于控制。在VB应用程序中，只有当没有其他方便途径在窗体间共享数据时才使用全局变量。当使用全局变量时，在一个单一模块中声明它们，并按功能分组，给模块取一个有意义的名字。较好的编码习惯是尽可能地定模块化的代码。除了全局变量，过程和函数应该仅对传递给它们的的对象操作。在过程中使用的全局变量应该在过程起始处的声明部分标识出来。变量的作用范围前缀如下：全局 g(global) ,模块级 m(model)，本地过程不需要使用。例如：gintFlag,表示全局整型变量，mstrPassword,可表示模块级字符型变量。
（2）声明所有变量原则。声明所有变量将会节省编程时间，键入错误将大大减少，我们可在程序开始写上如下语句：
Option Explicit
该语句要求在程序中声明所有变量。
（3）变量数据类型声明。可通过下面的前缀来做为变量的数据类标志。
Boolean bln
Byte byt
Double dbl
Integer int
String str
（4）常量。常量的命名，可遵循与变量命名大体相同的原则。
（5）对变量和过程名作出描述。变量或过程名的主体应该使用大小写混合的形式，并且应该足够长以描述它的作用。而且，函数名应以一个动词开头。如JudgeDialog。
2、适当的注解
注解是程序员和程序读者通信的重要手段，正确的注解非常有助于对程序的理解。VB中代码注解约定如下：所有的过程和函数都应该以描述这段过程的功能的一段简明的注释开始，说明该程序是干什么的，至于是如何做的，也就是编程的细节，最好不要包括。因为可能日后我们要修改程序，这样做会带来不必要的注释维护工作，如果不修改，将提供误导信息，可能成为错误的注释。因为代码本身和后面程序中的注释将起到相应的说明作用。
过程中的注释块应该包括如下标题：
小节描述内容
目的该过程完成什么
假设列出每个外部变量、控件、打开文件或其他不明显元素
效果列出每个被影响的外部变量、控件或文件及其作用（只有当它不明显时）
输入每一个可能不明显的参数。
返回函数返回值的说明
格式化代码
（1）标准的，基于制表位的嵌套应该包括一个嵌注释，来描述该变量的使用。
（2）变量、控件及过程的命名应该足够清楚，使得只有复杂的执行细节才需要嵌入注释。
（3）.bas 模块包含包含工程的VB一般常量声明，在其起始处，应包括程序的综述，列举主要数据对象，过程、算法、对话、数据库及系统需求。
3、程序的视觉组织
程序的视觉组织可用阶梯式，结构化的程序风格对于我们实际编程也很有意义，可极大地改善代码的可读性。主要有代码注释和一致性缩进。
---------------------------------------------------------------------------------------------------------
二、数据说明
数据结构的组织和复杂程序是在设计期间就已经确定了的，然而数据说明的风格却是在写程序时确定的。为了使数据更容易理解和维护，有一些比较简单的原则应该遵循。
1、数据说明的次序应该标准化。有次序就容易查阅。因此能够加速测试、调试和维护的过程。当多个变量名在一个语句中说明时，应按字母顺序排列这些变量。
2、数据结构复杂时，应加以说明其特点和实现方法。
---------------------------------------------------------------------------------------------------------
三、语句构造
语句构造原则:每个语句应该简单而直接，不能为了提高效率而使程序变得过分复杂。下述规则的使用有助于语句简单明了。
1、不要为了节省空间把多行语句写在一行；
2、尽量避免复杂的条件测试；
3、尽量减少对“非”条件的测试；
4、避免大量使用循环嵌套和条件嵌套；
5、利用括号使逻辑表达式或算术表达式的运算次序清晰直观。
---------------------------------------------------------------------------------------------------------
四、输入输出
1、对所有输入数据都进行检验；
2、检查输入项重要组合的合法性；
3、保持输入格式简单；
4、使用数据结束标志，不要要求用户指定输入数据的数目
5、明确提示交互式输入的请求，详细说明可用的选择或边界数值；
6、当语言对格式有严格要求时，应保持输入格式一致
7、设计良好的输出报表；
8、给所有输出加标志；
---------------------------------------------------------------------------------------------------------
五、效率
效率三原则：
1、效率是性能的要求，需求分析时就应确定；
2、效率是靠设计提高的；
3、程序的效率和程序的简单程序是一致的。
（一）运行时间
（1）写程序前先简化算术和逻辑表达式；
（2）他细研究嵌套的循环，以确定是否有语句从内层移到外层；
（3）尽量避免使用多维数组；
（4）尽量避免使用指针和复杂的表；
（5）使用执行时间短的算术运算；
（6）不要混合使用不同的数据类型；
（7）尽量使用整数运算和布尔表达式
（二）存储器效率
（三）输入输出效率
如果用户是为了给计算机提供输入信息或为了理解计算机输入的信息，所需花费的脑力劳动是经济的，那么，人和计算机之间的通信效率就高。简单清晰是关键。
---------------------------------------------------------------------------------------------------------
六、小结
其实风格是非常重要的，程序的外表是我们交流中不可缺少的东西。象我们常说的红颜命薄而归疚于外表太靓，也常听一些才子佳人的悲剧故事，提醒我们外表美而引出的一见钟情的浪漫不可取。可让人细想，才子佳人产生悲剧虽多，可也让人找到过心动和美好的感觉，做为一个人，活了一辈子，连那种感觉都未体验到，岂不比悲剧更加令人觉得可悲！编程亦然。
B. CATIA规则编程问题
在知识工程模块中点击rule命令，新建一个规则，变成如下：
if B<A
B=A+10mm;
else
;
变成时A或B直接在catia中选择即可。
C. 有谁知道C语言程序的编程规范，给我概括一下，
1引言
1.1编写目的
在软件开发过程中，编码的工作量是相当大的，同一项目参与编程的人可能有各自编程的经验和习惯，不同风格的程序代码使维护工作变得复杂和困难。为了提高代码的可读性、系统的稳定性及降低维护和升级的成本，特编写本规范以统一各开发人员的编程工作。
1.2 适用对象
本规范适用于所有开发人员，包括应用程序、网页及数据库开发人员，及有关的程序测试人员。
1.3 引用标准
GB/T 11457 软件工程术语
GB 8566 计算机软件开发规范
GB 8567 计算机软件产品开发文件编制指南
2．编写要求
2.1一般代码规则
可读性原则，这是评价程序质量的首选指标，宁可不要一些技巧也要保证程序的易读特性，不要因过分追求技巧而牺牲程序的可读性。
功能独立性原则。每一程序块只完成一个独立的功能，反过来，每一独立的功能只在一程序块内完成，尽量低耦合、高内聚。
提示说明应当简短且避免产生歧义。
提示或警告信息应当具有向导性，能准确告诉用户错误原因及恢复方法。提示和警告对话框应当使用标准规范。
快捷键的定义必须符合用户操作习惯。
程序需要长时间处理或等待时，应当显示进度条并提示用户等待。
一些敏感操作，如删除等操作在执行前必须提示用户确认。
2.2变量、函数、过程、控件等命名规则
2.2.1 变量命名
变量命名采用[作用范围][数据类型][自定义名称]规则定义，并遵循匈牙利命名法。要求看到变量名就能直观的看出其范围和数据类型。
匈牙利命名规则：
a Array 数组
b BOOL (int) 布尔(整数)
by Unsigned Char (Byte) 无符号字符(字节)
c Char 字符(字节)
cb Count of bytes 字节数
cr Color reference value 颜色(参考)值
cx Count of x (Short) x的集合(短整数)
dw DWORD (unsigned long) 双字(无符号长整数)
f Flags (usually multiple bit values) 标志(一般是有多位的数值)
fn Function 函数
g_ global 全局的
h Handle 句柄
i Integer 整数
l Long 长整数
lp Long pointer 长指针
m_ Data member of a class 一个类的数据成员
n Short int 短整数
p Pointer 指针
s String 字符串
sz Zero terminated String 以0结尾的字符串
tm Text metric 文本规则
u Unsigned int 无符号整数
ul Unsigned long (ULONG) 无符号长整数
w WORD (unsigned short) 无符号短整数
x,y x, y coordinates (short) 坐标值/短整数
v void 空
作用范围：
范围 前缀 例子
全局作用域 g_ g_Servers
成员变量 m_ m_pDoc
局部作用域 无 strName
数据类型
VC常用前缀列表
前缀 类型 描述 例子
ch char 8位字符 chGrade
ch TCHAR 16位UNICODE类型字符 chName
b BOOL 布尔变量 bEnabled
n int 整型（其大小由操作系统决定） nLength
n UINT 无符号整型（其大小由操作系统决定） nLength
w WORD 16位无符号整型 wPos
l LONG 32位有符号整型 lOffset
dw DWORD 32位无符号整型 dwRange
p * 内存模块指针，指针变量 pDoc
l p FAR* 长指针 lpDoc
lpsz LPSTR 32位字符串指针 lpszName
lpsz LPCSTR 32位常量字符串指针 lpszName
lpsz LPCTSTR 32位UNICODE类型常量指针 lpszName
h handle Windows对象句柄 hWnd
lpfn (*fn)() 回调函数指针 Callback Far pointer to
CALLBACK function lpfnAbort
2.2.2 函数、过程命名
函数或过程名的主体应该使用大小写混合形式，并且应该足够长以描述它的作用。而且，函数名应该以一个动词起首，如 InitNameArray 或 CloseDialog。对于频繁使用的或长的项，推荐使用标准缩略语以使名称的长度合理化。一般来说，超过 32 个字符的变量名在 VGA 显示器上读起来就困难了。当使用缩略语时，要确保它们在整个应用程序中的一致性。在一个工程中，如果一会儿使用 Cnt， 一会儿使用 Count，将导致不必要的混淆。
对于自行编写的函数，若是系统关键函数，则须在函数实现部分的上方标明该函数的信息，格式如下：
//======================================================
// 函 数 名：InsureHasOutputInfo
// 功能描述：确保有适当的输出信息
// 输入参数：nProctID:相应的产品ID
// 输出参数：void
// 创建日期：00-2-21
// 修改日期：00-2-21
// 作 者：***
// 附加说明：
//======================================================
2.2.3 用户定义类型
在一项有许多用户定义类型的大工程中，常常有必要给每种类型一个它自己的三个字符的前缀。如果这些前缀是以 "u" 开始的，那么当用一个用户定义类型来工作时，快速识别这些类型是很容易的。例如，ucli 可以被用来作为一个用户定义的客户类型变量的前缀。
注：对于非通用的变量，请在定义时加以注释说明，变量定义尽可能放在最开始处。
2.2.4 控件命名
应该用一致的前缀来命名对象，使人们容易识别对象的类型。
VC常用宏定义命名列表
前缀 符号类型 符号例子 范围
IDR_ 标识多个资源共享的类型 IDR_MAINFRAME 1~0x6FFF
IDD_ 对话框资源（Dialog） IDD_SPELL_CHECK 1~ 0x6FFF
HIDD_ 基于对话框的上下文帮助 HIDD_SPELL_CHECK 0x20001~0x26FF
IDB_ 位图资源（Bitmap） IDB_COMPANY_LOGO 1~0x6FFF
IDC_ 光标资源（Cursor） IDC_PENCIL 1~0x6FFF
IDI_ 图标资源（Icon） IDI_NOTEPAD 1~0x6FFF
ID_、IDM_ 工具栏或菜单栏的命令项 ID_TOOLS_SPELLING 0x8000~0xDFFF
HID_ 命令上下文帮助 HID_TOOLS_SPELLING 0x18000~0x1DFFF
IDP_ 消息框提示文字资源 IDP_INVALID_PARTNO 8~0xDFFF
HIDP_ 消息框上下文帮助 HIDP_INVALID_PARTNO 0x30008~0x3DFFF
IDS_ 字符串资源（String） IDS_COPYRIGHT 1~0x7FFF
IDC_ 对话框内的控制资源 IDC_RECALC 8~0xDFFF
2.3源代码规则
2.3.1风格约定：采用缩进的格式保存程序的层次结构。要求能直观的看出循环、判断等层次结构。
每一个嵌套的函数块，使用一个TAB缩进（可以设定为4个空格），大括号必须放在条件语句的下一行，单独成一行，便于匹对反大括号应该在单独的一行，在大多数情况下反扩号应有注释内容。举例如下：
if(condition1)
{
while(condition2)
{
…..
…..
}//end while(condition2)
}//end if (condition1)
或者
if(condition1){
while(condition2){
….
….
}//end while(condition2)
}//end if(conditionl)
2.3.2在操作符的前后必须使用空格。
2.3.3在分隔数组下标和函数参数的逗号后面必须添上空格。
2.3.4严禁使用go to 语句。
2.3.5对数据库操作只能使用标准SQL语句，关键字必须使用大写（如SELECT、WHERE等），数据元素（表、字段、视图等）必须按照数据字典书写。
2.3.6程序代码中要有足够的容错处理功能。
对可能发生的异常统一采用C++抛出格式：
try
{
//可能引发异常的代码
throw t; //手工抛出异常
}
catch(type_1 e) // type_1为类型定义符、如int、CException、_com_error
{
// type_1类型异常处理
}
catch(type_2 e)
{
// type_2类型异常处理
}
2.3.7程序代码结构必须层次清楚，适当使用空行分段。
2.3.8工程的版本控制要严格，版本格式为.me.ae.yy.mmdd，其中：[me]表示主版本号；[ae]表示辅版本号；[yy.mmdd]表示版本建立日期。高版本尽量兼容低版本的用法、数据或协议。
2．4文件的命名规则
2.4.1根据系统设计所规定的结构，建立相应的文件夹，根据需要建立子文件夹。
2.4.2文件夹和文件的名称应尽量能够表达其意义，尽量使用英文命名，绝对不能汉字。
2.4.3文件名称一般采用“xxx_yyy.ext”格式，xxx(3-4个字母)表示分类，yyy(字母数自定)表示操作 (如 “ /example/exp_edit.htm ”)
\
我从公司文档拷贝的！你自己看看对你有没有用！
D. TCL编程的语法规则
TCL的语法规则：
1、解释器
在Tcl的数据结构中的核心是Tcl_Interp.一个解释器包含了一套命令，一组变量和一些用于描述状态的东西。每一个 Tcl命令是 在特定的Tcl_Interp中运行的，基于Tcl的应用程序可以同时拥有几个Tcl_Interp。Tcl_Interp是一个轻量级的结构，可以快速的新建和删除。
2、数据类型
Tcl只支持一种数据结构：字符串（string）。所有的命令，命令的所有的参数，命令的结果，所有的变量都是字符串。请牢记这一点，所有的东西都是字符串。这是它比较有特点的方面字符串有三种形式：命令(command),表达式(expresion)和表(list)。
3、Basic Command Syntax 基本语法
Tcl有类似于shell和lisp的语法，当然也有许多的不同。一 条Tcl的命令串包含了一条或多条命令用换行符或分号来隔开，而每一条命令包含了一个域(field)的集合，域使用空白分开的，第一个域是一个命令的名字，其它的是作为参数来传给它。
例如：
set a 22 //相当于C中的 a=22 a是一个变量这条命令分为三个域：1：set 2：a 3：22 set使用于设置变量的值的命令，a、20 作为参数来传给它，a使它要操作的变量名，22是要付给的a值。
Tcl的命令名可以是内置的命令也可以是用户建的新命令，如果是用户用户建的新命令应用程序中用函数Tcl_CreateCommand来创建。所有的参数作为字符串来传递，命令自己会按其所需来解释的参数的。命令的名字必须被打全，但 Tcl解释器找不到一同名的命令时会用 unknown命令来代替。
在很多场合下，unknown 会在库目录中搜寻，找到一个的话，会自动生成一个Tcl命令并调用它。unknown经常完成缩略的命令名的执行。但最好不要使用。
4、注释
和shell很象，第一个字母是"#"的Tcl字符串是注释。
其他细节规则
Grouping arguments with double-quotes 用双引号来集群参数，目的在于使用有空白的参数。
例如：
set a "this string contains whitespace"
如果一个参数一双引号来开始，该参数会一直到下一个双引号才结束。其中可以有换行符和分号。
Variable substitution with $ 用美元符进行变量替换说白了就是引用该变量。
例如：
set a hello
set b $a // b = "hello" 实际上传给set命令的参数
//是b,"hello"
set c a // b = "a"
Command substitution with brackets 命令子替换（用方括号）
例如：
set a [set b "hello"]
实现执行 set b "hello" 并用其结果来替换源命令 中的方括号部分，产生一条新命令
set a "hello" //"hello" 为 set b "hello" 的返回值
最终的结果是b="hello" a="hello"
当命令的一个子域以方括号开始以方括号结束，表示要进行一个命令子替换。并执行该子命令，用其结果来替换原命令中的方括号部分。方括号中的部分都被视为Tcl命令。
如下一个复杂一点的例子：
set a xyz[set b "abc"].[set c "def"]
//return xyzabcdef
Backslash substitution 转移符替换
转移符时间不可打印字符或由它数意义的字符插入进来。这一概念与C语言中的一样。
Backspace (0x8).
f Form feed (0xc).
Newline (0xa).
Carriage-return (0xd).
Tab (0x9).
v Vertical tab (0xb).
{ Left brace (`{").
} Right brace (`}").
[ Open bracket (`[").
] Close bracket (`]").
$ Dollar sign (`$").
sp Space (` "): does not terminate argument.
; Semicolon: does not terminate command.
" Double-quote.
Grouping arguments with braces 用花扩括号来集群参数
用花扩括号来集群参数与用双引号来集群参数的区别在于：用花扩括号来集群参数其中的三种上述的子替换不被执行。而且可以嵌套。
例如：
set a {xyz a {b c d}}//set收到两个参数 a "xyz a {b c d}"
eval {
set a 22
set b 33
}//eval收到一个参数 "set a 22
set b 33"
5、命令综述
1．一个命令就是一个字符串（string）。
2．命令是用换行符或分号来分隔的。
3．一个命令由许多的域组成。第一个于是命令名，其它的域作为参数来传递。
4．域通常是有空白（Tab横向制表健 Space空格）来分开的。
5．双引号可以使一个参数包括换行符或分号。三种子替换仍然发生。
6．花括号类似于双引号，只是不进行三总体换。
7．系统只进行一层子替换，机制替换的结果不会再去做子替换。而且子替换可以在任何一个域进行。
8．如果第一个非控字符是`#",这一行的所有东西都是注释。
6、表达式
对字符串的一种解释是表达式。几个命令将其参数按表达式处理，如：expr、for 和 if,并调用Tcl表达式处理器(Tcl_ExprLong,Tcl_ExprBoolean等)来处理它们。其中的运算符与C语言的很相似。
!
逻辑非
* / % + -
< >>
左移 右移 只能用于整数。
> = == !=
逻辑比较
& ^ |
位运算和 异或 或
&&''
逻辑"和" "或"
x y : z
If-then-else 与C的一样
Tcl 中的逻辑真为1，逻辑假为0。
一些例子：
5．/ 4.0
5．/ ( [string length "abcd"] + 0.0 )
计算字符串的长度 转化为浮点数来计算
"0x03" > "2"
"0y" < "0x12"
都返回 1
set a 1
expr $a+2
expr 1+2
都返回 3
E. 当前的软件开发逐渐模块化，智能化，在程序设计中，制定编程规范还有必要么谈谈看法和理由。
为什么把软件开发模块化之后，编程规范就没必要了呢？
编程规范有两种理解：
俗称代码书写规则，英文为coding standards 或者 programming guidelines，就是规定程序书写形式，方便阅读，比如缩进为4个字符、每行最多80字符、操作符和等于号前后有空格、一行一条语句、带返回值的函数方法最好只有一个return、注释的写法等等。
每个项目中，在实现具体代码之前进行的程序总体设计，规定了接口的形式、功能与功能之间的调用规则、数据交换形式与规则、各个功能部分的负责人员等等。
这两种理解与软件模块化都不冲突。再怎么模块化也得写成代码，所以第一种理解的编程规范依然是必要的。模块化就是将功能包装起来方便调用和重复使用，模块怎么被使用、和程序其他部分怎么交互等等问题都是在第二种理解的编程规范里进行说明了。所以，不明白你为什么认为有了模块化，编程规范就没必要了？或者你对编程规范有其他的理解和解释？