代碼規範，是一個老生常談的問題了，網絡上也有大量關于規範的文章。本文希望抛開規範的條條框框，從根本上談一下如何寫出自然的漂亮的代碼。因為漂亮的代碼，就是規範的代碼。
那麼，怎樣才能寫出漂亮的代碼呢？竊以為，看着順眼，用着順手，追求完美，避免技巧。
看着順眼
這一點，與審美觀搭一點邊。作為一名理科生，不必去發揮想象力，隻要做到整齊劃一，層次、段落分明就行了。寫代碼的時候要随時注意，你的代碼看着順眼嗎？哪裡别扭就調整一下。對于規範中規定的哪裡該縮進，哪裡需要空行，一行寫多少個字母等等，都不用記住。你要做的僅僅是把你的代碼寫得看着順眼，整齊劃一，做到這點你就成功了。
舉一反三，一個檔案寫完之後，看一下函數清單，可以用source insight, eclipse等工具的函數清單。看看它們是否整齊劃一。
函數清單 檔案清單
有了自己的經驗見解之後，再回過頭來看規範，則會有一種豁然開朗的感覺。看規範，就相當于看畫家的精美畫作，也是對代碼審美觀的一個提高。
用着順手
這裡的順手，就不是寫的時候了，關鍵展現在用起來友善快捷。
先說目錄。所有檔案堆在一個目錄中，顯然會雜亂無章，想找檔案時也很麻煩。如果把它們按功能分到不同的目錄中，是不就清楚一些了呢？
再說函數名。函數名要展現其意義，這樣才能在調用時更快的找到它。給它加上子產品字首，則更容易與其它子產品的萬千函數區分。拿碼流管理來說，我們将其子產品名命名為mstream，然後所有相關的函數，都以mstream_開頭。當使用這裡邊的函數時，直接寫上mstream_，然後編輯器(比如eclipse)就會有提示，相關的函數一目了然，這就帶來了使用上的友善。反之，假設函數名為getparam，不說調用時不好查，重命名的風險也非常高。
寫到這裡忽然發現，從目錄到具體某一行代碼，更像是一個樹形結構。每一個函數，都是樹的葉結點，而目錄、檔案則是其枝幹。這棵樹長的越好看，用起來就越順手。
追求完美
兩行代碼的縮進看起來是一樣的，但用滑鼠選中一下，發現一行前邊是8個空格，一行是兩個Tab。
它們完美嗎？
No!
把它們改成一樣的吧。無論你喜歡的是空格還是tab。這沒什麼實際意義，但是，這代表了一種追求完美的苛刻态度。
當用svn送出修改的時候，當然是先對比與之前的修改有何差異了。如果新的代碼因為調試比原來多了一條空行，是否要送出呢？
不！
将它改回原來的樣子。因為，那會增加一份代碼的修改。以後如果比較代碼，你就要多花5秒鐘來檢查這個檔案的修改。
Cmake工具生成的makefile，在編譯時，是整齊的一行一個檔案的綠色。當有Warning發生時，就會因Warning提示打亂這份美麗。搞定這個warning吧。
檔案中，所有函數都叫mstream_xxx，忽然有一個成了mstreamSetParam。它破壞了完美，那就把它改成mstream_set_param吧。
避免技巧
技巧，意味着晦澀難懂，也就意味着風險。是以，如果不是特别關鍵的代碼，請把它寫得像白話文一樣直白。
如果，你在調試一段代碼時，被其中的邏輯繞的五迷三道，删了它重寫吧。如果你仍然堅持嘗試搞清邏輯，修正這代碼，60%的可能會引起新問題。90%的可能在不遠的将來會再冒出一個BUG來。