源
對於一個程序員來說，註釋就相當於雷達，只有註釋可讀性好，便於理解，才能讓項目更好的交接、交互、修改。
1.做好註釋的情況。請參照圖2.這是我拍攝的thinkphp框架下官方demo的示例，每個函數會有函數的功能簡介，每個模塊都有一個大概得說明，必要的地方也簡單一寫，讓讀代碼的人一看就知道這裡是幹嘛的，改起來也非常容易。還有前後端分離的項目，後段一看，需要調用什麼接口，參數是什麼，類型是什麼，也非常清楚。這才是良好的代碼規範。寫好代碼只是一半，良好的註釋代表了一半的工作。
2.沒有做好註釋的情況。參照圖1.這是我見過的一個asp網站的源碼，誰能告訴我這是說了什麼？這是幹嘛的？我從哪裡來，宇宙是怎麼形成的，好吧，跑偏了，這個代碼可讀性太差了，我要順著邏輯把每個頁面都看一遍才能知道每個頁面幹什麼的。修改起來就更麻煩了，特別是如果摻雜了一代程序員的個性代碼，就是無從下手。可能隨便一改，程序崩潰了也不是不可能。
希望以後想成為程序員的每個人，能知道註釋的重要性，它對於你是一個良好的習慣，對於項目是珍貴的資料，對於一個企業來說可能決定你走的路的長遠。
PPt小助手
有時候，我們的開發者要完成某個功能的編碼實現，或許靈光一閃，猶如行雲流水，一氣呵成，看著長長的整潔的代碼總是忍不住津津樂道，就是懶得給這代碼添上幾行註釋。過幾天，或者過了一段時間之後，代碼需要改動，還得花時間重新理解這段代碼，改動需要10分鐘足矣，但是閱讀這段代碼可能需要花上半個小時或者半天的時間，如果這代碼是由別的程序員來閱讀，花的時間必定會更長。
不寫註釋，不利於日後工作的進展，也不利於日後工作的交接。
百度、google了一下都沒有詳細說程序註釋的意義相關的文章，只搜到一些不寫註釋帶來的影響，諸如此類：
給代碼寫上工整的註釋是一個優秀程序員的良好習慣。工整簡潔的代碼未必就有較高的可讀性，在一些業務比較繁瑣，參數比較多的函數中，閱讀代碼的人會在各種參數的用法中糾纏不清，但是如果在參數或者業務操作的代碼旁加上工整的註釋，可以讓既有的代碼脈絡清晰，更加有血有肉。如下圖所示：
註釋是程序員之間交流的通道。
代碼中的某些參數，就像上文提及的“字”；代碼中的某些行，就像上文提及的“詞”；
代碼中的某些函數或者某些代碼塊，就像上文提及的“句”。
有了註釋輔助，讀者可以自行理解代碼的實現思想，就不必手足無措地找人詢問，大大節省時間成本，也可更專注在工作上。
上圖的註釋清晰反映了函數與代碼上下文的關係，這麼貼心的註釋，使得讀者在茫茫代碼之中不必為了查找某個參數或者某個方法而上上下下地翻動滾動條，不至於讓讀者在翻查代碼的過程中丟了工作的熱情。
註釋是程序員個性的反映。
大家都有各自的編碼習慣和註釋風格，喜歡在註釋裡面署名的程序員，個性比較張揚，無論是對生活還是對工作都是樂觀積極，團隊中的活躍分子；
喜歡用符號框住註釋的程序員，擁有謙虛得體的個性，工作生活中不驕不躁，傳遞著正能量；喜歡把註釋圍成圖案的程序員，內心想法豐富多彩，無論是工作還是生活都不缺乏藝術範。可見，註釋也是程序員得以展現自我的舞臺。
註釋有利於節約公司的資源。
程序員的工作很多時候會交接給新的職員來進行，新職員往往會耗上一段較長的時間去閱讀代碼，這個過程難免會經常詢問同事有關問題，間接或直接影響到同事工作狀態。註釋可以大大降低問題的發問率，並且引導新職員去理解代碼，同時節省了時間，而時間就是金錢。
看過軟件工程相關教材的都有所瞭解，幾乎每一本教材都告訴我們寫代碼要加註釋，並且要學會高質量的註釋，因為代碼不僅僅是用來執行的，它還是用來給別人看的。好的代碼加上高質量的註釋，使得程序盡顯優雅，讀的人賞心悅目，何樂為不為呢？
莫非8125
程序註釋非常重要！！！好的代碼首先要易於閱讀，其次才是效率。
1. 代碼是持續性的工作，後期需要不斷在現有代碼上進行調整和優化。自己剛寫的代碼對邏輯和含義會比較清楚，但是隨著時間流逝，自己也會忘記，如果這時讓你來修改這段代碼你需要花很多精力去回憶和讀懂原來寫的邏輯。
2. 代碼是團隊資產，會有多人一起進行維護和編輯。如果不寫註釋，其他人看起來會非常費勁。工作中經常會發生這種情況，某員工離職了，別人接手他的代碼，但是沒有註釋看不懂，導致不敢輕易去修改，乾脆自己重新寫一套了，這樣對公司來說是極大的資源浪費。
3. 寫代碼註釋是程序員的必備素質，不願意註釋可能是因為懶，也可能是為了趕工想著後面再來補。不管是哪種原因，這都是不好的習慣。我在面試程序員是都會問他們寫註釋的方法，可以按功能，可以按函數，也可以按代碼難點等等。其實寫註釋可以按自己的習慣，只要清楚明白，讓別人能看懂即可。
看看大神們寫的代碼，幾乎每行都有註釋
編程語言的種類不可勝舉，以後肯定還會有新的語言出來，但是不論是哪種編程語言都會大篇幅來講註釋的寫法，可見重要性。
用適合自己的方法來寫註釋。養成自己的編程技巧，對自身發展也很重要。
總之，程序註釋非常重要！！！
數據思維
現在程序員可是說是滿地都是，層次不同寫出的代碼風格也完全不一樣，代碼就像一片文章，有些人寫的程序規章有度，則有些程序員寫出來的則是東一下西一下，雖然也能運行可是各位考慮過嗎如果你辭職之後你的代碼需要改進 ，看到你的代碼一臉懵逼，他甚至會罵寫這些代碼的人，他會說你寫的都是BUG，在需求隨時變更的時代作為一名程序員應該做到，寫好備註不然寫完了你從頭檢查的時候你會發現你居然不知道你寫的是個什麼鬼，還有就是千萬要讀懂需求再去寫代碼，程序員不是一個著急的人能的行業，膽大心細願意去嘗試，不寫代碼註釋你會發現以後苦逼維護的還是你，註釋就像你兒子身上的胎記，如果沒有這個胎記你就發現過了五六年你連你孩子都不認識了
還有就是做項目要多交流，有個良好的環境，不然低頭做做完了之後你會發現你理解錯了需求，客戶就是你的金主爸爸，及時與團隊溝通才能達到準確的知道客戶需求與項目進度，做程序員不能一枝獨秀，特別是在一個團隊，團隊和諧才有更好的氛圍。
程序員小謝
程序註釋要堅持less is more的原則。
你的寫的代碼不是註釋越多越好，首先你將你的邏輯理清楚，好的邏輯性會減少很多註釋，差的邏輯代碼，你會發現無從註釋，不知道怎麼描述。不能忘記註釋本身的作用，編程kpi形式註釋。
一般註釋對於參數 ，接口，方法一定要加註釋，因為畢竟母語不是英語不是母語，很多時候用詞不準確，造成後面理解和閱讀困難。
方法內部儘量少註釋，除非這段邏輯寫的很精剪，需要描述。儘量讓代碼自描述完整，邏輯一幕瞭然，其次在方法內部可能存在多個邏輯段。不同邏輯段需要註釋一下。方便閱讀。
IT小侃
註釋就是輔助自己過一段時間或者接手的人理解你寫的程序代碼的手段，良好的註釋體驗出你邏輯思路清晰。
如果沒有註釋，不僅一段時間之後自己可能無法理解當時為何自己這樣寫，維護的人也會一篇茫然不知所措。
閉著眼睛切土豆
1.提醒自己
2.提醒別人
3.不好直觀看懂的代碼需要編寫註釋用來解釋這一段代碼的用途。
4.解釋自己當時這段代碼所用的思路。
深挖君
說什麼都難免蒼白無力，直接的體會就是: 假設你接手了前任的沒有任何註釋的項目時，你立馬就會體會到程序有(好的)註釋是多麼得重要，看著這樣的代碼連平日裡斯文的你嘴邊都不時會湧現出問候程序作者本人或其祖先的話來，原因就是半天看不懂是什麼意思！
更難以置信的是有些自已寫的代碼幾個月之後竟然也一時半會兒看不懂是什麼意思！
科技灣區
一 解釋自己寫這段代碼的作用
二 解釋為什麼自己要這麼寫
三 如果別人要調用這段代碼，有什麼需要注意的
張同學的技術分享
程序是寫給人看的不是寫給機器看的，增加註釋會使程序的可讀性更好
