改良程序的11個技巧

有不少理由都能說明爲何咱們應該寫出清晰、可讀性好的程序。最重要的一點，程序你只寫一次，但之後會無數次的閱讀。當你次日回頭來看你的代碼時，你就要開始閱讀它了。當你把代碼拿給其餘人看時，他必須閱讀你的代碼。所以，在編寫時多花一點時間，你會在閱讀它時節省大量的時間。

讓咱們看一些基本的編程技巧：

     1.儘可能保持方法簡短

     2.永遠永遠不要把同一個變量用於多個不一樣的目的

     3.使用自描述的變量名和方法名

     4.儘量的把變量定義在靠近使用它的地方

     5.拒絕神祕數字

     6.友好的對待你的語言

     7.不要逆常規而行

     8.警戒過早優化

     9.積極重構測試過的程序

   10.不要過分沉迷於技巧

   11.經過習例學習新知

 

如今，讓咱們把每一個小點展開來詳細講一下。

 1 儘可能保持方法簡短

儘管不少人都遵循這個規則，但它仍然很是的重要。你寫的方法要始終能在一個屏幕裏放得下。若是你須要去滾動屏幕，這會分散你的注意力，並且你看不到整個的上下文。最佳長度是5-20行，這根據你的狀況而定。固然，getters/setters 一般是一行代碼的方法，但與其說它們是真正的方法，不如說它們只是存取工具。

 2永遠永遠不要把同一個變量用於多個不一樣的目的

一個變量應該始終只爲一個目的服務。經過使變量常量化(C++裏的const， Java裏的final)，使得編譯器可以優化編譯，並且使你的代碼醒目表達這個變量是不能改變的，你的程序的可讀性會變得更好。

 3 使用自描述的變量名和方法名

你的代碼應該，對於任何人來講，只要看一眼就能知道是幹嗎的。儘可能不要用簡寫方式，除非有特殊的習慣，就像下面的：

src - source
 pos - position
 prev - previous

若是你認爲描述性的名稱並非那麼有價值，請對比一下n, ns, nsisd 和numTeamMembers, seatCount, numSeatsInStadium。

 4儘量的把變量定義在靠近使用它的地方

蓋房子時，你可不但願把錘子放到別人的院子裏。你但願把它們放的離手頭越近越好。定義變量也是一樣的道理。

int foo = 3;
int bar = 5;
// 一大段使用「bar」的代碼，
// 但沒用到「foo」
// ...

baz(foo);

這段代碼能夠簡單的重構成

int bar = 5;
// 一大段使用「bar」的代碼，
// 但沒用到「foo」
// ...

int foo = 3;
baz(foo);

當你把變量的聲明和第一次用到它的地方間隔太遠時(距離超過一個屏幕)，這確實會成爲一個問題。記住上下文關係會變得困難，你須要滾動屏幕去找哪來的這個變量。

 5拒絕神祕數字

當你要把什麼東西跟一個常量值作比較時，記得把這個值定義成常量。沒有什麼會比去猜想你的同事寫的這樣的代碼更讓人頭疼的事了：

il < 4384

換個形式感受如何？

inputLength < MAX_INPUT_LENGTH

 6友好的對待你的語言

學習新語言是一種頗有樂趣的事情，你能學到一種新的完成任務的途徑。當一個對一種語言已經很專業的人去學習另外一種語言時，會出現一種很大的負面效應。好比說你是一個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!" }

 7不要逆常規而行

每種語言都有本身不一樣的習俗約定。通常來講，人們聽的最多的是Java的編碼規範。讓咱們看看其中的一些習俗規範：

• 方法名應該小寫字母開頭，其後用字母大寫的單詞鏈接(veryLongVariableName)

• 類名應該都使用首字母大寫的單詞鏈接而成

• 常量名應該所有大寫，用下劃線鏈接(MY_CONSTANT)

• 左大括號應該跟 if 語句在同一行

只有在有必要的理由時纔去打破這些常規，不要輕易的由於你不高興就違反它。若是你只是在團隊裏改變一些這樣的習慣，那也沒問題，但當把你代碼拿出來和其餘的沒有這些思想準備的程序員共享時，問題就會來了。

 8 警戒過早優化

過早優化是全部問題的根源，至少電視上是這麼說的 … 你第一應該關心的事情是寫出易於理解的代碼。起初寫的程序不要求快。除非你的程序很慢，不然談優化都是爲時太早。若是你想優化什麼東西，你首先須要知道問題出在哪。這就是咱們須要profilers這個工具的緣由。

在沒有知道問題在哪的狀況下試圖對程序進行優化，其結果必然是把程序能壞，至少你的代碼會喪失可讀性。若是你以爲有些地方很慢，不要盲目的重寫代碼，你應先找到慢的證據。

不要傻乎乎的去解決根本不存在的問題。

9 積極重構測試過的程序

沒有任何東西會是完美的。即便你感受你真正寫出了一段完美的代碼，幾個月後回頭再看看，你可能會驚訝道」怎麼會這樣傻？「

改進程序的一個好方法就是重構，但要等程序測試經過以後。你首先要確保程序是好的可運行的，你能夠經過自動化測試或手工測試完成這個工做。

之初，你須要的是程序可用。不要指望在第一次就寫出完美的程序，你只須要把它寫出來，可用。而後重構它，使之完美。對於大家當中知道測試驅動開發(TDD)的人來講，對這個會很熟悉。這裏的關鍵就在於你要習慣於重構這種事情。若是你使用的是像IntelliJ IDEA這樣強大的集成開發工具的話，重構的工做會變得簡單的多。

重構以後，你也許會弄出一些Bug，致使某些功能出問題。這就是爲何說寫自動化測試的緣由。不論什麼時候重構後，只要運行一下全部的測試用例，你就能準確的知道什麼地方出了問題。

 10 不要過分沉迷於技巧

當我第一次讀到有關設計模式的知識時，我以爲我找到了聖盃。這些精心設計的思想做用顯著，它能使你的設計易於理解，由於你能夠簡單的說」我使用的是‘觀察器模式’「，而不用從頭至尾的解釋一遍。那麼，有問題嗎？一切看起來都這麼天然、簡單，你開始不論在哪都使用設計模式。爲何不把這個類作成singleton呢？幹嗎不去再建立一些工廠類呢？

因而一個80行就能寫完的腳本，你最終使用了10個類，15個接口，外加一大堆範式和標記符。97%的代碼不作任何事情。設計模式是一種十分有用的用來簡化你的設計的工具，但這不意味着你該在全部能用到的地方都用它。你應該用它們，但不能濫用。

 11 經過習例學習新知

編程是一種學習新知的過程。當你學到了新的程序庫或新語言，你可能會火燒眉毛的丟掉舊的代碼，用你新學到的東西從新寫一遍。有不少的理由都能說明你不應這麼作。

往現有的應用裏增長新的類庫或框架同屬於這種狀況。就說你寫了一個Javascript的web應用，期間，你發現了jQuery。如今你忽然急切的想丟到你的Javascript程序，從新用jQuery寫，儘管你還歷來沒用過它。

最好的方式是你先用jQuery寫一些簡單的例子，經過這種方式把你在應用裏將要用到的知識都學會。須要AJAX？在你的項目以外作一些小例子，當徹底弄懂了後，丟掉例子，應用到你的產品裏。

若是你很是關注編程技術，我強烈的推薦你閱讀Steve McConnell寫的《代碼大全》 一書。它會永遠的改變你對編程的認識。

轉：極分享