轉自：http://blog.csdn.net/fuyuwei2015/article/details/46552697

1）移除你沒有用到的東西（就像上面建議的一樣）。

2）簡化必要的概念，避免不必要的概念。

3）移除不必要的抽象，用實際的實現來替代。

4）移除不必要的虛擬化，并且簡化對象的結構。

5）如果一個設置曾經使用過，那么就避免在用另外的配置來運行這個模塊。

?

下面的都是廢話：

?

轉自：http://blog.csdn.net/yaomoon/article/details/23866657

?

要判斷一個程序員是不是好的程序員，主要看他寫的代碼，因為程序員最重要的事是寫代碼。

即便不去理解代碼的意圖，只要看一眼，好的程序員寫的代碼與差的程序員寫的代碼基本上就可以看出來。好的程序員寫的代碼，整潔而規范，視覺上自 然有一種美感。空白錯落有致，注釋恰到好處，命名和排版遵守統一的規范。差的程序員寫的代碼則經常出現過長的函數，前后不一致的命名方式和排版，過深的嵌 套結構，非常復雜的表達式，隨處可見的數字等毛病。 再去粗粗閱讀，對好的程序員還是差的程序員就會更有把握。好的程序員寫的代碼，有一種精心雕琢而成的一致性。好的程序員一致會遵守統一的命名方 式，如camelCase，而差的程序員的變量命名時不時的就會偏離統一規范。好的程序員的代碼中拼寫錯誤幾乎不可見，而差的程序員的拼寫錯誤要多得多。 好的程序員對于同一類動作，不會忽而用這個動詞，忽而又用那個同義詞，如add/insert混用。好的程序員采用一致的簡寫規則，差的程序員則時而不簡 寫，時而簡寫。好的程序員會很注意名稱中形容詞與名詞誰在前誰在后，而差的程序員沒有規則，時而在前時而在后。好的程序員很少會寫出大段大段的重復代碼， 差的程序員卻經常搞不定重復代碼，他們難以將重復的代碼抽取出一個統一的概念進行重用。好的程序員對于對外的API會注重注釋與代碼的一致性，差的程序員 經常注釋中的參數名稱與函數定義都不一致。好的程序員很少會留下被注釋掉的或用#if 0括起的垃圾代碼，他們意志堅決，代碼有用就要，沒用就不要，差的程序員則不一樣，他們經常不確信一段代碼是否真的需要，他們缺乏保持代碼整潔的習慣，因 此他們讓垃圾代碼留著。 如上，即便你不懂他所用的語言，不卻關心程序的邏輯，對好的程序員還是差的程序員就能做到八九不離十的判斷。程序的好壞幾乎總是取決于它們是否 “漂亮”，不“漂亮”而好的程序，除了C++ STL源碼，我再也沒見過(如果你稍仔細看，STL的源碼雖然不夠“漂亮”，但仍然滿足這里提出的一致性原則)。而又好又“漂亮”的代碼則隨處可見，如 Linux Kernel，InnoDB，JDK，JUnit等等。 如果再仔細閱讀，就能更準確。好的程序員寫的代碼，好似渾然天成，簡單而直白。函數通常較短小，函數的名稱準確的反映函數要完成的工作。邏輯簡 單而自然，讓你讀的時候由衷的發出“啊，就應該是這樣”的感嘆，而差的程序員的代碼經常讓你發出“怎么是這樣?這是再干什么呀?”的疑問。好的程序員會在 緊要關頭加以畫龍點睛般的注釋，差的程序員要么沒注釋，要么注釋只是代碼的重復，純粹是廢話，更差的是注釋是錯的，是誤導。 好的程序員未必是“語言律師”，即那種非常清楚的了解語言的各個細節，在編程時到處使用的家伙。好的程序員也不常“炫技”，在代碼中精心構造一些獨具匠心的片斷，他們偶而會，但大多數時候總是用直白的語言來表述。 從代碼也可以看出一個程序員的團隊協作精神。注意團隊合作的程序員，會嚴格按照團隊規范寫代碼，而風格與團隊規范不一致的程序員則很可能欠缺團 隊精神。注意團隊合作的程序員會注意給模塊的對外接口加以重要的說明，如前置條件、后置條件、參數能否是NULL等等，不注意團隊合作的程序員懶于處理這 些細節。 好的程序員與差的程序員的生產力差別巨大，項目的周期越長，項目越復雜，項目對質量的要求越高，好的程序員的價值就越大。好的程序員與差的程序 員，管理成本也差別巨大，好的程序員只需要與他共同確定設計，代碼可以不看，差的程序員的代碼經常需要經過多次review，且仍有可能達不到理想的質 量。 要成為好的程序員，首先要樹立要成為好的程序員的志向，再勤加練習，天長日久，就會越來越好，這些人不怕老。沒有志向永遠成不了好的程序員，這些人若不在老去之前成為經理就會變成廢人。 通過兩個小時的筆試和半個小時的面試對于判斷程序員來說是不夠的。通過筆試與面試，你可以判斷一個程序員是否具備算法與數據結構等基礎知識，可以判斷他對編程語言的特性是否掌握，可以判斷他對技術是否關注，然而要知道他能否真的能很好的完成工作，不寫代碼是不夠的。 那些顯得對技術充滿熱情的，未必是好的程序員。這些人可能非常樂意從事有新意的工作，但后續的編碼、測試、調試、文案工作則可能讓他們感到厭煩。他們可能會提出好的創意，但卻經常不能夠有始有終的將其完成。公司不需要多少這樣的人。 因此招聘的方式需要改善。招聘是最重要的，因為進來后就難以出去，即便是試用。轉正條件白紙黑字寫的很清楚，只要合格就可以轉正，要達到合格并不是很困難。今年部門里進了很多新人，并不是人人都很優秀，但確實也都合格，自然也應該轉正。 改善招聘的方法，就是讓他寫程序，可以出兩道題，一道讓他寫程序，一道讓他重構一個已有的較長的程序，一天之內完成。假使可以考他半個月，那么 重構是不太需要的，但一天的時間太短，通過重構可以考察閱讀并理解代碼，并通過重構“化腐朽為神奇”的能力。那些不愿意寫別人的代碼，不愿意接受別人的代 碼，經常要重來一遍的人是不理想的。

轉載于:https://www.cnblogs.com/lyggqm/p/6477338.html

總結

以上是生活随笔為你收集整理的写出漂亮的代码的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。