作爲一個合格的程序員,有太多的理由促使你去編寫乾淨利落且可讀性強的代碼。最重要的是因爲你編寫的代碼,將來會有很多人一次次地閱讀。當你有一天回過頭來看自己的代碼時,你就會明白編寫優雅的代碼是多麼的重要。另外,如果別人來閱讀你編寫的代碼,你是否想知道別人看到那些爛代碼無比抓狂的感受。因此,花多一點的時間去編寫優雅的代碼,將來說不定會給你節省更多的時間。
那麼,如何編寫更棒的代碼,下面是11條基本規則:
-
1、保持方法簡短扼要
-
2、永遠永遠不要將同一個變量用於不同的目的
-
3、儘可能讓變量和方法的名稱能夠描述要實現的功能
-
4、儘可能將變量定義在最靠近它們的地方
-
5、不要出現讓人費解的數字
-
6、要像對待朋友一樣對待你擅長的語言
-
7、不要逆常規而行
-
8、千萬小心過早的優化代碼
-
9、要常常重構經過測試的代碼
-
10、不要沉溺於過度的設計技巧
-
11、隨時隨地學習新的知識
下面我們來對每一點詳細展開介紹。
1、保持方法簡短扼要
儘管很多人都遵循這條規則,但是它依然很重要。總的來說,編寫的方法最好能在首屏完全顯示。試想,如果你需要滾動頁面才能看到整一個方法,那是一件多麼分散注意力的事情。一個方法最好能保持在5 – 20行之間,當然,你也要視具體情況而定,並不是一概而論的。對於getter和setter方法,通常只需一行代碼,所以它們看起來更像是類成員的存取訪問器。
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; // 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);
當你把變量的聲明跟使用它的地方相隔太遠的時候(甚至是超過一屏),那的確會給你帶來很大的麻煩。你會經常滾動頁面去尋找這個變量,導致你很難在大腦中保持代碼之間的連貫性。
5、不要出現讓人費解的數字
任何時候,你要比較一些常量時,都要將它們定義成constant類型。團隊之間調試代碼時最讓人頭疼是出現下面的代碼:
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的味道,關鍵在於你需要熟悉重構的每一個環節。如果你熟練使用一些高級的IDE,像IntelliJ IDEA,那你的重構工作將會簡單很多。
重構完以後,也許你會碰到很多這樣那樣的問題,甚至會破壞正常的程序,這就是我們要利用自動化測試的原因了。當你重構完以後,跑一遍單元測試就能避免這些令人頭疼的問題了。
10、不要沉溺於過度的設計技巧
當我第一次接觸到設計模式這一概念時,我覺得自己找到了“聖盃”。這些精妙的設計思想可以讓你工作更加順利,也可以讓你的設計淺顯易懂,因爲你可以簡單的說“我使用了觀察者模式”,而不同大費周章的解釋一通。然而問題來了,由於有些問題看起來太自然太簡單了,你會把那些設計模式的思想應用到任何地方,爲什麼不把這個類設計成單例模式(singleton)?幹嘛不去創建一些工廠類呢?
於是用80行代碼就能完成的腳本,結果你用了10個類,15個接口和一堆泛型和註釋,這其中的97%代碼並沒有做實質上的事情。設計模式雖然非常有用,可以幫助你簡化設計,但是這並不是說你可以到處使用它們。你可以使用設計模式,但是不能將它濫用了。
11、隨時隨地學習新的知識
編程就是一項隨時學習新事物的工作,當你學到了新的類庫或者編程語言時,你會迫不及待地丟掉老的代碼,進而去重寫它們。然而有很多理由說明你不該這麼做。
將一個新的類庫或者框架應用到現有的項目中就會出現類似的問題。比如說你正在爲一個Web項目寫Javascript,但是中間你發現了jQuery,這時候你會迫不及待想把jQuery應用進去,而丟掉原來的Javascript代碼,即便你根本沒用jQuery寫過任何項目。
最好的方式是你先用jQuery學着寫一些簡單的例子,把你項目中要用到的技術都學會。比如說你想要用AJAX?就先在項目之外寫一些關於AJAX的簡單例子,等到完全掌握了,就可以將老代碼從項目中移除。
如果你熱衷於編程,我強烈推薦你閱讀Steve McConnell編寫的《Code Complete》,它將永遠改變你的編程思維。