在《喜劇之王》中，周星馳扮演的尹天仇，一直夢想成為一名演員，而他不管是在扮演跑龍?zhí)?，或者在街坊中開設(shè)演員訓練班，亦或成為主角時，他對待演員的態(tài)度，始終是認真，熱愛而又投入的。而那一本他隨身攜帶的書--《演員的自我修養(yǎng)》，盡管不知道里面具體寫的是什么，但我猜，他對待演員的態(tài)度和行為，就是書中內(nèi)容顯示的。

于是，不禁問了問自己，作為一名程序員，一個“程序員的自我修養(yǎng)”是什么？

盡管我們不一定要像尹天仇那么的認真對待自己的事業(yè)，但，一些基本的修養(yǎng)，作為一名新時代的碼農(nóng)，總應(yīng)該是要具備的吧。不過真要說修養(yǎng)，方面還是挺多的，技術(shù)自我提示自不必說。但我并不打算從這個大家都覺得理所當然的技術(shù)方面入手，而是談?wù)?，可讀性代碼，這個容易被大家忽視的基本素養(yǎng)。

1、遵從所在團隊的代碼規(guī)范。

一個高效、成熟的團隊，必定有一個屬于自己的代碼規(guī)范，這個規(guī)范是團隊的寶貴的財富，它是整個團隊從各種坑中爬起來后積累的經(jīng)驗教訓。什么是規(guī)范，它是人們從無數(shù)經(jīng)驗中總結(jié)出來的規(guī)則，標準。而代碼規(guī)范，指導團隊成員如何以最短的時間寫成最高效，可讀性強的代碼。試想，如果成員不遵從規(guī)范，你用駝峰命名，他用下劃線，這對程序的可讀，將造成多大的影響。我想，應(yīng)該沒有一個人愿意去閱讀一段，各種變量命名形式都能見得到，private， public 方法隨意排序，甚至常量類都散落在各個角落的代碼吧。

代碼，一個作用是讓機器閱讀，另一個重要的作用是讓人閱讀！??！

2、遵從行業(yè)內(nèi)通用的規(guī)范

在團隊的代碼規(guī)范未涉及到的，那請按照行業(yè)內(nèi)的規(guī)范來編寫代碼。規(guī)范的一個好處是，可以明顯減少學習和交流成本。在java中，當我們看到全大寫的變量名時，我們就知道這是常量，而不需要去看注釋，不需要去看代碼邏輯。為什么這么迅速，因為行業(yè)里大家都習慣把常量用大寫命名。但假如你用其他命名方式命名常量，比如team_nums命名常量，不僅不能讓人迅速知道這是個常量，而且可能讓人誤會這是個變量，增加了團隊成員學習和溝通成本，甚至可能誤導他們。就見過一位仁兄，明明用的是工廠模式，偏偏按模版模式的命名方式來命名，問他，他說他知道這是工廠模式，但他覺得，更應(yīng)該叫模版模式。。。我的天，，你這么任性，以后還能做朋友么？

舉個例子，我們需要根據(jù)支付類型，來生產(chǎn)多個支付產(chǎn)品，于是，我們寫了個工廠類，命名為FactoryPay。當其他人看到一個類叫FactoryPay，他們會猜測，這應(yīng)該是個工廠類，負責生產(chǎn)各種支付產(chǎn)品的工廠，然后按照這個猜測去閱讀代碼，就能比較快速的理解整個類的作用。但是，假如我取名PowerPay，別人還不知道是啥，看了半天，才明白，這是個工廠的作用。這就明顯增加了他人的學習成本和維護代碼的成本。

不管你是新手還是老鳥，務(wù)必了解施行行業(yè)規(guī)范，切勿為了標新立異而違反規(guī)范。這么低端的裝逼，就沒必要采用了，要裝也寫個高端的框架來提升逼格唄。

3、變量、方法命名要能表達變量作用

在程序員這個圈子很久了，就發(fā)現(xiàn)，程序員這貨，都喜歡這套，“這個接口干嘛用的，有文檔么”，“自己看代碼去”。很多時候都是一臉黑。

盡管程序員閱讀別人代碼技術(shù)都是一流，不管你是有沒有注釋，不管你是怎么循環(huán)嵌套，也不管你是怎么命名，他們都能耐心的，把代碼分析個所以然來。但，對于程序員這個視時間寶貴如生命，分分鐘都能創(chuàng)造幾百萬價值的群體來說，您行行好，給我們省點時間吧，把變量是干啥用的，說清楚唄，沒準節(jié)省的這幾分鐘，多賺個幾萬，還能請大家出去嗨呢。

每每看到部門的某大神，用一個神一般的變量名“flag”，我就有吐血的沖動，他還這個flag一直雪藏，不用，只是傳遞到第n個方法才使用，頓時心力交瘁，我的天，這個flag都是是干嘛用的啊，后來才明白，是isPay的意思，用來標識用戶是否支付成功了。當時一口老血吐屏幕上，心里狂吐槽，老兄，你命名個isPay會死么，我的腦細胞這么不值錢么。到后來看到，去魔法數(shù)字，用int NUM_7 = 7，而不是MAX_MEMBERS來表示最大成員、用x y z來命名變量名，各種只有作者，或者作者后來都忘了的獨特命名方式，都見怪不怪了。更有甚者，一個變量命名為passed，作用居然是“未通過”的意思，當時就石化了，作者還真是用心良苦，這都要考我細心不細心。

一個好的變量名，能幫助閱讀者了解變量的作用，也輔助了對整段代碼的理解。

4、不要show英語，鄉(xiāng)下的孩子傷不起唉

LZ所在的團隊，英語一直都是團隊的硬傷，但總是能看到，某位仁兄，加上大把大把的英文注釋，有些變量名也取些高大上的復雜的英語單詞。敢問，你這么高的逼格，以后我們怎么和你玩啊。（那位仁兄其實就是LZ，年輕時唉，罪過罪過）

代碼是用來溝通的，傳遞作者意圖的，都看不懂，怎么溝通交流。建議英語好的童鞋，英語能力可以放到閱讀英文書籍中展示，在代碼中，如果團隊英語能力很弱，避免使用英文，變量命名也盡量按照團隊英語水平來命名

5、添加必要的注釋

正如上面LZ說的，經(jīng)常遭遇“你仔細看看代碼，就知道干嘛用的”這樣的神回復。盡管閱讀代碼是每個程序員的強項，但必要的注釋，比如邏輯比較復雜的地方，添加必要的注釋，對提升團隊成員閱讀熟悉代碼的效率是有很大幫助的。試想，一個類，幾百行，沒有一行注釋，對于閱讀者來說，閱讀它將是一個多么恐怖的事。

6、注釋保持簡潔，避免沒有必要的注釋

即看過一行注釋都沒有的代碼，也看過注釋比代碼還要多的程序。一個是讓人生不如死，一個是讓人痛不欲生。（唉，有時不僅感嘆，在程序員界混，真的是難）。

LZ就經(jīng)?？催^，一大段注釋，啰嗦了半天，要不就是沒表達清楚重點，要不就是只為說明它是個循環(huán)的作用?。?！譬如i++這樣的代碼，有必要加個“每個計數(shù)增加1”這樣的注釋么，這完全是把讀者定位為非程序員啊，或者就是嚴重鄙視讀者的編程水平。

注釋是幫助閱讀的人更好的理解程序的邏輯，只是輔助，如果不重視通過命名等方式來傳遞代碼的作用，而是依賴于注釋，這就是本末倒置了。而且，冗長啰嗦的注釋，這到底是幫助人理解，還是阻礙人理解啊，是讀程序還是讀小說啊。

7、擁有自己的編碼規(guī)范

規(guī)范是為了讓團隊更快的理解、熟悉代碼的，同理，擁有自己的一套規(guī)范，就能幫助其他人更快的理解我們所寫的功能，減少學習和溝通成本。

8、代碼清晰簡潔的表達出作者的意思

在我們每次寫完一段代碼時，一定要問問自己，代碼是否表達清楚了我的意思，是否需要添加些注釋，名字取得是否恰當了，別人在閱讀時是否吃力。。每每看到別人一團糟的費解的代碼，就時刻提醒自己，一定要把代碼寫好咯，我也確實是這么做的，一遍又一編的檢查，看變量名、方法名是否表明了它的用途，是否有些不必要的、只是為了提升逼格的代碼，別人是否能在短時間內(nèi)看懂。所有的這些，只是為了寫出一段更優(yōu)美的代碼。

9、堅持并捍衛(wèi)上面的準則

經(jīng)常能聽到，有些公司是代碼行數(shù)來定義績效的，但作為一個有操守，并秉承基本自我修養(yǎng)的程序員，我們絕不能為了各種誘惑或者脅迫，甚至是自己的惰性、個性，而放棄寫出簡潔清晰，可讀的代碼。

以上的幾點，并不是嚴格的意見或者建議，只是提醒廣大程序員同胞們，在癡心與高端的技術(shù)時，千萬不要忘了，代碼不僅機器要閱讀，人也需要閱讀。就算你寫出再復雜的代碼，但它讓人完全無法閱讀，這有什么用呢。這就如同，你很牛逼很牛逼，但別人聽不懂你說的話，還不是沒用。如果你真的寫出了可讀性強的代碼，但你也不應(yīng)該鳴鳴得意，我覺得，寫出一段優(yōu)美，健壯，可讀性高的代碼，是一個程序員最基本的自我修養(yǎng)。如果這個追求都沒有，那和咸魚有啥區(qū)別呢。雖然常被外人看來邋里邋遢，不善交流，但我們的的代碼優(yōu)美，每段代碼都清晰簡潔的表達了心中的想法，這不也很好么。代碼作為程序員間交流溝通的媒介，一定要保持它的高效溝通的屬性，切不要為了自己的個性，而犧牲它的可讀性。在此，建議大家業(yè)余時間閱讀些比如《clean code》、《how to be a better programmer》等相關(guān)書籍