這問題的背後是沒有答案
但我們可以根據目前世界一流的repo 來參考
絕大部分的世界級的framework 包含 linux
專案裡面都一定會有註解 只是註解多 或 註解少
其中讓我最喜歡的 專案大概是 laravel 連註解都寫得很藝術
我自己是贊成部分寫註解 而且要寫清楚
當專案架構越來越大 開發的人越來越多
尤其是 -> 功能越加越多
上頭 隨便天馬行空就來一筆 OOXX 的需求
( X的！當初為什麼不講，現在要怎麼弄 )
不太可能沒有技術債的產生
有時候因為時程關係 / 前人留下的技術債 / 上頭的天馬行空的新需求
有些地方是牽一髮動全身
雖然明知道最好的辦法是 某feature全部打掉重練 但是 整個重寫至少2個禮拜
照現在的邏輯下去寫 2個小時 以先解決的目前的ticket目的的前提
會讓你陷入一個 就算名稱取再好
你也無法講述清楚的情況
所以這時候寫註解 可以省去後來維護的人 或 幾個月的自己
方便快速地進入狀況
這時候 我是贊同寫註解
非此情況下的註解 我會比較希望看到 整個全局的概述 而非 單個block的論述