在《喜劇之王》中,周星馳扮演的尹天仇,一直夢想成為一名演員,而他不管是在扮演跑龍套,或者在街坊中開設演員訓練班,亦或成為主角時,他對待演員的態度,始終是認真,熱愛而又投入的。而那一本他隨身攜帶的書--《演員的自我修養》,盡管不知道里面具體寫的是什么,但我猜,他對待演員的態度和行為,就是書中內容顯示的。
于是,不禁問了問自己,作為一名程序員,一個“程序員的自我修養”是什么?
盡管我們不一定要像尹天仇那么的認真對待自己的事業,但,一些基本的修養,作為一名新時代的碼農,總應該是要具備的吧。不過真要說修養,方面還是挺多的,技術自我提示自不必說。但我并不打算從這個大家都覺得理所當然的技術方面入手,而是談談,可讀性代碼,這個容易被大家忽視的基本素養。
1、遵從所在團隊的代碼規范。
一個高效、成熟的團隊,必定有一個屬于自己的代碼規范,這個規范是團隊的寶貴的財富,它是整個團隊從各種坑中爬起來后積累的經驗教訓。什么是規范,它是人們從無數經驗中總結出來的規則,標準。而代碼規范,指導團隊成員如何以最短的時間寫成最高效,可讀性強的代碼。試想,如果成員不遵從規范,你用駝峰命名,他用下劃線,這對程序的可讀,將造成多大的影響。我想,應該沒有一個人愿意去閱讀一段,各種變量命名形式都能見得到,private, public 方法隨意排序,甚至常量類都散落在各個角落的代碼吧。
代碼,一個作用是讓機器閱讀,另一個重要的作用是讓人閱讀?。?!
2、遵從行業內通用的規范
在團隊的代碼規范未涉及到的,那請按照行業內的規范來編寫代碼。規范的一個好處是,可以明顯減少學習和交流成本。在java中,當我們看到全大寫的變量名時,我們就知道這是常量,而不需要去看注釋,不需要去看代碼邏輯。為什么這么迅速,因為行業里大家都習慣把常量用大寫命名。但假如你用其他命名方式命名常量,比如team_nums命名常量,不僅不能讓人迅速知道這是個常量,而且可能讓人誤會這是個變量,增加了團隊成員學習和溝通成本,甚至可能誤導他們。就見過一位仁兄,明明用的是工廠模式,偏偏按模版模式的命名方式來命名,問他,他說他知道這是工廠模式,但他覺得,更應該叫模版模式。。。我的天,,你這么任性,以后還能做朋友么?
舉個例子,我們需要根據支付類型,來生產多個支付產品,于是,我們寫了個工廠類,命名為FactoryPay。當其他人看到一個類叫FactoryPay,他們會猜測,這應該是個工廠類,負責生產各種支付產品的工廠,然后按照這個猜測去閱讀代碼,就能比較快速的理解整個類的作用。但是,假如我取名PowerPay,別人還不知道是啥,看了半天,才明白,這是個工廠的作用。這就明顯增加了他人的學習成本和維護代碼的成本。
不管你是新手還是老鳥,務必了解施行行業規范,切勿為了標新立異而違反規范。這么低端的裝逼,就沒必要采用了,要裝也寫個高端的框架來提升逼格唄。
3、變量、方法命名要能表達變量作用
在程序員這個圈子很久了,就發現,程序員這貨,都喜歡這套,“這個接口干嘛用的,有文檔么”,“自己看代碼去”。很多時候都是一臉黑。
盡管程序員閱讀別人代碼技術都是一流,不管你是有沒有注釋,不管你是怎么循環嵌套,也不管你是怎么命名,他們都能耐心的,把代碼分析個所以然來。但,對于程序員這個視時間寶貴如生命,分分鐘都能創造幾百萬價值的群體來說,您行行好,給我們省點時間吧,把變量是干啥用的,說清楚唄,沒準節省的這幾分鐘,多賺個幾萬,還能請大家出去嗨呢。
每每看到部門的某大神,用一個神一般的變量名“flag”,我就有吐血的沖動,他還這個flag一直雪藏,不用,只是傳遞到第n個方法才使用,頓時心力交瘁,我的天,這個flag都是是干嘛用的啊,后來才明白,是isPay的意思,用來標識用戶是否支付成功了。當時一口老血吐屏幕上,心里狂吐槽,老兄,你命名個isPay會死么,我的腦細胞這么不值錢么。到后來看到,去魔法數字,用int NUM_7 = 7,而不是MAX_MEMBERS來表示最大成員、用x y z來命名變量名,各種只有作者,或者作者后來都忘了的獨特命名方式,都見怪不怪了。更有甚者,一個變量命名為passed,作用居然是“未通過”的意思,當時就石化了,作者還真是用心良苦,這都要考我細心不細心。
一個好的變量名,能幫助閱讀者了解變量的作用,也輔助了對整段代碼的理解。
4、不要show英語,鄉下的孩子傷不起唉
LZ所在的團隊,英語一直都是團隊的硬傷,但總是能看到,某位仁兄,加上大把大把的英文注釋,有些變量名也取些高大上的復雜的英語單詞。敢問,你這么高的逼格,以后我們怎么和你玩啊。(那位仁兄其實就是LZ,年輕時唉,罪過罪過)
代碼是用來溝通的,傳遞作者意圖的,都看不懂,怎么溝通交流。建議英語好的童鞋,英語能力可以放到閱讀英文書籍中展示,在代碼中,如果團隊英語能力很弱,避免使用英文,變量命名也盡量按照團隊英語水平來命名
5、添加必要的注釋
正如上面LZ說的,經常遭遇“你仔細看看代碼,就知道干嘛用的”這樣的神回復。盡管閱讀代碼是每個程序員的強項,但必要的注釋,比如邏輯比較復雜的地方,添加必要的注釋,對提升團隊成員閱讀熟悉代碼的效率是有很大幫助的。試想,一個類,幾百行,沒有一行注釋,對于閱讀者來說,閱讀它將是一個多么恐怖的事。
6、注釋保持簡潔,避免沒有必要的注釋
即看過一行注釋都沒有的代碼,也看過注釋比代碼還要多的程序。一個是讓人生不如死,一個是讓人痛不欲生。(唉,有時不僅感嘆,在程序員界混,真的是難)。
LZ就經常看過,一大段注釋,啰嗦了半天,要不就是沒表達清楚重點,要不就是只為說明它是個循環的作用!??!譬如i++這樣的代碼,有必要加個“每個計數增加1”這樣的注釋么,這完全是把讀者定位為非程序員啊,或者就是嚴重鄙視讀者的編程水平。
注釋是幫助閱讀的人更好的理解程序的邏輯,只是輔助,如果不重視通過命名等方式來傳遞代碼的作用,而是依賴于注釋,這就是本末倒置了。而且,冗長啰嗦的注釋,這到底是幫助人理解,還是阻礙人理解啊,是讀程序還是讀小說啊。
7、擁有自己的編碼規范
規范是為了讓團隊更快的理解、熟悉代碼的,同理,擁有自己的一套規范,就能幫助其他人更快的理解我們所寫的功能,減少學習和溝通成本。
8、代碼清晰簡潔的表達出作者的意思
在我們每次寫完一段代碼時,一定要問問自己,代碼是否表達清楚了我的意思,是否需要添加些注釋,名字取得是否恰當了,別人在閱讀時是否吃力。。每每看到別人一團糟的費解的代碼,就時刻提醒自己,一定要把代碼寫好咯,我也確實是這么做的,一遍又一編的檢查,看變量名、方法名是否表明了它的用途,是否有些不必要的、只是為了提升逼格的代碼,別人是否能在短時間內看懂。所有的這些,只是為了寫出一段更優美的代碼。
9、堅持并捍衛上面的準則
經常能聽到,有些公司是代碼行數來定義績效的,但作為一個有操守,并秉承基本自我修養的程序員,我們絕不能為了各種誘惑或者脅迫,甚至是自己的惰性、個性,而放棄寫出簡潔清晰,可讀的代碼。
以上的幾點,并不是嚴格的意見或者建議,只是提醒廣大程序員同胞們,在癡心與高端的技術時,千萬不要忘了,代碼不僅機器要閱讀,人也需要閱讀。就算你寫出再復雜的代碼,但它讓人完全無法閱讀,這有什么用呢。這就如同,你很牛逼很牛逼,但別人聽不懂你說的話,還不是沒用。如果你真的寫出了可讀性強的代碼,但你也不應該鳴鳴得意,我覺得,寫出一段優美,健壯,可讀性高的代碼,是一個程序員最基本的自我修養。如果這個追求都沒有,那和咸魚有啥區別呢。雖然常被外人看來邋里邋遢,不善交流,但我們的的代碼優美,每段代碼都清晰簡潔的表達了心中的想法,這不也很好么。代碼作為程序員間交流溝通的媒介,一定要保持它的高效溝通的屬性,切不要為了自己的個性,而犧牲它的可讀性。在此,建議大家業余時間閱讀些比如《clean code》、《how to be a better programmer》等相關書籍
-
程序員
+關注
關注
4文章
951瀏覽量
29799
發布評論請先 登錄
相關推薦
評論