【單片機到嵌入式之路】序列之5：你的代碼別人有耐心看么？

　　本節我們將從代碼格式來審視你的代碼，主要是從下面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++ 代碼規范參考】一書。

　　對于代碼對齊 和 一些其它的內容，我希望大家可以多閱讀別人的代碼，多練習，只有多練習了才能掌握于心，才能運用自如。

　　以上的內容大家可以作為參考，就作為拋磚引玉吧，希望大家能提出更好的方法，共同提高才是王道!!!