我們鼓勵在編程時應有清晰的哲學思維，而不是給予硬性規則，
我并不希望你們能認可所有的東西，因為它們只是觀點，觀點會隨著時間的變化而變化，
可是，如果不是直到現在把它們寫在紙上，長久以來這些基于許多經驗的觀點一直積累在我的頭腦中，
因此希望這些觀點能幫助你們，了解如何規劃一個程式的細節，要是不認同的話，那也沒關系，能啟發你們思考為什么不認同，那樣就更好了，
在任何情況下，都不應該照搬我所說的方式進行編程；要用你認為最好的編程方式來嘗試完成程式，請一以貫之而且毫不留情的這么做，
01
排版問題
程式是一種出版物，
意味著程式員們會先閱讀（也許是幾天、幾周或幾年后的你自己閱讀），最后才輪到機器，
機器的快樂就是程式能編譯，機器才不在乎程式寫的有多么漂亮，可是人們應該保持程式的美觀，
有時人們會過度關心：用漂亮的列印機呆板地列印出漂亮的輸出，而這些輸出只是將所有介詞用英文文本以粗體字體凸顯出來，都是些與程式無關的細節，
雖然有很多人認為程式就應該像 Algol.68 所描述的一樣（有些系統甚至要求照搬該風格撰寫程式），可清晰的程式不會因為這樣的呈現而變得更清晰，只會使糟糕的程式變得更可笑，
對于清晰的程式來說，排版規范一向都是至關重要的，當然，眾所周知最有用的是縮進，但是當墨水遮蓋了意圖時，就會控制住排版，
因此即便堅持使用簡單的舊打字機輸出，也該意識到愚蠢的排版，避免過度修飾，比如保持注釋的簡潔和靈活，通程序式整齊一致地說出想表達的，接著往下看，
02
變數命名
對于變數名稱，長度并不是名稱的價值所在，清晰的表達才是，
6不常用的全域變數可能會有一個很長的名稱，像 maxphysaddr，在回圈中每一行所使用的陣列索引，并不需要取一個比 i 更詳盡的名字，
取 index 或者 elementnumber 會輸入更多的字母（或呼叫文本編輯器），并且會遮蓋住計算的細節，當變數名稱很長時，很難明白發生了什么，在一定程度上，這是排版問題，看看下面
vs
現實體子中的問題會變得更糟，所以僅需把索引當成符號來對待，
指標也需要合理的符號，np 僅僅只是作為指標 nodepointer 的助記符，如果一貫都遵從命名規范，那么很容易就能推斷出 np 表示“節點指標”，在下一篇文章中會提到更多，
同時在編程可讀性的其它方面，一致性也是極其重要的，假使變數名為 maxphysaddr，則不要給同級關系的變數取名 lowestaddress，
最后，我傾向于「最小長度」但「最大資訊量」的命名，并讓背景關系補齊其余部分，
例如：全域變數在使用時很少有背景關系幫助理解，那么它們的命名相對而言更需要令人易懂，因此我稱 maxphyaddr 作為一個全域變數名，對于在本地定義和使用的指標來說 np 并不一定是 NodePoint，這是品味的問題，但品味又與清晰度相關，
我避免在命名時嵌入大寫字母；它們的閱讀舒適性太別扭了，像糟糕的排版一樣令人心煩，
03
指標的使用
C語言不同尋常，因為它允許指標指向任何事物，指標是鋒利的工具，像任何這樣的工具一樣，使用得當可以產生令人愉悅的生產力，但使用不當也可以造成極大的破壞，指標在學術界的名聲不太好，因為它太危險了，莫名其妙地就變得糟糕的不行，但我認為它是強大的符號，它可以幫助我們清楚地自我表達，
思考：當有指標指向物件時，對于那個物件，確切地說它只是名稱，其它什么也不是，聽起來很瑣碎，但看看下面的兩個運算式：
第一個指向一個 node（節點），第二個計算為（可以說）同一個 node，但第二種形式是不太容易理解的運算式，這里解釋一下，因為我們必須要知道 node 是什么，i 是什么，還要知道 i 和 node 與周圍程式之間相關的規則是什么，孤立的運算式并不能說明 i 是 node 的有效索引，更不用提是我們想要元素的索引，
如果 i、j 和 k 都是 node 陣列中的索引將很容易出差錯，而且連編譯器都不能幫助找出錯誤，當給子程式傳引數時，尤其容易出錯：指標只是一個單獨的引數；但在接收的子程式中必須認為陣列和索引是一體的，
計算為物件運算式本身，比該物件的地址更不易察覺，而且容易出錯，正確使用指標可以簡化代碼：
vs.
如果想取下一個元素的 type 可以是
或
i 前移，但其余的運算式必須保持不變；用指標的話，只需要做一件事，就是指標前移，
把排版因素也考慮進來，對于處理連續的結構體來說，使用指標比用運算式可讀性更好：只需要較少的筆墨，而且編譯器和計算機的性能消耗也很小，
與此相關的問題是，指標型別會影響指標正確使用，這也就允許在編譯階段使用一些有用的錯誤檢測，來檢查陣列序列不能分開，
而且如果是結構體，那么它們的標簽欄位就是其型別的提示，因此
是足以讓人明白的，如果是索引陣列，陣列將取一些精心挑選的名字，而且運算式也會變得更長
此外，由于例子變得越來越大，額外的字符更加讓人畝訓，
一般來說，如果發現代碼中包含許多相似并復雜的運算式，而且運算式計算為資料結構中的元素，那么明智地使用指標可以消除這些問題，考慮一下
看起來像利用復合運算式表示 p，有時這值得用一個臨時變數（這里的 p）或者把運算提取成一個宏，
04
程序名稱
程序名稱應該表明它們是做什么的，函式名稱應該表明它們回傳什么，函式通常在像 if 這樣的運算式使用，因此可讀性要好，
是沒有太大幫助的，因為不能推斷出 checksize 錯誤時回傳 true，還是非錯誤時返回，相反
使這點能清晰表達，并且在常規使用中將來也不大可能出錯，
05
注釋
這一個微妙的問題，需要自己體會和判斷，由于一些原因，我傾向于寧可清除注釋，
? 第一，假如代碼清晰，并且使用了規范的型別名稱和變數名稱，應該從代碼本身就可以理解，
? 第二，編譯器不能檢查注釋，因此不能保證準確，特別是代碼修改過以后，誤導性的注釋會非常令人困惑，
? 第三，排版問題：注釋會使代碼變得雜亂，
但有時我會寫注釋，像下文一樣僅僅只是把它們用于介紹，例如：解釋全域變數的使用和型別（我總是在龐大的程式中寫注釋）；作為一個不尋常或者關鍵程序的介紹；或標記出大規模計算的一節，
有一個糟糕注釋風格的例子：
還有更糟糕的做法：
先不要嘲笑，等到在現實中看到再去吧，
或許除了諸如重要資料結構的宣告（對資料的注釋通常比對演算法的更有幫助），這樣至關重要部分之外，需要避免對注釋的“可愛”排版和大段的注釋；基本上最好就不要寫注釋，
如果代碼需要靠注釋來說明，那最好的方法是重寫代碼，以便能更容易地理解，這就把我們帶到了復雜度，
06
復雜度
許多程式過于復雜，比需要有效解決的問題更加復雜，這是為什么呢？大部分是由于設計不好，但我會跳過這個問題，因為這個問題太大了，
然而程式往往在微觀層面就很復雜，有關這些可以在這里解決，
規則 1：不要斷定程式會在什么地方耗費運行時間，瓶頸總是出現在令人意想不到的地方，直到證實瓶頸在哪，不要試圖再次猜測并加快運行速度，
規則 2：估量（measure） 在沒有對代碼做出估量之前不要優化速度，除非發現最耗時的那部分代碼，要不也不要去做，
規則 3：當 n 很小時（通常也很小），花哨的演算法運行很慢，花哨演算法有很大的常數級別復雜度，在你確定 n 總是很大之前， 不要使用花哨演算法，（即使假如 n 變大，也優先使用規則 2）.例如，對于常見問題，二叉樹總比伸展樹高效，
規則 4：花哨的演算法比簡單的演算法更容易有 bug，而且實作起來也更困難 盡量使用簡單的演算法與簡單的資料結構，
以下幾乎是所有實際程式中用到的資料結構：
? 陣列
? 鏈表
? 哈希表
? 二叉樹
當然也必須要有把這些資料結構靈活結合的準備，比如用哈希表實作的符號表，其中哈希表是由字符型陣列組成的鏈表，
規則 5：以資料為核心 如果選擇了適當的資料結構并把一切都組織得很有條理性，演算法總是不言而喻的，編程的核心是資料結構，而不是演算法，（參考 Brooks p. 102）
規則 6：就是沒有規則 6，
07
資料編程
不像許多 if 陳述句，演算法或演算法的細節通常以緊湊、高效和明確的資料進行編碼，
眼前的作業可以編碼，歸根到底是由于其復雜性都是由不相干的細節組合而成，分析表是典型例子，它通過一種決議固定、簡單代碼段的形式，對編程語言的語法進行編碼，
有限狀態機特別適合這種處理形式，但是幾乎任何涉及到對構建資料驅動演算法有益的程式，都是將某些抽象資料型別的輸入“決議”成序列，序列會由一些獨立“動作”構成，
也許這種設計最有趣的地方是表結構有時可以由另一個程式生成（經典案例是決議生成器），
有個更接地氣的例子，假如作業系統是由一組表驅動，這組表包含連接 I/O 請求到相應設備驅動的操作，那么可以通程序式“配置“系統，該程式可以讀取到某些特殊設備與可疑機器連接的描述，并列印相應的表，
資料驅動程式在初學者中不常見的原因之一是由于 Pascal 的專制，Pascal 像它的創始人一樣，堅信代碼要和資料分開，
因而（至少在原始形式上）無法創建初始化的資料，與圖靈和馮諾依曼的理論背道而馳，這些理論可都是定義存盤計算機的基本原理，
代碼和資料是一樣的，或至少可以算是，還能怎樣解釋編譯器的作業原理呢？（函式式語言對 I/O 也有類似的問題）
08
函式指標
Pascal 專制的另一個結果是初學者不使用函式指標，（在 Pascal 中沒有把函式作為變數） 用函式指標來處理編碼復雜度會有一些令人感興趣的地方，
指標指向的程式有一定的復雜度，這些程式必須遵守一些標準協議，像要求一組都是相同呼叫的程式就是其中之一，除此之外，所要實作的只是完成業務，復雜度是分散的，
有個協議的主張是既然所有使用的功能相似，那么它們的行為也必須相似，這對簡單的檔案、測驗、程式擴展和甚至使程式通過網路分布都有幫助——遠程程序呼叫可以通過該協議進行編碼，
我認為面相物件編程的核心是清晰使用函式指標，規定好要對資料執行的一系列操作，以及對這些操作回應的整套資料型別，
將程式合攏到一起最簡單的方法是為每種型別使用一組函式指標，簡而言之，就是定義類和方法，當然，面向物件語言提供了更多更漂亮的語法、派生型別等等，但在概念上幾乎沒有提出額外的東西，
資料驅動程式與函式指標的結合，變成了一種表現令人驚訝的作業方法，根據我的經驗，這種方法經常會產生驚喜的結果，
即使沒有面向物件語言，無需額外的作業也可以獲得 90％ 的好處，并且能更好地管理結果，
我無法再推薦出更高標準的實作方式，我所有的程式都是由這種方式組織管理，而且經過多次開發后都相安無事——遠遠優于缺少約束的方法，
也許正如所說：從長遠來看，約束會帶來豐厚的回報，
09
包含檔案
簡單規則：包含（include）檔案時應該永遠不要嵌套包含，
如果宣告(在注釋或隱式宣告里)需要的檔案沒有優先包含進來，那么使用者（程式員）要決定包含哪些檔案，但要以簡單的方式處理，并采用避免多重包含的結構，多重包含是系統編程的禍根，
將檔案包含五次或更多次來編譯一個單獨的 C 源檔案的事情屢見不鮮，Unix 系統中 /usr/include/sys 就用了這么可怕的方式，
說到 #ifdef，有一個小插曲，雖然它能防止讀取兩次檔案，但實際上經常用錯，#ifdef 是定義在檔案本身中，而不是檔案包含它，結果是常常導致讓成千上萬不必要的代碼通過詞匯分析器，這是(優秀編譯器中)耗費最大的階段，
————
只需遵從以上簡單規則，就能讓你的代碼變得優雅而美觀，至少也是賞心悅目，從技術變成藝術~~
————————————
看到這里你是不是對“C語言”又有了一點新的認知呢~
如果你想當學C語言，小編推薦一個程式員編程學習基地【點擊進入】！
涉及到：C語言、C++、windows編程、網路編程、QT界面開發、Linux編程、游戲編程、黑客等等......
編程入門資料：
?推薦學習書籍：
一個活躍、高逼格、高層次的編程學習殿堂；編程入門只是順帶，思維的提高才有價值！
最后希望你也能成為自己心目中的完美物件~能成為自己心目中的完美物件~
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/186239.html
標籤：其他
上一篇：Gson-Expected a string but was BEGIN_ARRAY
下一篇：學習第59天