關於代碼的一些心得體會
前 言
Lms
入行也有很久了，一直都只是忙着工作學習，卻一直沒能好好靜下心來好好整理一下自己。時間久了，慢慢的代碼越來越熟悉，敲起來也越來越順手，自己缺總感覺有些不對。我總覺得代碼不應該就是這么簡單，不應該像寫記敘文一樣，一條一條慢慢的就羅列出來了，返回去看了看自己剛寫代碼的時候功能也都能夠實現了。但是還是有那么多可以優化的地方。我覺得好的代碼不應該只是把功能實現那么簡單，我覺得好的代碼應該有以下幾條特點：第一，命名要規范，第二，可復用性，第三，就是注釋。當然，當然你們可能有更深入的理解，可以分享給我，這里，僅把我最近領悟的分享給大家。
| 一、 命名的規范 |
最近，一直有看一些關於怎么優化代碼的文章和博客，大多都有提到命名的規范和代碼的可讀性。說來慚愧，我醒悟的並不算太早，有挺長一段時間我的代碼里充斥着var daa； var mbb；等一些蜜汁縮寫，有時翻出自己原來的代碼來作復習和總結，看到這些東西總是最頭疼的，因為自己已經忘了這是什么的縮寫，是拼音還是英語，都早已不記得了。只能再次整理代碼邏輯，找到這些東西到底是啥。
命名規范主要就是可讀性，可讀性高了將大大提高代碼的質量，也會增加代碼的可維護性。畢竟，維護代碼首先要讀懂代碼。下面講一下我對變量和函數命名的一些心得，看了許多文章，都在說要遵守某某法則，和使用標准的英文。我說下我的看法：
1、首先，命名確實需要一個好的命名規則，你可以使用駝峰法則，匈牙利命名法等等，這會讓名字看起來清晰一些，畢竟不能用空格隔斷單詞。
2、關於英語命名，如果你英語好的話，我建議你是用標准的英文來命名，如果你英語不好的話我建議你使用拼音。總有人在說程序員使用拼音很土，很low，可我想不明白，中華民族的拼音low在哪了，難道就連個代碼命名都要崇洋媚外么。當然，筆者英語比較差，我承認，所以別人這么說我的時候有些反感。我覺得拼音挺好的，至少在國內的話，程序員英語差的不在少數。當然，你想寫出國際化的代碼，走向世界，就當我在放屁。
3、使用縮寫的時候，請在你第一次使用這個塊的縮寫時，在前面注釋一下這個縮寫是啥意思，為以后的讀取大開方便之門，畢竟你注釋只需要一點點時間，但是，不寫注釋等你再用到去翻看的時候會用到幾倍甚至幾十倍的時間。
| 二、可復用性 |
我覺得，寫的好的代碼是下次拿過來就能用的。這里的可復用性我有兩種理解，
第一種可復用性就是這段代碼會在這個程序或是工程里經常出現所以把它提出去。封裝起來，哪里需要哪里調用即可。
第二種可復用性就是寫了一個很常用的功能，在別的工程也用到的時候直接拿過來就可以使用的，也就是平時我們用的插件。
下面，舉個例子：
1、首先，要實現一個信息循環滾動的功能：
· 2、然后你可以把它寫成這種，基本的功能都已經實現了，並沒有哪里不對，請接着往下看
3、隨着你的不斷進步，你會發現代碼還可以繼續優化然后變成下邊的樣子。
4、技術不斷提高，眼界的開闊，優質源碼的閱讀，你會發現原來的代碼還可以進一步優化，然后變成了插件
| 三、 注釋 |
首先，我們看一下注釋的重要性，先看一下幾種假設，請帶入一下：
1、當你經過一段時間后，發現哪兒出問題或需要調整功能的時候；
2、當你去改別人代碼的時候（你的代碼也會被別人改）；
3、當你需要補一些設計文檔的時候（比如現在的我）；
注：以上的這些情景僅發生在：1、你所面對的是別人的代碼；2、如果你面對的是你的代碼，再加一個前提，過一段時間之后。
然后，我總結了一下我們在注釋中常出現的問題，大家共勉：
1、忘記寫注釋：a、這種情況大多數是只寫了方法本身功能注釋，但是參數的含義並未加以說明(再遇到參數取名和本身含義更不符的情況下，就更頭疼了)；
b、有些就直接類和方法注釋都沒有（少數）
2、注釋描述的不夠清楚、太簡單籠統話：一些類或方法注釋太過於簡單籠統，不能准確表達代碼含義。
3、注釋與本身代碼所做的功能不符合：總結發生的情況可能有如下原因：
a、寫好一個方法或類，復制粘貼的時候把注釋一起復制粘貼，完了后代碼改了（代碼有錯誤提示）忘了改注釋（注釋沒有錯誤提示），導致注釋與代碼不符；
b、一些方法參數，可能實現設計的時候沒有，或者多設計了，后來經過反復修改，參數進行了調整，這時參數的注釋還是以前初始版本，這種情況也是只注重代碼，注釋未得到及時的更新，導致注釋與代碼嚴重不符；
最后，關於怎么做好注釋我寫下我的理解：
1、一定要養成良好的代碼注釋習慣，邊寫代碼邊注釋，及時的記錄下自己寫代碼過程中的思路；
2、一定要養成代碼和注釋同時對待，改完代碼及時更正注釋；
3、多提升自己對代碼的解釋能力，用精煉的語言表達出代碼的核心價值所在；不要用冗雜的語言描述，看起來注釋比代碼還多。
關於怎么寫出更好的代碼我也在進步的路上，在此寫出此篇文章大家共勉。大家都有不同的意見歡迎指教討論，大家一起進步。最后謝謝大家的閱讀。