代碼精進之路讀後感（六-結束篇）

繼續拜讀範老師的代碼精進之路，這一篇說的使咱們最經常使用的註釋

註釋就是對代碼的解釋。註釋不須要運行，它是用來提升代碼的可讀性和可維護性的。可是很差的註釋會使代碼變得更糟糕,令人更抓狂

首先咱們必定要明白一個事情：源代碼不必定要添加註釋

在理想狀態下，代碼不須要註釋，理想的代碼，命名恰當，結構清晰邏輯順暢，含義顯而易見。可是正如一個做者沒法預料他的做者可否讀懂他的意思同樣，一個程序員也沒辦法保證他的做者可否理解他的意思，因此咱們就須要來使用註釋進一步提升可讀性。

使用註釋該注意什麼：

1.不能過分的依賴註釋，咱們首先要保證準確的命名，清晰的結構，而不是由於使用註釋就不注意命名規範

　　例如

var name1; // first name
var name2; // last name

　　雖然有註釋可是讀起來很費勁，那咱們就不如改用如下方式

var firstName;
var lastName;

2.不能夠濫用註釋

　　因爲註釋部分不被執⾏，那麼就能夠被⽤來註釋掉⼀些不須要的東⻄。⽐如，在正式的產品代碼中，註釋掉調試信息、代碼塊、俏皮話等等。

　　⽐如說，看到下面的註釋，你是否是當即就轉移注意⼒了？ 我理解這個註釋的初衷是幽默⼀下，可是衆⼝難調，這樣的註釋有些人感受到的不是幽默，而是散漫和業餘。

// 哈哈，有沒有⼈姓好，叫「好名字」？
var firstName;
var lastName;

 

總結⼀下，註釋是代碼的⼀部分，是須要閱讀的內容，⽬的是讓其餘⼈能更好地理解咱們的代碼，寫註釋須要咱們有「⽤戶思惟」。雖然也有過分依賴註釋的狀況，可是，對於⼤部分程序員來講，問題仍是註釋太少，⽽不是太多。

 

常見的註釋類型

　　1.是記錄源代碼版權和受權的

　　　　⼀般放在每⼀個源文件的開頭，說明源代碼的版權全部者，以及受權使用的許可方式，或者其餘的公共信息

　　2.是用來生成用戶文檔的

　　　　⽐如Java Doc。 這部分的做⽤，是⽤來⽣成獨⽴的、不包含源代碼的⽂檔。 這些⽂檔幫助使⽤者瞭解軟件的功能和細節，主要⾯向的是該軟件的使⽤者，⽽不是該軟件的開發者。 ⽐如Java的API規範的⽂檔。

　　3.是用來解釋源代碼的

　　　　就是幫助代碼的閱讀者理解代碼。這是⼤家默認的註釋類型，

 

註釋的三項原則

　　1. 準確，錯誤的註釋⽐沒有註釋更糟糕。
　　2. 必要，多餘的註釋浪費閱讀者的時間。
　　3. 清晰，混亂的註釋會把代碼搞得更亂。

 

合理的運用好註釋必然會讓咱們代碼的可讀性更上一層樓，就不會出現懟着一個函數看半天還不知道這個函數是在作什麼的狀況了，加上註釋吧騷年，幸福你我他

到此關於代碼精進之路的閱讀就結束了，雖而後續還有不少篇，例如內存規範之類的，前端基本上是涉及不到的，因此我也就不在將後續的發表讀後感了，經過讀了讀範老師的幾篇文章感觸頗多，意猶未盡的同窗能夠直接去看範老師的文章