代碼編寫管理規(guī)定

本文格式為Word版，下載可任意編輯——代碼編寫管理規(guī)定XXX公司

代碼編寫管理規(guī)定

XXXXX公司

編號(hào)

編制

審核

批準(zhǔn)

發(fā)布日期

修改記錄

序號(hào)文件更改內(nèi)容

修改日期修改人版本1A

V1.0

（A-新增，M-修改，D-刪除）

目錄1.目的42.范圍43.職責(zé)44.術(shù)語45.程序46.相關(guān)文件317.相關(guān)記錄31

11..目的

為確保XXX公司軟件開發(fā)工程代碼編寫過程得到有效管控，以確保代碼的安全性、可讀性、適用性，特制定本規(guī)定。

22..范圍

適用于軟件開發(fā)工程的代碼編寫活動(dòng)。

33..職責(zé)

產(chǎn)品事業(yè)部：負(fù)責(zé)代碼的編寫、評(píng)審。

增值業(yè)務(wù)部：負(fù)責(zé)代碼的編寫、評(píng)審。

44..術(shù)語

編碼：編碼是信息從一種形式或格式轉(zhuǎn)換為另一種形式的過程。

55..程序

5.1.編碼規(guī)范5.1.1頁(yè)面設(shè)計(jì)部分Img控件所有展示類圖片都要具有能簡(jiǎn)要描述圖片內(nèi)容的文字說明。

Input控件maxlength：所有INPUT控件都需要制定maxlength屬性，默認(rèn)值為數(shù)據(jù)庫(kù)中對(duì)應(yīng)的字段的長(zhǎng)度。

readonly：所有不可更改的信息都要使用readonly屬性。

控件的命名將默認(rèn)名稱中的序號(hào)用有意義的名稱代替，如：存儲(chǔ)按鈕默認(rèn)為Button1改為Button_Save

5.1.2客戶端程序部分提醒每次操作都應(yīng)當(dāng)返回提醒。

錯(cuò)誤提醒信息的處理所有錯(cuò)誤提醒信息全部使用中文，標(biāo)點(diǎn)使用中文半角符號(hào)，格式如下：

quot;錯(cuò)誤：quot;+提醒信息+quot;！quot;

成功提醒信息的處理所有成功提醒信息全部使用中文，標(biāo)點(diǎn)使用中文半角符號(hào)，格式如下：

quot;成功：quot;+提醒信息+quot;！quot;

提交前數(shù)據(jù)的驗(yàn)證

1)是否為數(shù)字2)長(zhǎng)度判斷3)為空判斷刪除數(shù)據(jù)前的提醒所有涉及刪除的操作，在用戶選定以后都要再進(jìn)行一次確認(rèn)操作。

5.1.3服務(wù)器端程序部分對(duì)象的關(guān)閉所有數(shù)據(jù)庫(kù)和文件對(duì)象都要在使用后盡可能早的close，同時(shí)賦nothing。

可移植配置管理將可能在部署或升級(jí)時(shí)可能發(fā)生變化的信息進(jìn)行動(dòng)態(tài)設(shè)置處理。例如：數(shù)據(jù)適配器中連接串動(dòng)態(tài)配置。

5.1.4模糊查詢?cè)谖谋究蛑休斎?！表示匹配單個(gè)字符、%表示匹配多個(gè)字符。

5.1.5必輸內(nèi)容標(biāo)示用*標(biāo)示必輸內(nèi)容。

5.2.C#編程規(guī)范5.2.1命名規(guī)范命名總體原則：

將默認(rèn)名稱中的序號(hào)用有意義的名稱代替，如：存儲(chǔ)按鈕默認(rèn)為Button1改為Button_Save。

其他命名原則是：

1）使名稱足夠長(zhǎng)以便有一定的意義，并且足夠短以避免冗長(zhǎng)；2）使用簡(jiǎn)單讓人理解的名稱，避免簡(jiǎn)單被主觀解釋的難懂的名稱；3）盡量減少使用縮寫；4）鑒于大多數(shù)名稱都是通過連接若干單詞構(gòu)造的，請(qǐng)使用大小寫混合的格式以簡(jiǎn)化它們的閱讀。

類以Class聲明的類，都必需以名詞或名詞短語命名，表達(dá)類的作用。如：

ClassIndicator當(dāng)類是一個(gè)特性（Attribute）時(shí)，以Attribute結(jié)尾，當(dāng)類是一個(gè)異常（Exception）時(shí)，以Exception結(jié)尾：

ClassColorSetException

ClassCauseExceptionAttribute當(dāng)類只需有一個(gè)對(duì)象實(shí)例（全局對(duì)象，譬如Application等），必需以Class結(jié)尾，如：

ClassScreenClassClassSystemClass當(dāng)類只用于作為其他類的基類，根據(jù)狀況，以Base結(jié)尾：

MustInheritClassIndicatorBase假如定義的類是一個(gè)窗體，那么名字的后面必需加后綴Form，假如是Web窗體，必需加后綴Page：

ClassPrintForm:InheritsForm"*Windows窗體ClassStartPage:InheritsPage"*Web窗體其他原則：

1)使用Pascal大寫。

2)減少類名中縮寫的使用量。

3)不要使用任何類前綴（譬如C）。

4)不要使用帶下劃線的字符。

下面是一些正確命名的類名的例子。

publicclassFileStream{}

publicclassButton{}

publicclassString{}枚舉和結(jié)構(gòu)同樣必需以名詞或名詞短語命名。最好表達(dá)枚舉或結(jié)構(gòu)的特點(diǎn)，如：

EnumColorButtons"以復(fù)數(shù)結(jié)尾，說明這是一個(gè)枚舉StructureCustomerInfoRecord"以Record結(jié)尾，說明這是一個(gè)結(jié)構(gòu)體委派類型普通的委派類型以描述動(dòng)作的名詞命名，以表達(dá)委派類型實(shí)例的功能：

DelegateStringDataSeeker(StringSeekString)用于事件處理的委派類型，必需以EventHandler結(jié)尾，如：

DelegatevoidDataChangedEventHandler(SenderObject,DataChangedEventArgse)接口與其他類型不同，接口必需要由I作為前綴，并用形容詞命名，突出表現(xiàn)實(shí)現(xiàn)接口的類將具有什么能力，如：InterfaceIsortable。

使用Pascal大寫。

減少接口名中縮寫的使用量。

不要使用帶下劃線的字符。

不要在類名前加上前綴C。偶而狀況下，需要在類名前加上I而并不表示它是一個(gè)接口。在這種狀況下，只要I后面的字符是小寫就可（例如，

IdentityStore。）

當(dāng)類是接口的標(biāo)準(zhǔn)執(zhí)行時(shí)，定義這一對(duì)類/接口組合就要使用相像的名稱。兩個(gè)名稱的不同之處只是接口名前有一個(gè)I前綴。

下面我們舉個(gè)例子，來看看接口IComponent和它的標(biāo)準(zhǔn)執(zhí)行，類Component。

publicinterfaceIComponent{

}

publicclassComponent:IComponent{

}

publicinterfaceIServiceProvider{

}

publicinterfaceIFormatable{

}模塊模塊不是類型，他的名稱除了必需以名詞命名外，必需加以后綴Module，

如：ModuleSharedFunctionsModule。

上述所有規(guī)矩的共同特點(diǎn)是，每個(gè)組成名稱的詞語都必需是大寫開頭，阻止完全大寫或小寫的名稱。

方法無論是函數(shù)還是子程序，方法都必需以動(dòng)詞或動(dòng)詞短語命名。無需區(qū)分函數(shù)和子程序，也無需指明返回類型。

publicvoidSetCopyNumber(IntCopyNumber)參數(shù)需要區(qū)分ref還是out，這一點(diǎn)寫起來會(huì)讓程序變長(zhǎng)，但十分必要。假如沒有特別狀況，都使用默認(rèn)。參數(shù)的命名方法，參考后面變量的命名方法。需要重載的方法，一般不寫Overloads，根據(jù)需要編寫重載的方法。

屬性原則上，字段（Field）是不能公開的，要訪問字段的值，一般使用屬性。屬性以簡(jiǎn)單清楚的名詞命名：

publicintConcentration{get{return0;}set{}

}變量和常數(shù)常數(shù)以說明常數(shù)意義的名詞命名：

publicconstintDefaultConcentration=12在嚴(yán)格要求的代碼中，常數(shù)以c_開頭，如c_DefaultConcentration，但最好不要用它，它會(huì)帶來輸入困難。

普通類型的變量，只要用有意義的名字命名即可，不可使用簡(jiǎn)稱和無意義的名稱諸如A，x1等標(biāo)簽

標(biāo)簽就是用于Goto跳轉(zhuǎn)的代碼標(biāo)識(shí)，由于Goto并不推薦使用，所以標(biāo)簽的使用也對(duì)比苛刻。標(biāo)簽必需全部大寫，中間的空格用下劃線_代替，而且應(yīng)當(dāng)以_開頭，譬如：

_A_LABEL_EXAMPLE:如此定義標(biāo)簽是為了與其他代碼元素充分區(qū)別。

0名稱空間命名名稱空間的一般規(guī)矩如下：

CompanyName.TechnologyName這樣，我們看到的名稱空間應(yīng)當(dāng)是這樣的：

Microsoft.OfficePowerSoft.PowerBuilder注意：這只是一個(gè)原則。第三方公司可以選擇其它的名字。

避免用公司名稱或其它有名品牌的名稱作為名稱空間的前綴，這樣會(huì)

造成兩個(gè)公布的名稱空間有同一個(gè)名稱的可能性。（例如，將微軟提供的Office自動(dòng)類命名為Microsoft.Office。）

使用Pascal大寫方式，用逗號(hào)分隔邏輯成分（例如，Microsoft.Office.PowerPoint）。假如你的品牌使用的是非傳統(tǒng)大寫方式，那么一定要遵循你的品牌所確定使用的大寫方式，即使這種方式背離了尋常的名稱空間大寫規(guī)矩（例如，NeXT.WebObjects，和ee.cummings。）

該用復(fù)數(shù)的時(shí)候要使用復(fù)數(shù)的名稱空間名。

例如，使用System.Collections而不是System.Collection。本規(guī)矩的特例是品牌名稱和縮寫。例如：使用System.IO而不是System.IOs。

名稱空間和類不能使用同樣的名字。例如，有一個(gè)類被命名為Debug后，就不要再使用Debug作為一個(gè)名稱空間名5.2.2書寫格式規(guī)范總則格式化使代碼的規(guī)律結(jié)構(gòu)很明顯。

要求書寫格式1)使用四個(gè)空格作為標(biāo)準(zhǔn)的縮進(jìn)大小，并一致地使用此標(biāo)準(zhǔn)；2)括號(hào)位于下一行，要求相匹配的大括號(hào)在同一列；3)每一行上放置的語句避免超過一條；4)對(duì)繼行則要求再縮進(jìn)4格。

5.2.3解釋規(guī)范一般性問題1)其他人得到了代碼是否能夠很快的理解它;

2)解釋是否解釋了代碼的意圖，而不僅僅是描述重復(fù)描述流程;3)技巧性過強(qiáng)的代碼是否重新編寫了而不是僅僅加一些解釋;4)解釋是否及時(shí)更新了，以正確反應(yīng)最新的程序含義;5)解釋的風(fēng)格是否能夠保證修改解釋很簡(jiǎn)單;6)使用XML文檔功能；7)修改代碼時(shí)，總是使代碼周邊的解釋保持最新；8)在每個(gè)函數(shù)的開始，說明函數(shù)的用途、假設(shè)和限制等；9)除了批注變量聲明外，避免在代碼行的末尾添加解釋；10)在部署之前，移除所有臨時(shí)或無關(guān)的解釋；11)解釋應(yīng)當(dāng)表明代碼，而不應(yīng)當(dāng)增加多義性；12)在編寫代碼時(shí)就解釋，由于以后很可能沒有時(shí)間這樣做；13)避免多余的或不適當(dāng)?shù)慕忉?，如幽默的不主要的備注?4)使用解釋來解釋代碼的意圖，而不是作為代碼的聯(lián)機(jī)翻譯；15)為了防止問題反復(fù)出現(xiàn)，對(duì)錯(cuò)誤修復(fù)和解決方法代碼總是使用解釋；16)對(duì)由循環(huán)和規(guī)律分支組成的代碼使用解釋。

語句和段落1)代碼是否避免了在程序語句末尾的解釋；2)解釋是否更側(cè)重于解釋"為什么這么做'，而不是"如何做'；3)解釋是否能夠引導(dǎo)讀者的思路；4)每一個(gè)解釋是否都是有價(jià)值的，多余的，無關(guān)的或自相矛盾的解釋是否刪除了或改正了；

5)縮寫單詞是否替換為完全拼寫形式了；6)主要解釋和次要解釋的區(qū)分是否明顯；7)代碼繞過了一個(gè)錯(cuò)誤或者未在文檔中記載的特性的狀況是否在解釋中說明白。

數(shù)據(jù)定義1)數(shù)據(jù)的單位是否說明白；2)數(shù)值型數(shù)據(jù)的取值范圍是否說明白；3)輸入數(shù)據(jù)的限制是否說明白；4)使用標(biāo)志的解釋是否細(xì)到了每一個(gè)位；5)使用的全局變量的地方是否在解釋中說明白該全局變量是在那里定義的；6)使用了全局變量的任何地方能否通過解釋或命名規(guī)矩看出它是一個(gè)全局變量；7)每個(gè)操縱語句是否都有解釋；8)對(duì)比長(zhǎng)的或繁雜的操縱結(jié)構(gòu)終止的地方是否有解釋，以便于閱讀；9)需要使用特定數(shù)值的數(shù)據(jù)是否在解釋中記載了，或者采用更好的方式：使用命名常量或變量。

例程例程的目的是否在解釋中說明白。

解釋能夠找得到例程相關(guān)的其他方面的信息，包括：輸入輸出參數(shù)、調(diào)用條件假設(shè)、限制、錯(cuò)誤數(shù)據(jù)改正、算法來源等。

文件、模塊和程序

程序有沒有全局性描述，介紹程序的總體結(jié)構(gòu)和組織方式。

每一個(gè)文件的用途是否都有記載。

5.3.JAVA編程規(guī)范5.3.1命名規(guī)矩Package的命名Package的名字應(yīng)當(dāng)都是由一個(gè)小寫單詞組成。

Class的命名Class的名字必需由大寫字母開頭而其他字母都小寫的單詞組成。

Class變量的命名變量的名字必需用一個(gè)小寫字母開頭。后面的單詞用大寫字母開頭。

StaticFinal變量的命名StaticFinal變量的名字應(yīng)當(dāng)都大寫，并且指出完整含義。

參數(shù)的命名參數(shù)的名字必需和變量的命名規(guī)范一致。

數(shù)組的命名數(shù)組應(yīng)當(dāng)總是用下面的方式來命名：

byte[]buffer;而不是：

bytebuffer[];方法的參數(shù)使用有意義的參數(shù)命名，假如可能的話，使用和要賦值的字段一樣的名字：

SetCounter(intsize){this.size=size;

}5.3.2文件樣式所有的Java文件(*.java)都必需遵守如下的樣式規(guī)矩。

版權(quán)信息版權(quán)信息必需在java文件的開頭，譬如：

/***lt;pgt;Title:lt;/pgt;*lt;pgt;Description:lt;/pgt;*lt;pgt;Copyright:Copyright(c)2022lt;/pgt;*lt;pgt;Company:lt;/pgt;*@authornotattributable*@version1.0*/其他不需要出現(xiàn)在JavaDoc的信息也可以包含在這里。

Package/Importspacka