【文章內容簡介】 好、更不易出錯，而且同樣高效。第二十七條 編碼慣例1． 避免在一個文件中放多個類2． 一個文件應該只對一個命名空間提供類型，避免在同一文件中有多個命名空間 3． 避免一個文件的長度超過500行（除了機器生成的代碼）4． 避免方法定義超過25行5． 避免超過5個參數的方法，使用結構傳遞多個參數 6． 每行應該不超過80個字符，或者10個單詞 7． 不要手工編輯任何機器生成的代碼，修改代碼格式和風格以符合本編碼標準 8． 避免對顯而易見的內容作注釋，由可讀性強的變量和方法組成的好的代碼應該不需要注釋 9． 僅對操作的前提、內在的算法等寫文檔 10． 避免方法級的文檔 11． 決不要硬編碼數值，聲明一個常量是最好的選擇 12． 僅對本輪就是常量的值使用const修飾符，例如一周的天數 13． 避免對只讀變量使用const修飾符。在此情況下，采用readonly修飾符public class MyClass { public const int DaysInWeek = 7。public readonly int Number。public MyClass(int someValue){ Number = someValue。} }14．對任何假設采用assert。平均來講，每五行代碼中就有一行是斷言using 。object GetObject(){} object someObject = GetObject()。(someObject!= null)。15． 16． 17． 每行代碼都應該經過白盒測試 僅捕獲已經顯式處理了的異常在拋出異常的catch語句中，總是拋出最初異常以保持最初錯誤的堆棧位置catch(Exception exception){ ()。throw。}18． 定義自定義的異常時 19． 避免采用friend程序集，因為這樣增加了程序集間的耦合度 20． 避免使用依賴于從特定位置運行的程序集的代碼。21． 盡量減少應用程序集（客戶端EXE程序集）的代碼，采用類庫而不要包含業(yè)務邏輯層代碼。22． 避免對枚舉提供明確的值//正確public enum Color { Red,Green,Blue } //錯誤public enum Color { Red=1,Green=2,Blue=3 }23． 避免對枚舉指定類型//錯誤public enum Color : long { Red, Green, Blue }24． 25． 26． If語句總是使用括號，即使它只包含一句語句 避免使用?:條件運算符 避免使用（if…endif），應使用conditional方法代替[Conditianal(“MySpecialCondition”] public void MyMethod(){}27． 避免在布爾條件語句中調用函數，賦值到局部變量并檢查它們的值。bool IsEverythingOK(){} //錯誤if(IsEverythingOK()){} //正確bool ok=IsEverythingOK()。if(ok){}28．29． 總是使用從0開始的數組總是使用一個for循環(huán)顯式地初始化一個引用類型數組public class MyClass {} const int ArraySize=100。MyClass[] array=new MyClass{ArraySize]。for(int index=0。index30． 31． 不用提供public或protected成員變量，而是使用屬性 應盡量使用get/set的自動返回屬性//錯誤class MyClass { int m_Number。public int Number { get { return m_Number。} set { m_Number=value。} } } //正確class MyClass { public int Number { get。set。} }32． 33． 34． 35． 避免使用new,應使用override替代在一個密封的類里總是把public和protected方法標記為virtual 永遠不要使用不安全的代碼 合理使用as操作符進行映射Dog dog = new GermanShepherd()。GermanSheperd shepherd = dog as GermanShepherd。if(shepherd!= null){} 36． 37．{ 在使用一個委托前總是要先檢查它是否為空（null）不要提供公有成員變量，使用存取器（accessors）進行替代public class MyPublisher MyDelegate m_SomeEvent。public event MyDelegate SomeEvent { add { m_SomeEvent += value。} remove { m_SomeEvent= value。} } }38． 避免定義事件處理委托，使用EventHandler或者GenericEventHandler進行替代 39． 使用EventsHelper安全的發(fā)布事件 40． 總是優(yōu)先使用接口，但要避免一個接口只包含一個成員，包含35個成員較為合適。上限為12。41． 避免事件成為接口成員 42． 提供明確定義的接口描述 43． 不要假設一個接口是可以安全運作的，永遠都要做好處理意外的準備SomeType obj1。IMyInterface obj2。obj2=obj1 as IMyInterface。if(obj2!= null){ ()。} else { //處理可能出現(xiàn)的錯誤}44． 不要將可能改變的，或用于數據庫連接的，或者交付給最終客戶使用的任何字符串進行硬編碼，要使用資源文件定義他們 45． ””//錯誤string name = “。//正確string name = 。46． 47． 48．定義長字符串的時候，應該使用StringBuilder，而不是string 永遠不要使用goto語句，除非迫不得已在switch代碼塊中總要包含一個default項，并且為其設置斷言int number = SomeMethod()。switch(number){ case 1: (”Case 1:“)。break。case 2: (”Case 2:“)。break。default: (false)。break。}49．不要使用this引用，除非某些特殊情況，比如從一個構造器中運行另外一個//一個正確使用this的例子public class MyClass { public MyClass(string message){} public MyClass():this(”Hello){} }50． 不要使用base關鍵詞。除非你想要解決一個子類成員和基類間的名稱沖突，或者運行一個基類構造器//一個正確使用base的例子public class Dog { public Dog(string name){} virtual public void Bark(int howLong){} } public class GermanShepherd:Dog { public GermanShepherd(string name):base(name){} public override void Bark(int howLong){ (howLong)。} }51． ()，不要依賴HandleCollector。合理的使用Dispose()和Finalize()方法 52． 一般情況下不要使用check來檢查代碼（防止性能損失），但是在可能的溢出區(qū)則使用check來保持代碼的安全性。安全性的優(yōu)先級永遠高于性能。int CalcPower(int number,int power){ int result=1。for(int count=1。count53． 在代碼中要避免直接使用object數據類型（），可以使用約束或者as進行替代。class SomeClass {} //錯誤class MyClass { void SomeMethod(T t){ object temp=t。SomeClass obj=(SomeClass)temp。} } //正確class MyClass where T: SomeClass { void SomeMethod(T t){ SomeClass obj =t。} }54．{} 一般而言，不要在通用接口中定義約束。接口級別的約束經常會被強類型所覆蓋public class Customer //錯誤public interface IList where T: Customer {} //正確public interface ICustomerList:IList {} 第二十八條 安全1． 總是對應用程序私有的組件，集合等使用強名，這樣可以保證安全性2． 在應用程序配置文件中使用加密算法，進行安全保護3． 對不受控制的引用方法，要做適當的安全處理，如加入斷言控制4． 不要使用SuppressUnmanagedCodeSecurity屬性 5． 不要使用/。6． 在服務器端要使用自定義的安全規(guī)則來擴展Microsoft的默認配置，以保證更高級別的安全性7． 為防止引誘性攻擊，應修改組件級別的運行權限，限制其可能的不安全行為8． 在編寫Windows程序時，在每個Main（）中都要使用相應的安全規(guī)則第三篇：C 編碼規(guī)范之命名空間C++編碼規(guī)范之命名空間C++,提倡使用不具名的命名空間。使用具名命名空間時,其名稱可基于項目或路徑名稱,不要使用using指示符。定義:命名空間將全局作用域細分為不同的,具名的作用域,可有效防止全局作用域的命名沖突。優(yōu)點:。缺點:命名空間具有迷惑性,因為它們和類一樣提供了額外的命名軸線。在頭文件中使用不具名的空間容易違背C++的唯一定義原則。1),允許甚至提倡使用不具名命名空間,以避免運行時的命名沖突:namespace{//命名空間的內容無需縮進enum{UNUSED,EOF,ERROR}。bool AtEof(){return pos_ == EOF。}}//namespace然而,與特定類關聯(lián)的文件作用域聲明在該類中被聲明為類型,靜態(tài)數據成員或靜態(tài)成員函數,而不是不具名命名空間的成員。像上文展示的那樣，不具名命名空間結束時用注釋//namespace標識。注:。2)具名命名空間命名空間將除文件包含,全局標識的聲明/定義以及類的前置聲明外的整個源文件封裝起來,以同其他命名空間相區(qū)分。//.h文件namespace mynamespace{class MyClass{public:...void Foo()。}。}//namespace mynamespace//.cc文件namespace mynamespace{//函數定義都置于命名空間中void MyClass::Foo(){...} }//namespace mynamespace禁止污染命名空間using namespace foo。第四篇：JAVA程序員不可不注意的編碼規(guī)范最近經?？匆恍┡笥褜懙脑创a，總是感覺編碼規(guī)范問題還沒有成為大家的關注點，導致代碼的通用可讀性相對比較差；所以在此嘮叨幾句編碼規(guī)范（以struts2+spring2+hibernate3架構的項目為例），大家各取所需，歡迎拍磚！一、規(guī)范存在的意義應用編碼規(guī)范對于軟件本身和軟件開發(fā)人員而言尤為重要，有以下幾個原因：好的編碼規(guī)范可以盡可能的減少一個軟件的維護成本 , 并且?guī)缀鯖]有任何一個軟件，在其整個生命周期中，均由最初的開發(fā)人員來維護；好的編碼規(guī)范可以改善軟件的可讀性，可以讓開發(fā)人員盡快而徹底地理解新的代碼；好的編碼規(guī)范可以最大限度的提高團隊開發(fā)的合作效率；長期的規(guī)范性編碼還可以讓開發(fā)人員養(yǎng)成好的編碼習慣，甚至鍛煉出更加嚴謹的思維；二、命名規(guī)范一般概念盡量使用完整的英文描述符采用適用于相關領域的術語采用大小寫混合使名字可讀盡量少用縮寫，但如果用了，必須符合整個工程中的統(tǒng)一定義避免使用長的名字（小于 15 個字母為正常選擇）避免使用類似的名字，或者僅僅是大小寫不同的名字避免使用下劃線（除靜