有很多理由都能說明為什么我們應該寫出清晰、可讀性好的程序。最重要的一點，程序你只寫一次，但以后會無數次的閱讀。當你第二天回頭來看你的代碼時，你就要開始閱讀它了。當你把代碼拿給其他人看時，他必須閱讀你的代碼。因此，在編寫時多花一點時間，你會在閱讀它時節省大量的時間。
讓我們看一些基本的編程技巧：
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.?盡可能的把變量定義在靠近使用它的地方
蓋房子時，你可不希望把錘子放到別人的院子里。你希望把它們放的離手頭越近越好。定義變量也是同樣的道理。
這段代碼可以簡單的重構成
當你把變量的聲明和第一次用到它的地方間隔太遠時(距離超過一個屏幕)，這確實會成為一個問題。記住上下文關系會變得困難，你需要滾動屏幕去找哪來的這個變量。
5.?拒絕神秘數字
當你要把什么東西跟一個常量值做比較時，記得把這個值定義成常量。沒有什么會比去猜測你的同事寫的這樣的代碼更讓人頭疼的事了：
換個形式感覺如何？
6.?友好的對待你的語言
學習新語言是一種很有樂趣的事情，你能學到一種新的完成任務的途徑。當一個對一種語言已經很專業的人去學習另一種語言時，會出現一種很大的負面效應。比如說你是一個Java開發者，試圖去學習Ruby。你應該學會用Ruby的方式解決問題，而不是沿用Java的解決問題的思想。
當你需要重復5遍”Hello?world！“時，在Java里，你可能會這樣做：
在Ruby里，你也許會禁不住這樣寫：
這樣看起來沒問題，但有一個更好的方式：
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？在你的項目之外做一些小例子，當完全弄懂了后，丟掉例子，應用到你的產品里。
讓我們看一些基本的編程技巧：
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.?盡可能的把變量定義在靠近使用它的地方
蓋房子時，你可不希望把錘子放到別人的院子里。你希望把它們放的離手頭越近越好。定義變量也是同樣的道理。
| 1 2 3 4 5 6 7 | int?foo?=?3;int?bar?=?5;//?一大段使用“bar”的代碼，//?但沒用到“foo”//?...? baz(foo); |
這段代碼可以簡單的重構成
| 1 2 3 4 5 6 7 | int?bar?=?5;//?一大段使用“bar”的代碼，//?但沒用到“foo”//?...? int?foo?=?3;baz(foo); |
當你把變量的聲明和第一次用到它的地方間隔太遠時(距離超過一個屏幕)，這確實會成為一個問題。記住上下文關系會變得困難，你需要滾動屏幕去找哪來的這個變量。
5.?拒絕神秘數字
當你要把什么東西跟一個常量值做比較時，記得把這個值定義成常量。沒有什么會比去猜測你的同事寫的這樣的代碼更讓人頭疼的事了：
| 1 | il?<?4384 |
換個形式感覺如何？
| 1 | inputLength?<?MAX_INPUT_LENGTH |
6.?友好的對待你的語言
學習新語言是一種很有樂趣的事情，你能學到一種新的完成任務的途徑。當一個對一種語言已經很專業的人去學習另一種語言時，會出現一種很大的負面效應。比如說你是一個Java開發者，試圖去學習Ruby。你應該學會用Ruby的方式解決問題，而不是沿用Java的解決問題的思想。
當你需要重復5遍”Hello?world！“時，在Java里，你可能會這樣做：
| 1 2 3 | for?(int?i?=?0;?i?<?5;?i++)?{????System.out.println("Hello?world!");} |
在Ruby里，你也許會禁不住這樣寫：
| 1 2 3 | for?i?in?(0..5)??puts?"Hello?world!"end |
這樣看起來沒問題，但有一個更好的方式：
| 1 | 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？在你的項目之外做一些小例子，當完全弄懂了后，丟掉例子，應用到你的產品里。
的和（大數據處理）)
中的相關概念)
