程序你只寫一次，但以后會(huì)被很多人無數(shù)次的閱讀。這也是我們應(yīng)該寫出條理清晰、可讀性好的程序的最重要的理由。當(dāng)你第二天回頭來看你的代碼時(shí)，你就要開始閱讀它了。當(dāng)你把代碼拿給其他人看時(shí)，他必須弄清楚你的代碼。因此，在編寫時(shí)多花一點(diǎn)時(shí)間，在閱讀它時(shí)就會(huì)節(jié)省大量的時(shí)間。

 

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

 

   1. 盡量保持方法簡短

 

盡管很多人都遵循這個(gè)規(guī)則，但它仍然非常的重要。你寫的方法要始終能在一個(gè)屏幕里放得下。如果你需要去滾動(dòng)屏幕，這會(huì)分散你的注意力，而且你看不到整個(gè)的上下文。最佳長度是5-20行，這根據(jù)你的情況而定。當(dāng)然，getters/setters 通常是一行代碼的方法，但與其說它們是真正的方法，不如說它們只是存取工具。

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

 

你的代碼應(yīng)該，對(duì)于任何人來說，只要看一眼就能知道是干嘛的。盡量不要用簡寫方式，除非有特殊的習(xí)慣，就像下面的：

src - source

 pos - position

 prev - previous

 

如果你認(rèn)為描述性的名稱并不是那么有價(jià)值，請對(duì)比一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium。

3. 盡可能的把變量定義在靠近使用它的地方

 

蓋房子時(shí)，你可不希望把錘子放到別人的院子里。你希望把它們放的離手頭越近越好。定義變量也是同樣的道理。

int foo = 3;

int bar = 5;

// 一大段使用“bar”的代碼，

// 但沒用到“foo”

// ...

 

baz(foo);

 

這段代碼可以簡單的重構(gòu)成

 

int bar = 5;

// 一大段使用“bar”的代碼，

// 但沒用到“foo”

// ...

 

int foo = 3;

baz(foo);

 

當(dāng)你把變量的聲明和第一次用到它的地方間隔太遠(yuǎn)時(shí)(距離超過一個(gè)屏幕)，這確實(shí)會(huì)成為一個(gè)問題。記住上下文關(guān)系會(huì)變得困難，你需要滾動(dòng)屏幕去找哪來的這個(gè)變量。

4. 永遠(yuǎn)永遠(yuǎn)不要把同一個(gè)變量用于多個(gè)不同的目的

 

一個(gè)變量應(yīng)該始終只為一個(gè)目的服務(wù)。通過使變量常量化(C++里的const， Java里的final)，使得編譯器能夠優(yōu)化編譯，而且使你的代碼醒目表達(dá)這個(gè)變量是不能改變的，你的程序的可讀性會(huì)變得更好。

5. 拒絕神秘?cái)?shù)字

 

當(dāng)你要把什么東西跟一個(gè)常量值做比較時(shí)，記得把這個(gè)值定義成常量。沒有什么會(huì)比去猜測你的同事寫的這樣的代碼更讓人頭疼的事了：

 

il < 4384

 

換個(gè)形式感覺如何？

 

inputLength < MAX_INPUT_LENGTH

6. 不要逆常規(guī)而行

 

每種語言都有自己不同的習(xí)俗約定。一般來說，人們聽的最多的是Java的編碼規(guī)范。讓我們看看其中的一些習(xí)俗規(guī)范：

 

    方法名應(yīng)該小寫字母開頭，其后用字母大寫的單詞連接(veryLongVariableName)

    類名應(yīng)該都使用首字母大寫的單詞連接而成

    常量名應(yīng)該全部大寫，用下劃線連接(MY_CONSTANT)

    左大括號(hào)應(yīng)該跟if語句在同一行

 

只有在有必要的理由時(shí)才去打破這些常規(guī)，不要輕易的因?yàn)槟悴桓吲d就違反它。如果你只是在團(tuán)隊(duì)里改變一些這樣的習(xí)慣，那也沒問題，但當(dāng)把你代碼拿出來和其他的沒有這些思想準(zhǔn)備的程序員共享時(shí)，問題就會(huì)來了。

7. 警惕過早優(yōu)化

 

過早優(yōu)化是所有問題的根源，至少電視上是這么說的 … 你第一應(yīng)該關(guān)心的事情是寫出易于理解的代碼。起初寫的程序不要求快。除非你的程序很慢，否則談優(yōu)化都是為時(shí)太早。如果你想優(yōu)化什么東西，你首先需要知道問題出在哪。這就是我們需要profilers這個(gè)工具的原因。

 

在沒有知道問題在哪的情況下試圖對(duì)程序進(jìn)行優(yōu)化，其結(jié)果必然是把程序能壞，至少你的代碼會(huì)喪失可讀性。如果你覺得有些地方很慢，不要盲目的重寫代碼，你應(yīng)先找到慢的證據(jù)。

 

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

 

8. 友好的對(duì)待你的語言

 

學(xué)習(xí)新語言是一種很有樂趣的事情，你能學(xué)到一種新的完成任務(wù)的途徑。當(dāng)一個(gè)對(duì)