大約一年前，我曾編寫過一些PHP Web編程守則——MicroPHP Manifesto。但我發現各個語言之間有一些共同的編程/編碼規則，這或許是我在熟悉各種類型的編程語言後的一些收獲吧。
下面是我總結出來的一些規則，並且在實際中應該牢記於心。
學習語言而不是框架
我喜歡PHP、Python和JavaScript，喜歡用他們做些東西。但我卻不是Symfony、Django、jQuery開發人員。
我認為這有很大的區別。一個人很有可能成為一名jQuery程序員而非JavaScript，也有可能成為Django程序員而不是Python。在實際應用中，的確存在許多有價值且非常實用的工具和框架，但如果我僅知道如何使用一個框架，我想表達的觀點是在工作上只使用合適的工具其實會給任務帶來一些限制，你可以查看一下，看看你用的工具，看看你用的框架。以我的經驗來看，一些復雜的全棧（full-stack）框架並不是非常合適的工具，尤其在靈活性和性能方面都不是太好。
集中精力學習一門語言會讓程序員變的更加靈活。全棧式復雜框架可以幫助我快速的構建某個產品，但當我需要一個不屬於框架范圍內的解決方案時，它反而會變成一種傷害。我經常會采用“plug和pray”方法進行開發，當我發現某個庫或插件可以滿足需求時，我就會把它們應用到產品裡。這樣可能會使應用程序快速推出，但在以後的道路上會留下很多障礙。
此外，學習全棧框架和學習新語言一樣復雜。它們通常都有復雜的體系結構和術語，並且有些部分並不適用於其他框架和工具上。當然框架也有許多好處，但前提是你必須要懂這門語言，然後才能理解其真正的工作原理，所以我寧願花時間學習更多關於語言本身的東西，並且把所學的技能應用到其他語言或者庫上。
構建小模塊
有些小型的單元代碼是很好很討程序員們喜歡的，因為越小越容易理解且很難把它弄的很糟，所以限制編寫冗長復雜的代碼是非常重要的。
所以有目的的構建一些小模塊——盡可能的接近需求目標。它們應該是獨立的塊，單純地解決某方面問題，但是把它們結合起來時，就可以解決許多大型的、復雜的問題。
像這些簡單的模塊代碼修復起bug來也會非常容易。因為這些單獨的塊通俗易懂，一看就會知道其用途。如果模塊是自我包含的，那麼測試起來會更加簡單。
代碼越少越好
套用Biggie Smalls的一句話：“代碼越多，問題也就越多”。
誰都喜歡管理少的代碼。估計大家都有過這樣的體會，當審查一個功能模塊的代碼時，如果代碼很多很亂，第一印象肯定不好，相反，如果該模塊代碼簡潔明了，你會非常愉悅。更通俗點講就是代碼越多，管理起來也就越困難：搜索代碼庫的時間會變長、查看文件導航也需要較長的時間、跟蹤執行也會變的困難等。
你是否發現，代碼審查、還有你使用的工具，很大程度上都是用來減少代碼量的。那些龐大的庫和長代碼似乎會溢出人們的大腦緩沖區。當我在追蹤一段較長的源碼或執行跳躍好幾個源文件的功能時，我會感到很苦惱。這就是為什麼我會喜歡給語法進行著色的編輯器，並且保持一致的空格對我也非常有幫助。
除了喜歡管理較少的代碼外，我還支持開發者們盡量簡化代碼。程序員要為應用程序所使用的代碼，不僅僅是自己編寫的部分負責——甚至是這些應用裡的每行代碼。這也就意味著要替這些應用裡出現的bug或者安全漏洞負責。
你會在程序中使用自己不理解的代碼嗎？這並不表示我從不使用他人的代碼——坦白說，世上有許多優秀的程序員，但是在應用他人代碼的時候，你必須理解代碼，因為應用程序裡的每行代碼都很重要。在編碼時千萬不要忘記思考，編寫最少代碼的背後應該是多思考，這樣就不會給自己帶來不必要的麻煩。
編寫簡單、有用可讀的代碼
編寫容易理解的代碼，少編碼多思考，這樣完成一個功能就會很快，生產力就會得到提高。
當然，我也希望代碼是可驗證的。並且我一直認為簡單、模塊化的代碼是更容易被測試。
代碼應具備的另一特征就是可讀。代碼應簡潔明了，語義清楚。在編寫代碼時，我會思考其他程序員在第一眼看到它的時候會花多長時間來理解。或者一兩個月後我自己能一目了然嗎？正如大家熟知的那句編程諺語：任何一個傻瓜都會寫出能夠讓機器理解的代碼，只有好的程序員才能寫出人類可以理解的代碼。當我試圖發現它們工作原理的時間越少，做的事情就會越多。
但是很少有人能堅持這些規則，如果我說是，那麼我肯定是在撒謊。有時候我也會很懶惰，甚至由於時間限制，我會編寫一些復雜的、難以理解的代碼或者使用沒有審查的庫來實現某個功能。想要在短期內編寫簡單、清晰的代碼會很困難——它需要更多的紀律和不斷的技術評估。特別是那種對時間敏感的項目，實行起來將會更難。
但是，當你花時間和精力去做的時候，你會發現功夫不負有心人——不僅僅對自己有幫助，還會給其他團隊成員帶來很多益處。
來自：More Code, More Problems
