本文是html5tricks原創翻譯，轉載請看清文末的轉載要求，謝謝合做！html
做爲一個合格的程序員，有太多的理由促使你去編寫乾淨利落且可讀性強的代碼。最重要的是由於你編寫的代碼，未來會有不少人一次次地閱讀。當你有一天回過頭來看本身的代碼時，你就會明白編寫優雅的代碼是多麼的重要。另外，若是別人來閱讀你編寫的代碼，你是否想知作別人看到那些爛代碼無比抓狂的感覺。所以，花多一點的時間去編寫優雅的代碼，未來說不定會給你節省更多的時間。html5
那麼，如何編寫更棒的代碼，下面是11條基本規則：程序員
下面咱們來對每一點詳細展開介紹。web
儘管不少人都遵循這條規則，可是它依然很重要。總的來講，編寫的方法最好能在首屏徹底顯示。試想，若是你須要滾動頁面才能看到整一個方法，那是一件多麼分散注意力的事情。一個方法最好能保持在5 – 20行之間，固然，你也要視具體狀況而定，並非一律而論的。對於getter和setter方法，一般只需一行代碼，因此它們看起來更像是類成員的存取訪問器。編程
一個變量應該只能被用於一個目的，咱們能夠經過使用常量（C++中用const標識，Java中用final標識），幫助編譯器優化代碼編譯，也能夠向程序標識「這個變量是不能被改變的」，這樣咱們編寫的代碼就有更好的可讀性。設計模式
一段通俗易懂的程序代碼，應該是任何人只要看了代碼，就能明白程序是用來幹嗎的。因此我建議你們儘可能少用縮寫，除非是程序界公認的簡寫習慣，像下面的簡寫習慣：框架
src - source pos - position prev - previous
若是你以爲描述性的簡寫方式沒有價值，你能夠比較一下n, ns, nsisd和numTeamMembers, seatCount, numSeatsInStadium編程語言
當你在蓋房子的時候，總不但願把錘子放在別人家的院子裏吧，相反，你會把蓋房的工具放得儘量近，定義變量也是一樣的道理。ide
int foo = 3; int bar = 5; // bunch of code that uses "bar" // but doesn't care about "foo" // ... baz(foo);
咱們能夠這樣重構代碼：工具
int bar = 5; // bunch of code that use "bar" // but doesn't care about "foo" // ... int foo = 3; baz(foo);
當你把變量的聲明跟使用它的地方相隔太遠的時候（甚至是超過一屏），那的確會給你帶來很大的麻煩。你會常常滾動頁面去尋找這個變量，致使你很難在大腦中保持代碼之間的連貫性。
任什麼時候候，你要比較一些常量時，都要將它們定義成constant類型。團隊之間調試代碼時最讓人頭疼是出現下面的代碼：
il < 4384
把它替換成下面的代碼該多好：
inputLength < MAX_INPUT_LENGTH
學習一種新的編程語言是一件頗有趣的事情，你將學會用新的很酷的方式解決問題。若是讓一個對某種語言很專業的人去學另一種語言，不少時候會讓人愛莫能助。舉個例子，讓一個Java開發者試圖去學Ruby，你就應該要學會用Ruby的方式去解決問題，而不是繼續沿用Java的解決問題的思想。
當你須要循環輸出5遍」Hello World「時，Java代碼應該會是這樣：
for (int i = 0; i < 5; i++) {
System.out.println("Hello world!");
}
可是用Ruby，你也許會這樣寫：
for i in (0..5) puts "Hello world!" end
這些看上去都很不錯，可是最完美的方式多是下面這樣：
5.times { puts "Hello world!" }
每一種編程語言都有本身的約束習慣，總的來講，你們對Java的編程習慣可能會了解得比較多，咱們一塊兒來看看其中的一些習慣：
只有在無可奈何的時候才能打破這種規則，千萬不要由於不喜歡這種作法而違背已經約定好的編碼習俗。若是你身爲團隊一員，想改變一些編碼規則的話，那也能夠，不過當你把本身的代碼分享給沒有你這種習慣的隊友的時候，棘手的問題會迎面而來。
過早的優化是全部問題的根源，至少電視上是這麼說的…你的首要任務是編寫容易理解的代碼，而不要求你能很快寫出來。除非你的程序運行很慢，不然談優化都是爲時太早。若是你想優化你的程序，那麼得先找出程序的問題，這就是咱們須要profilers這個工具的緣由。
在沒有找到問題源頭就去優化代碼，這樣作你所要付出的代價就是破壞了程序的結構，至少會喪失程序的可讀性。若是你發現程序運行緩慢了，也不要盲目地重構代碼，要先找到致使運行慢的根本緣由。
千萬不要傻乎乎地去解決根本不存在的問題。
世上沒有絕對完美的事情。儘管你認爲本身的代碼已經寫得很是完美了，過一段時間也要常常去看看它，也許那時你會對本身大罵：」怎麼會那麼傻！」
有一種提升代碼質量的方法，那就是常常重構經過測試的代碼。所謂經過測試，我指的是程序要能正常工做，你能夠經過自動化測試或者手動測試來確保這一點。
首先你要確保程序可以正常運行，第一次咱們並不須要寫出多麼完美的程序，能用就行，接下來咱們能夠慢慢重構，讓它逐漸變得完美。這種開發方式頗有TDD的味道，關鍵在於你須要熟悉重構的每個環節。若是你熟練使用一些高級的IDE，像IntelliJ IDEA，那你的重構工做將會簡單不少。
重構完之後，也許你會碰到不少這樣那樣的問題，甚至會破壞正常的程序，這就是咱們要利用自動化測試的緣由了。當你重構完之後，跑一遍單元測試就能避免這些使人頭疼的問題了。
當我第一次接觸到設計模式這一律念時，我以爲本身找到了「聖盃」。這些精妙的設計思想可讓你工做更加順利，也可讓你的設計淺顯易懂，由於你能夠簡單的說「我使用了觀察者模式」，而不一樣大費周章的解釋一通。然而問題來了，因爲有些問題看起來太天然太簡單了，你會把那些設計模式的思想應用到任何地方，爲何不把這個類設計成單例模式（singleton）？幹嗎不去建立一些工廠類呢？
因而用80行代碼就能完成的腳本，結果你用了10個類，15個接口和一堆泛型和註釋，這其中的97%代碼並無作實質上的事情。設計模式雖然很是有用，能夠幫助你簡化設計，可是這並非說你能夠處處使用它們。你可使用設計模式，可是不能將它濫用了。
編程就是一項學習新知識的工做，當你學到了新的類庫或者編程語言時，你會火燒眉毛地丟掉老的代碼，進而去重寫它們。然而有不少理由說明你不應這麼作。
將一個新的類庫或者框架應用到現有的項目中就會出現相似的問題。好比說你正在爲一個Web項目寫Javascript，可是中間你發現了jQuery，這時候你會火燒眉毛想把jQuery應用進去，而丟掉原來的Javascript代碼，即使你根本沒用jQuery寫過任何項目。
最好的方式是你先用jQuery學着寫一些簡單的例子，把你項目中要用到的技術都學會。好比說你想要用AJAX？就先在項目以外寫一些關於AJAX的簡單例子，等到徹底掌握了，就能夠將老代碼從項目中移除。
若是你熱衷於編程，我強烈推薦你閱讀Steve McConnell編寫的《Code Complete》，它將永遠改變你的編程思惟。
譯文連接：http://www.html5tricks.com/11-tips-to-coding-better.html
英文原文：11 tips for better code
翻譯做者：蔣麗麗
[ 轉載必須在正文中標註並保留原文連接、譯文連接和譯者等信息。]