|
本節我們將從代碼格式來審視你的代碼，主要是從下面3個方面進行講解： 1.代碼格式的重要性 2.規范自己的代碼格式 3.函數設計和變量定義格式 一、代碼格式的重要性： 好的代碼格式猶如男工程師看見美女，女工程師看見帥哥一樣，有種一見鐘情的感覺。但是事實上很多人不注重代碼的規范性，結果寫出來的代碼，沒有連自己都不想看第二遍，這是工程師的大忌。 不論是硬件工程師還是軟件工程師，良好的代碼格式是基本功。如果你寫的代碼別人就看了幾行就感覺惡心、嘔吐，你說你的代碼別人還有耐心全部看完么? 以前看見一個研究生，以為自己多牛逼，寫的代碼沒有一行注釋了。變量取名也是莫名其妙的，結果有一個bug。導致他檢查了半個月。何必這樣害自己呢?不要以為你寫的代碼多高級，不要加注釋，不注重格式，怕別人復制。別人想復制你的代碼，說明你的代碼有價值。 好了不多少了，直接進入下一個小點吧。O(∩_∩)O~ 二、規范自己的代碼格式 1.文件結構 a) 版權和版本的聲明 這個是每個公司或者個人為了保護自己的代碼而寫的。格式也不是固定了，主要根據個人的愛好來寫的。下面貼出本人喜歡的格式。 /* * Copyright (c) 2014, 鑫亮電子 * All rights reserved. * 文件名稱：usart.c * 摘 要：串口驅動函數 * 硬件平臺：STM32F030探索套件 * 當前版本：V0.0 * 完成日期：2013-01-09 * 修改記錄： */ 很簡單，僅僅作為參考吧。 b) 頭文件的結構 頭文件由三部分內容組成： (1)頭文件開頭處的版權和版本聲明。 (2)預處理塊。 (3)函數和類結構聲明等。 下面主要看頭文件的類型，以個人平時的程序為例： /* Includes ----------------------------*/ #ifndef __EXTI_H //防止重定義 #define __EXTI_H //個人愛好 #include "STM32F0xx.h" //包含的頭文件 void EXTI_KEY_Init(void); //外部中斷初始化 //個人愛好 #endif c) 定義文件的結構 定義文件有三部分內容： (1) 定義文件開頭處的版權和版本聲明。 (2) 對一些頭文件的引用。 (3) 程序的實現體(包括數據和代碼)。 下面以常見的例子為例： // 全局函數的實現體 void Function1(…) { … } 2.程序的板式 為了更好的講解程序的版式，下面以一個例子為例來講解： /*************************************** * 函數描述：外部中斷0服務程序 * 輸入參數：No * 返 回 值：No * 說 明：無 * 修改記錄：無 ****************************************/ void EXTI0_1_IRQHandler(void) { if(EXTI_GetITStatus(EXTI_Line0) != RESET)//判斷線0上的中斷是否發生，可以理解為標志位 { /* Toggle LED3 and LED4 */ GPIO_WriteBit(GPIOC,GPIO_Pin_8, (BitAction)((1-GPIO_ReadOutputDataBit(GPIOC, GPIO_Pin_8)))); GPIO_WriteBit(GPIOC, GPIO_Pin_9, (BitAction)((1-GPIO_ReadOutputDataBit(GPIOC, GPIO_Pin_9)))); /* Clear the EXTI line 0 pending bit */ EXTI_ClearITPendingBit(EXTI_Line0);//清除LINE0上的中斷標志位 } } A.注釋方式有有兩種【//】 和 【/* */】. B.對齊方式要注意。 C.函數的設計也很重要。 D.變量的定義也很關鍵。 E.拆行也很重要，關鍵在其可讀性。 F.必要的注釋可以讓讀者理解的更快，對自己以后維護更便捷。 三、變量的定義和函數的設計 1.變量的定義 a) 見名知意 int width; //定義寬度 #define MAX 100; /* 最大值為100*/ 等等，上面也是兩種注釋方式。 游客,如果您要查看本帖隱藏內容請回復 2.函數的設計 函數的設計其實很關鍵，對讀者相當重要。一個好的函數設計可以讓讀者看出設計者別出心裁。下面簡單舉幾個例子來說明： void Object::SetValue(int width, int height) { m_width = width; m_height = height; } 下面再講述一下斷言的使用： 程序一般分為Debug版本和Release版本，Debug版本用于內部調試，Release版本發行給用戶使用。 斷言assert是僅在Debug版本起作用的宏，它用于檢查“不應該”發生的情況。下面例子是一個內存復制函數。在運行過程中，如果assert的參數為假，那么程序就會中止(一般地還會出現提示對話，說明在什么地方引發了assert)。 void *memcpy(void *pvTo, const void *pvFrom, size_t size) { assert((pvTo != NULL) && (pvFrom != NULL)); // 使用斷言 byte *pbTo = (byte *) pvTo; // 防止改變pvTo的地址 byte *pbFrom = (byte *) pvFrom; // 防止改變pvFrom的地址 while(size -- > 0 ) *pbTo ++ = *pbFrom ++ ; return pvTo; } assert不是一個倉促拼湊起來的宏。為了不在程序的Debug版本和Release版本引起差別，assert不應該產生任何副作用。所以assert不是函數，而是宏。程序員可以把assert看成一個在任何系統狀態下都可以安全使用的無害測試手段。如果程序在assert處終止了，并不是說含有該assert的函數有錯誤，而是調用者出了差錯，assert可以幫助我們找到發生錯誤的原因。 很少有比跟蹤到程序的斷言，卻不知道該斷言的作用更讓人沮喪的事了。你化了很多時間，不是為了排除錯誤，而只是為了弄清楚這個錯誤到底是什么。有的時候，程序員偶爾還會設計出有錯誤的斷言。所以如果搞不清楚斷言檢查的是什么，就很難判斷錯誤是出現在程序中，還是出現在斷言中。幸運的是這個問題很好解決，只要加上清晰的注釋即可。這本是顯而易見的事情，可是很少有程序員這樣做。這好比一個人在森林里，看到樹上釘著一塊“危險”的大牌子。但危險到底是什么?樹要倒?有廢井?有野獸?除非告訴人們“危險”是什么，否則這個警告牌難以起到積極有效的作用。難以理解的斷言常常被程序員忽略，甚至被刪除。 【注意】： A.使用斷言捕捉不應該發生的非法情況。不要混淆非法情況與錯誤情況之間的區別，后者是必然存在的并且是一定要作出處理的。 B.在函數的入口處，使用斷言檢查參數的有效性(合法性)。 C.在編寫函數時，要進行反復的考查，并且自問：“我打算做哪些假定?”一旦確定了的假定，就要使用斷言對假定進行檢查。 D.一般教科書都鼓勵程序員們進行防錯設計，但要記住這種編程風格可能會隱瞞錯誤。當進行防錯設計時，如果“不可能發生”的事情的確發生了，則要使用斷言進行報警。 以上內容參考了林銳博士的【C/C++ 代碼規范參考】一書。 對于代碼對齊 和 一些其它的內容，我希望大家可以多閱讀別人的代碼，多練習，只有多練習了才能掌握于心，才能運用自如。 以上的內容大家可以作為參考，就作為拋磚引玉吧，希望大家能提出更好的方法，共同提高才是王道!!! |
