如何寫出優秀的C代碼？

　　一份優秀的代碼必然是多種編程技巧和設計思想結晶，所以還需一步一步的積累，分享這篇構建“庫”思想的文章，大家也可以體會一下。

　　設備程序如果完美庫化會怎樣？

　　1、所有工程師在移植或創建該設備驅動時，花費的代價超小。

　　2、隨著使用者的增多，它飽經考驗，不斷趨于穩定，變為當之無愧的公共代碼。

　　3、庫對外的接口（函數名及其參數聲明）是不變的，當所有常用設備都實現庫化時，它帶來另外一個好處，應用層的移植、創建、修改維護的時間耗費也會劇烈減少。應用層的跨平臺無縫移植不是傳說，當它所依賴的所有外圍設備通通在不同平臺庫化的時候，應用層的實現，就像在寫java代碼一樣。

　　4、庫同時意味著公司核心代碼的安全，庫代碼只掌握在核心工程師手里，應用層的程序即使丟失也是無礙。

　　5、新人對于這些基于庫案子更快上手，一來有庫幫助文檔的說明，二來不必也無法關心底層細節，專注于應用開發。

　　6、提供給客戶二次開發，你可以把硬件和外設驅動的庫交給客戶，讓其二次開發。

　　7、通信協議的庫化，將使通信系統類的產品更加安全，至少不會被離職的工程師破壞，比如RFID的扣款充值。

　　8、and so on~ 怎么樣，用庫的方式進行設計組織代碼是不是很酷~，當時這些都是庫的設計目標，真正到了工程師手里，能達到什么效果，就得看水平了~ 當然，有些工程師會想到，庫可以使他脫離繁瑣的底層驅動工作，進行更高層次的工作。

　　搞得好庫創建需要的條件

　　1、提供給客戶的只有.h檔和.lib檔

　　2、所有.h檔中沒有define，編譯條件對于.lib檔來說只是一個笑話。

　　3、所有.h檔中沒有extern變量，如果有，這意味著系統只能創建一個這種設備。比如蜂鳴器驅動，如果extern變量，就意味著整個系統只允許一個蜂鳴器。

　　4、完善而詳細的使用幫助文檔。可參考keil的hlp文檔格式。

　　5、簡單的使用該.h檔的demo程序讓人參考。

　　6、“動態鏈接”庫代碼，簡言之，沒用到的接口函數代碼不會被鏈接器搞到最終的二進制檔中。

　　7、還有一點，盡量的平臺無關性，它不依賴于任何寄存器或者其他和平臺相關的東西。

　　要達到上述的目的，通常會使庫有如下特點：

　　1、結構體指針。

　　2、大量的回調函數指針。

　　3、豐富的接口。

　　4、庫源碼的.c檔將按接口函數拆分成更多的.c檔，這為了實現鏈接時代碼空間最小化。 當然凡是都有其兩面性，如果庫這么簡單容易、有沒有什么確定，那不每個人都信手拈來了？

　　一些需要考慮的其他問題：

　　1、它會使設備速度變慢一些，多了幾層間接取址的消耗。但對于32位機，對于它帶來的便利，還是可接受的。

　　2、它會使code空間消耗相對更大一些，但請相信我，對于一整個中大型系統而言，它會使代碼量不升反降，因為大系統中有非常多的重復冗余代碼。這方面我個人的經驗，降的不是一般的多，簡直到了一個難以置信的程度。

　　早期的8位機，51平臺上其實不能很好地實現完美的庫，至少是不能實現一個跨機型的底層設備驅動庫。

　　近年來隨著32位機的興起，庫漸漸地受到越來越多工程師的青睞。這里面最本質的原因在于，51架構的棧是靜態編譯的，局部變量和傳參的棧也是靜態的，函數無法重入。而多數的32位機都是壓棧傳參的方式。當然，51速度慢也是重要的原因之一。 如果有熟悉面向對象語言或者linux驅動的朋友，你大概就明白一個好的庫是什么樣子的了。庫就像似面向對象中的類，至于linux底層驅動的代碼，那就是函數指針和結構體指針的世界。

　　C的精華在指針，在里面得到完美的詮釋。

　　編輯：黃飛