編程規則
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、注釋的寫法等等。
每個項目中，在實現具體代碼之前進行的程序總體設計，規定了介面的形式、功能與功能之間的調用規則、數據交換形式與規則、各個功能部分的負責人員等等。
這兩種理解與軟體模塊化都不沖突。再怎麼模塊化也得寫成代碼，所以第一種理解的編程規范依然是必要的。模塊化就是將功能包裝起來方便調用和重復使用，模塊怎麼被使用、和程序其他部分怎麼交互等等問題都是在第二種理解的編程規范里進行說明了。所以，不明白你為什麼認為有了模塊化，編程規范就沒必要了？或者你對編程規范有其他的理解和解釋？