標籤:style http color 使用 io strong 檔案 ar
第3部分 軟體研發工作總結
代碼的第一印象
我們都很注重給別人的第一印象,也有很多書籍教我們怎樣給別人留下一個美好印象的。確實,如果我們第一眼看到某個人,就覺得很不爽,那麼一定會在心理上產生抵觸,以後再見到他,會有一種疏遠的感覺。也正因為如此,當今社會交往中的“面子工程”很重要,不管怎樣,先撐足了自己的臉面再說。
代碼也一樣,也會給別人留下或好或差的印象。當我們看到優美的代碼時,會有一種想繼續研究下去的慾望,甚至會有一種覺得很享受的感覺。相反,當我們看到醜陋的代碼時,就會咬牙切齒,因為它不僅不利於閱讀,還會浪費我們很多時間,降低我們做事的效率。人人都想寫出好的代碼,就像大家都想考試取得好成績一樣。但是,在實際工作中,有很多因素使得我們心有餘而力不足,想把事情做好,結果卻事與願違。
一般說來,代碼給我們的第一印象有如下幾種:
排版工整 VS 排版不工整
我們開啟一個代碼檔案的時候,最先看到的就是其排版怎樣,這也是最直觀的感覺。當代碼排版工整時,我們很容易找出其條理和邏輯,會很快理解其到底要實現什麼功能;而排版不工整的時候,我們的眼睛會覺得很累,進而影響了我們的思維。
排版工整的代碼形式如下:
程式碼片段A
程式碼片段B
程式碼片段C
程式碼片段D
排版不工整的代碼形式如下:
程式碼片段A
程式碼片段B
程式碼片段C
程式碼片段D
命名規範 VS 命名不規範
在看完排版之後,我們就會看到每個函數和變數的命名。由於一般項目的程式碼數都比較多,我們不可能花很多時間去理解每個函數和變數到底是何用意,到底是拿來做什麼的。這就要求我們在編碼的時候,使函數和變數的命名具有自說明性,讓它們自己告訴讀者是做什麼用的,而不是要別人花大量時間去研讀後才能知道。這在一定程度上反映了開發人員的態度和專業化程度。
例如,一個處理訊息的函數,命名為ProcessMsg和FunctionA,哪個更好呢?顯然是前者。我們只要一看到其名字,就知道它是做什麼用的。
再如,有三個變數,命名為LoopFlag、MaxNum、SumOfTwoNum,我們就能一下子明白它們有何用途。第一個變數用於作為迴圈標誌,第二個變數用來存放最大數,第三個變數用來存放兩個數之和。這太明顯了,你都可以不用去問元芳,自己就能搞清楚。而如果同樣三個變數,命名為i、j、k,你就無法一眼看出它們到底有什麼用,還要花大量的時間去閱讀代碼,甚至用幾個小時的時間,你還不知道它們有何用途。這時,你的老大來問你事情做得怎樣,你照實一說,他便說你無能。其實你是“啞巴吃黃連”,怪就怪別人沒有把代碼寫好。
注釋得當 VS 注釋不得當
第一眼看到代碼,我們還會注意到其是否有注釋,注釋多還是少。這也是很直觀的。
如果代碼實現的功能較為複雜,那麼添加註釋是必不可少的。在恰當的地方,使用恰當的注釋,能夠讓讀者覺得思路豁然開朗,他們會默默地在心裡感激你。注釋過少或沒有注釋是不行的,就像我們吃飯一樣。如果一碗青菜裡面什麼也沒有,你會覺得很乏味,沒有食慾。如果放上一點辣椒醬,就會覺得食慾倍增。不管你信不信,反正我是信了。
但是,注釋也不能過多,不能將有用的代碼掩蓋住了,不能夠喧賓奪主,讓真正實現功能的代碼成了陪襯。馬克思教導我們“凡事都要有個度”,就是這個道理。
良好的注釋形式如下:
// 注釋A
{
語句塊A
}
// 注釋B
{
語句塊B
}
// 注釋C開始
語句D
語句E
語句F
// 注釋C結束
有了代碼給我們的好的第一印象,接下去的工作就要好辦多了。在實際開發中,我就有這樣的經驗:當接手到優美的代碼時,自己就會為之振奮,會花費較少的時間而將任務完成得很好。我想,沒有人想接手一個爛攤子,不僅影響開發進度,還影響心情。也許你當天是高高興興來上班的,但好心情就毀於爛代碼之手。你說,是值,還是不值?
為了給別人留下好印象,我們一定要首先讓自己的代碼給別人一個好的第一印象。這也是培養團隊凝聚力的一個很好的方法。
(本人微博:http://weibo.com/zhouzxi?topnav=1&wvr=5,號:245924426,歡迎關注!)