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