Code Style(代碼的風格)
2019-09-06 23:33:49
供稿：網友
1./t簡介
2./t什么是風格？
3./t代碼的風格為什么如此重要？
4./t更少的工作，更多的文檔？
5./t推薦的代碼風格
6./t簡單的文檔
7./t輸出風格
8./t結論
簡介
讓我們面對一下吧…如果您是一個資深的程序員，那么您總是在最后期限下工作并且您的最終目標是完成您設計的軟件。如果您是個新手，您的努力是更多的研究、試驗、當然還有錯誤和一心希望您的程序可以象打算的那樣運行。不管怎樣，當您的程序真的如愿以償的運行時那種成功的感覺令人十分振奮，但更多的程序員發現能夠用良好的風格生成程序內部代碼時的那種自豪的感覺更棒。
如果您是程序設計小組的成員或者如果您還在書寫學校分配的任務，那么您會有機會被要求遵守某些必須遵守的風格規則。 絕大多數的程序員考慮風格這件事就象一個10歲大的孩子看待就寢時間一樣。但資深程序員和我所見過的小組領導及多年來使用許多風格的程序員都會試圖向您傳達良好的代碼風格與您所得意的一些書寫代碼的技巧同樣重要。在這篇文章中我將嘗試包括一些輸出風格的觀點，這也許有助您的編程旅程。
更少的工作，更多的文檔？
因此風格意味著要在代碼的每一行加上注解，對嗎？錯。如果沒有做對的話，注解也會變成一場災難。 我仍然希望一個程序員學會喜歡輸入注解或真正對注解有足夠的重視。為了未來的可維護性必須強制自己正確的放置注解。所以怎么能夠不使用注解？
顯然對一個新手最困難的事是懂得什么是好的變量命名。讓我們看看以下的代碼。您能告訴我下面的代碼是做什么的嗎？
/t/t float __fastcall TExampleForm::CalcAverageGrade(void)
/t {
/t int y=0;
/t int i=0;
/t for (i; i<x; i++) {
/t/t y=y+g;/t
/t }
/t return float(y/x);
/t/t }
在上面的例子中，您能很輕易的告訴我y代表什么呢？x又是什么呢？這段代碼也許需要一些注釋來解釋這些變量的代表意義及代碼中發生了什么？應用以上的代碼風格，看不出什么邏輯關系。現在讓我們看看應用更好的代碼風格以后，代碼是何等模樣？
/t/t float __fastcall TExampleForm::CalcAverageGrade(void)
/t {
/t int total=0;
/t for (int i=0; i<maxGrades; i++)
/t/t {
/t/t total+=Grades;
/t } //求所有成績的和
/t return float(total/maxGrades);
/t } //計算平均成績
在您除錯時以上兩段代碼孰優孰劣，已不必多說。現在就讓我們討論一些能夠讓您的代碼更具有可維護性的推薦風格吧。
推薦的代碼風格
1. 使用有描述意義的變量名。
2. 使用i, j, k, l, m作為循環計數變量。這起源于Fortran，自始自終這都是事實上的工業標準。
3. 在閉合括號處為所有的聲明和方法注釋。這樣在嘗試找到與此配對的上一個初始括號時更容易做決定，尤其在聲明很長時。
4. 考慮將if后面或循環定義體的初始括號放在一個單獨的行上。這真的有助于您找到與其對應的閉合括號。
5. 使用適當的組合運算符 (+=, *=, 等等)。對自增（自減）變量使用++ 和 -?C運算符。正確使用這些運算符會使您的代碼更可讀和更一致。這也減少了輸入的字符數量。組合運算符也會幫助編譯器生成更快的代碼。舉例來說，i++產生的asm（匯編）代碼是inc ，而i=i+1將會產生如下的asm（匯編）代碼mov eax, inc eax mov ,eax。
6. 注解代碼時，要明智些！如果一段代碼的邏輯關系很復雜，注解將有助于別人理解代碼的意圖。但如果邏輯關系直線向前，避免加上并非必須的注解。要象維護您的代碼一樣維護您的注解！
7. 命名變量時，使用有描述意義的大寫。簡單變量（例如，int, long, String）應該以小寫字符開始。復雜變量（例如，對象、結構、數組）應該以大寫開始。變量名稱中包含的所有單詞都應該大寫開頭。這會讓讀（寫）代碼的人對所訪問的數據類型有一個清晰的第一印象。
8. 避免在變量名中使用下劃線。絕大多數的編譯器中，它都有特殊的意義。
9. 盡可能（而不是瘋狂的）將代碼模塊化。合理的話，將代碼放入函數中去。這允許更好的代碼重用性和可讀性。
10. 使用正確的循環。如果代碼最少要執行一次，使用do-while循環，否則使用while-do循環。如果確切的循環執行次數已知，使用for循環。
11. 在事件發生的數量超過兩種時，只要可能就使用switch聲明。同時，無論何時只要可能就包含一個switch default（缺省開關），這樣總會有一個選項被觸發。Switch聲明很容易除錯，而且比組合的多重if聲明執行速度更快。
12. 在您代碼中的邏輯步驟之間加上一個空行（例如，定義變量、循環、等等）。
13. 聲明變量的位置非常重要。變量應該聲明的位置幾乎沒有隨意性。當變量用于整個（類）對象或者必須在對象外可見的時候，變量應放在頭文件中。臨時變量如果不需要在if聲明或循環體外被訪問的話，就應在它們內部聲明。不正確的放置變量聲明會導致執行速度減慢、錯誤、或者引起誤導的代碼。
14. 初始化所有的變量。
15. 如果您有非空返回（帶返回值）的函數，確保所有的退出點都使用了return。對編譯器產生的警告"function should return a value"（函數應該返回一個值）要引起足夠重視。這是嚴重警告并且可能導致您的軟件發生隨機錯誤。
16. 在兩個不同類型的變量間賦值時，應對變量進行強制轉換計算來避免編譯器的警告（例如：int x; float y; … y=float x;）。這么做可以防止"Conversion may loose significant digits"的警告。作為一個程序員您的目標應該盡可能的減少警告的數量。而強制類型轉換將消除其中的大多數。
17. 永遠在刪除后將指針設為NULL。
18. 盡量仔細的調查以避免“閉門造舊車”。經過證明的函數與程序使用時優先于新寫的代碼。這會讓您有更多的時間去寫真實的邏輯代碼并且非常有助于維護。盡管盡管動態鏈表的書寫非常有趣，它早已被完成了！
19. 正確的拼寫很重要。如果拼寫有錯的話，將來的搜索會很困難。
20. 永遠不要使用兩個只有大小寫不同的變量名字。
21. 在您創建代碼時就輸入注解，而不是以后。在您修改代碼的時候，保持對注解的維護。
22. 如果您在調試或除錯時注解（rem）了一段代碼的話，確保您最后將被注解的代碼刪除。
23. 最后最重要的是…保持風格的一致。
簡單的文檔
平凡的文檔在創建一個可維護的系統是卻十分有效。您應該設置一個標準來為您的文檔注解模板規定文件的開始處應該放置的內容。這里是某些應該在您的模板中完成的東西：
1．/t 原創作者名字
2．/t 原始創建日期
3．/t 文件的用途
4．/t 包括使用指導在內的主要內容列表
5．/t 包括修訂日期的修訂歷史記錄。同時應該說明修訂時發現并修復的bug。
文件注解應該放在文檔頭部，并盡量簡明。下面是我們現在的應用程序的一個例子。這個例子比較復雜。
/*
Written by（作者）: Scott Cross/t/t
Date originally Completed（原始完成日期）: 9/18/99
Purpose（用途）: Main routine for NY Billing. This logic calculates the installments and provides all data necessary to print, display, and report billing status. The form will display the billing information. The main structure, InvoiceInfo, has all information including detail of Installments and Payment activities. Although the main object is a form, the form need not be shown in order to get billing information. This is the only billing logic for this version of the system. All billing inquiries should go through this routine.
Usage（用法）: Nothing will be performed during the OnCreate event with the exception of setting some reference variables. All calculations are done by calling the main routine LoadAcctInfo. This routine can be called many times for different policies since it is fully initialized on each call. There are 5 parameters for the main functions and their usage is as follows:
bool LoadAcctInfo(
String policyNo - Supplies the logic with the targeted PolicyNo./t
bool printInvoice - Set to true if you want to print the invoice./t
bool nightRunning - If being called from the night, set to true./t
bool payableRunning - If being called by accounting rpt, set to true.
String masterPrintDate - This is a date. For more info on usage, see cpp.
);
No preliminary logic needs to be performed and the function will return true in most cases. No structures are passed since the main structure is public. It is imperative that the LoadAcctInfo be called prior to displaying the screen or unexpected results can occur since the main structures will not be initialized.
struct InvoiceInfoStruct{
PaymentHistoryStruct Payments[30]; - Payment History
int paymentCount; - Count of Payments
InstallmentStruct Installments[30]; - Installment Information
int installmentCount; - Count of Installments
int currInstall; - The current due installment
float totalPaid; - The total paid on file *
float totalDue; - Total due on file
float pastDue; - Total amount past due
float totalBilled; - Total amount billed on file
float totalApplied; - Amount applied to installments **
String equityDate; - The date the premium is paid to
String dateDue; - Date the file is due a payment
float annualizedPremium; - the annualized premium ***
};
* Restricted to masterPrintDate
** Should equal total paid
*** What the annualized premium is for the policy as stored in the tables if rated for one year.
Update History（更新歷史）:
09/18/1999 - Scott - Completed
02/01/2000 ?C Scott - Fixed totalPaid error on cancelled file
*/
輸出風格
輸出風格沒有標準。在我的觀念中，編程最精彩的部分是程序的設計。您可以有自己的選擇，從什么是好的或壞的直到系統的外觀和感覺。盡管如此，仍有些有助于您的設計的建議。
1. 選擇統一的字體。
2. 把界面設計成可以在不同分辨率和不同設置下正常工作。啟用/不用大字體，然后測試您的軟件。并假定用戶仍在windows的VGA設定下運行（640X480 16色）。
3. 在多種顏色方案下測試軟件。
4. 嘗試維護逼真的3D效果。大多數情況下，初始的form（頁面）應該是凸起的并帶有一種附加的下凹效果。盡管這看起來有點小兒科，但這使得程序有了深度并非常有助于分割頁面。
5. 牢記輸出效果的性能。在處理器集中的循環中，更新越簡單，執行就越快。
6. 盡量避免在界面中使用太多的噱頭組件和效果。這會給人不專業的感覺，也可能傷害用戶的信心，除非工程要求浮華的設計。
7. 設計登錄屏幕，讓用戶無須鼠標動作就可以獲得更多。
8. 您的用戶也許欣賞毫不雜亂的環境，但也要牢記這依靠用戶的配置，多屏可能會使系統太慢。嘗試在速度和可用性之間找到平衡吧。
9. 在任何時候使用彈出提示和提示條都是合適的。從一開始就就記住要將頁面設置成這樣的。
10. 向導類型的界面對復雜的多步驟過程時十分合適。這使得軟件可以指導用戶一步步的走過這些步驟。找一個好的NoteBook（筆記本）組件吧。
11. 在進行長時間的操作時，應該總是調用Application->ProcessMessages();保持界面更新并讓windows知道您的應用程序仍然處于活動狀態且能夠響應消息。
12. 最后最重要的是…保持系統風格的一致。
結論
編程的風格要比許多程序員想像的更重要的多。您想讓別的程序員看見您現在的工程中的代碼嗎？您是不是對您的代碼和您的系統一樣自豪呢？現在花點時間來決定想在您的代碼中采用何種風格并開始每天使用這種風格。記住，用6個星期來發展一個習慣，不管它是好的還是壞的。
祝 好運！
原著： Scott Cross
翻譯： cker
版權說明：
國內的網站上，有許多關于C＋＋Builder的內容，但多以軟件、組件為主。論壇里也大都不能令人滿意，很空虛的感覺。書籍又都昂貴，內容卻有搶錢之嫌。對銀子不足的初學者、自學者關愛不夠，因而想盡自己的綿薄之力。
文中的所有資料都是從國外網站上收集而來。因為E文不方便，所以翻成中文。又因為English和計算機都不是非常好，文中的錯誤在所難免。若大家覺得有用的話，我計劃不斷搜集翻譯一些有用的東西。
有任何意見和建議請mailto：cker@sina.com
您可以隨意復制、分發、下載此文檔。但未經本人同意，您不可以截取、改動本文片斷，或用本文謀取任何形式的利益.
