程序員懵逼時刻：幾個月後，以前本身寫的代碼也看不懂了？

程序員們大多都會有過這樣的經歷，就是要看別人寫的代碼。好比說公司有同事離職了，他的業務就須要有其它的小夥伴們給接下來繼續維護。

這對好多程序員來講是一種折磨，邊看邊罵，這寫的是什麼東西呀。相信好多人都有這種經歷。

那麼爲何會出現這樣一個局面呢，其實這裏面就有不少講究的地方了，若是不注意的話，不光是看不懂別人寫的代碼，即便是本身寫的代碼，幾個月後你再去瞧瞧，你也會發現，咦，看不懂了呢。

那麼接下來就分析一下這種狀況造成的緣由及怎麼去解決它們。

」註釋很重要」，」註釋很重要」，」註釋很重要」，重要的事情說三遍。

造成這種局面的緣由

1.面向過程去寫代碼
寫代碼前沒有對代碼進行設計，徹底是爲所欲爲去實現。對本身的要求比較低，就是「能實現功能就能夠了」這種心態去寫代碼。這樣的代碼未來是十分很差維護的，別說之後讓別人來維護這個代碼了，即便幾個月後的本身也是很是困難能讀懂本身的代碼。

2.代碼沒有註釋
代碼註釋是對讀取代碼有着很是好的輔助做用，是其餘人可以快速的瞭解代碼的功能，同時對本身之後回頭來看本身的代碼也是十分有幫助的。沒有註釋的代碼就像深夜車燈壞了的汽車同樣，雖然能行駛，可是你敢快開麼？

3.代碼變量名稱隨意
好比什麼abc,temp這類變量，這是讓誰看的，不根據代碼的上下文誰也不知道這是啥意思，若是代碼的上下文中全是相似這樣的變量，我估計看代碼的人會瘋掉的。

4.每一個方法分工不明確
一個方法中夾雜着多種功能，讓人看了以後很難說出這個方法是幹啥的，也不敢輕易去修改。

不論爲本身仍是爲別人，讓之後本身能看懂本身的代碼，仍是爲別人能看懂本身的代碼，讓本身不捱罵，那麼就推薦如下幾種方法來規範本身的代碼，讓別人或者是本身可以輕輕鬆鬆看懂本身的代碼。

破除這種局面

1.實現功能前先設計好代碼
最好是面向對象的方式編程，不管是java仍是Python都能很好的應用面向對象的方式進行編程，設計好文件名，類名，以及方法名，不管是文件名，仍是類名，方法名都要作到見名知意，要用標準的英文去表示，須要用多個英文表示就用駝峯標識來表達。讓人看上去結構一目瞭然，代碼看上去讓人賞心悅目。

2.註釋寫的儘可能詳細
每一個類，每一個方法都要寫明註釋， 類的註釋能夠簡明寫這個類的主要功能，可是每一個方法的註釋儘可能要寫細了，註釋必定要覆蓋方法中所實現的全部功能，而不是隻寫其中一部分。看過系統級源碼的程序員都知道，註釋的行數是比代碼的行數還要多的。這就是優秀的習慣，咱們也要去學習、掌握。

3.不要隨便定義臨時變量
儘可能不要定義一些臨時的變量，若是十分必要定義時，最好是加上單行註釋，讓其餘人知道你的意圖。

4.不要寫太長的方法
每一個方法最好不要超過50行代碼，若是過長了，能夠考慮該方法的功能點是否能夠再次拆分，最好是一個方法就實現單一的一個功能，這樣的話方法的複用率也會提升的。

5.不要寫太「牛」的代碼了
有的程序員喜歡寫很是有個性的代碼，喜歡寫一些別人很難看懂的代碼，他認爲這樣才能顯示出本身的「高水平」，這樣就不是高水平了，只能說代碼的可讀性太差了，咱們要寫出傻瓜式代碼，也就是說讓很傻的程序員都能看懂，」傻瓜式代碼」 != 「低性能代碼」哈，這一點要分開。

6.中國人就別寫英文註釋了
好多國內的程序員給代碼寫註釋用英文寫，若是英文很是好的話寫英文註釋那固然是無可厚非，若是你英文很差，那麼仍是勸你別寫英文註釋了，你在折磨本身也折磨別人嘛。
在剛開始的學習階段大部分老師都會要求學生寫註釋，只是咱們在後面的學習工做中，由於有些時候須要趕進度，會忽略了代碼註釋，代碼註釋不只方便本身之後修改代碼，還會使別人更好的理解你的代碼。
看到這裏還沒過癮，那麼就來羣裏與更多的大佬交流切磋技術，戳這裏：我們來一塊兒抱團取暖，好嗎？