看板
[ Soft_Job ]
討論串[請益] 寫註解到底是不是好習慣
共 24 篇文章
內容預覽:
這問題的背後是沒有答案. 但我們可以根據目前世界一流的repo 來參考. 絕大部分的世界級的framework 包含 linux. 專案裡面都一定會有註解 只是註解多 或 註解少. 其中讓我最喜歡的 專案大概是 laravel 連註解都寫得很藝術. 我自己是贊成部分寫註解 而且要寫清楚. 當專案架構
(還有356個字)
內容預覽:
個人淺見. 註解是可恥的. 代表你程式不夠乾淨. 變數 函式名稱詞不達意 只能靠註解補完. 最近手上接到外包的程式碼. 有一個核心處理封包差不多200行程式碼. 裡面做什麼呢？. 他有好心寫上註解. //處理messages類型 A. .. .. .. //處理類型B. .. .. .. //...
(還有500個字)
內容預覽:
先說結論：註解必須寫，除非 code 太過簡單。. 我不相信有「看得懂的命名」這東西。. 哪怕是我現在全部寫中文，發到網路上，. 只要字數多到一個程度，就會有一堆人看不懂中文表達的意思。. 更不用說是程式碼。. 連命名都看不懂，就更要花大量的時間去釐清整個 code 的邏輯才看得懂「寫什麼」。. 看
(還有1903個字)
內容預覽:
這是個封閉式問題，意即非黑即白。. 理想的情境：程式碼的命名 "都" 能被清楚的解讀。. 理想的情境：記者寫的內容是客觀的. 實際的狀況是：理想通常支離破碎 XDD. 實際的情境：程式碼的命名產生的過程，因為有：. - 時程壓力. - 需求不清楚. - 業務亂喊時程. - 貴司跑敏捷, 所以不重要.
(還有539個字)