導言：這個題目很大，以我的水平、經驗或哪個方面都是寫不了的，就像 Eric S. Raymond 如果不是對 UNIX 世界的典故了如指掌的話也寫不出現在的《UNIX 編程藝術》。用這個標題是因為 @vczh 對這話題有興趣（請看靠譜的代碼和DRY），這里僅是拋個磚，也算是這幾年寫 AutoHotkey 代碼的一點心得。
怎樣算好代碼
如何衡量一種代碼好的還是不好，我的看法是看它的價值，不過對價值的理解也因人而異。
寫代碼是為了解決問題，所以代碼首先必須能解決問題，這是它的第一價值。它的后續價值是能否方便地重用。例如，現在要解決某個問題，我花了差不多的時間寫了兩段代碼，它們都很好的解決了這個問題，那么能否重用就是它們價值的差異所在了。重用能提升代碼的價值，重用越多價值越大化（反過來看，解決同類問題花的單位時間就少了）。
方便重用的代碼一般具有下面三個特點：
- 易理解
- 可擴展
- 易維護
不論是自己以后的使用，還是分享給別人，理解都應放在第一位，只有在理解的基礎上才可能去擴展和維護。
如何才方便重用
這三個特點如果從風格上描述，可概括為：
邏輯清晰
很多人有過這樣的經驗，小學初中寫作文沒有思路的時候，寫的搜腸刮肚、涂涂改改，字數齊了居然自己都看不懂寫了什么。
初學編程的人可能會被要求畫流程圖，對于寫小腳本一般無需那么嚴謹，不過思路一定要清晰，即要解決這個問題采用這種方法時第一步應如何，第二步如何，哪里要跳轉，哪里要返回，如果整個流程了然于胸要寫出來就不難了。一般而言，主腳本（多腳本時）或主線程的執行流即為主要流程，其他腳本或線程為實現某個模塊或某種功能，這樣只看完主腳本或主線程后即能明白實現的思路了。結構良好
結構一般屬于個人風格，包含很多細節，如變量命名、區塊風格（大括號）、縮進、注釋等。多數人認為書寫風格完全是個人的事情，實際并不盡然。結構好的代碼看起來賞心悅目，我們很容易理解和使用。
在官網論壇上，我們可以看到很多函數，它們一般都有個共同點：在函數頂部包含其功能說明和參數及返回值的含義，很可惜在中文論壇中大多沒有，以致很多變成一次性的死代碼（即分享后響應的人很少基本沒人用，甚至自己以后想使用都看不懂）。
考慮協作的問題
上面所說的主要針對個人書寫腳本，并沒有提到協作。實際中，只要不是打算寫好問題解決就扔的腳本，多少都要考慮到協作。
可能有人說，我的代碼沒打算讓別人用，不需要協作。我個人感覺，如果從廣義上看，和他人協作是一種協作，將來的自己和現在的自己協作也是一種。許多時候，我們自己寫的代碼，一段時間后，想要擴展發現困難重重，這雖有可能之前沒有設計好或在寫的過程中思路發生了變化。很多人此時就想推倒重來（重構代碼），重構的精力暫且不談，然而既然當初的想法后面發生變化，我們如何知道現在的想法以后不發生變化呢？
一而再再而三的重構就明白這種過程的痛苦了，所以更好的方法是預防，從功能上分解并模塊化，例如一個腳本或函數實現一個功能。在以后整體思路確定而某功能細節的實現改變時，框架不動而只替換模塊。當然，偶爾還是需要重構的，不過次數大大減少了。
小結
片面追求最精簡、最優化或最高效的代碼是個誤區，如果注意觀察我們會發現我們使用別人的代碼時用的最多的是邏輯清晰、結構良好的代碼，而不是那些標新立異、看起來高深莫測的代碼（當然炫耀除外）。
上面談到了，多分享也能提升代碼的價值，所以看到好的代碼時要不吝分享哈！
本文通篇都在說代碼，但從沒出現過代碼，因此補充，有興趣的朋友請看看視頻網站瞬間提速，對比文中和評論中兩段代碼的得失之處。
