餓死抬頭
https://i.imgur.com/3QcIsVN.jpeg
本魯不是資工系的啦
所以不知道寫程式不加註解會有多嚴重
想請問相關從業的鄉民
實務上遇到這種情況真的很賭爛嗎
乾五西恰

不加註解的一定是超級有能的傢伙

這就一樣兩派人士在吵啊

超嚴重，因為幾個月後會連寫的人可能都看不懂

前提是code寫的讓人看不懂，還不加註解

接手的很麻煩，要多花時間理解

還有只把註解當分隔線用的XD

大概跟大便不沖水一樣的等級

歷史本文

看複用性

寫的爛又不註解的真的該死

就算是自己寫的也可能幾個月後看不懂

我自己是沒意見 看主管(

不一定 要看是不是寫垃圾

寫得好就不太需要 太多註解反而更難讀

比註解寫的像日記隨筆的好一點

更慘的是註解沒有維護的 地獄模式

函式參數名稱取的有其意義也算是種註解

連自己都不一定看的懂了

除非你的變數名稱取得一目了然

我直接給你一個題目 a + b = 5然後告訴你 a 和b都是一個正整數 而且在設計者心中是一個唯一解。就這樣

不是，是註解內容與事實不符，成年累月不刪的錯誤訊息誤導

這垃圾是誰寫的，喔 是我==

寫得極好可以不加註解 這是真的不過你們這些庸才不要隨便就自認為寫得很好嘛

看可讀性 像變數都命名無意義a,b,c的不加註解就很糟

寫得好其實不需要太多註解把說明文件寫好還比較重要

好。請問。當你急用。必須知道a b是什麼時。你會不會很

會不寫註解，八成是是能力很強的g8人= =

顧不顧人怨先不論，一個月後你就會恨自己了

也有這種大家都苦笑的案例https://i.meee.com.tw/T24DsDn.png

註解不改版的才是==

都要2025了誰還寫註解

what the fuck? 笑死

現在PR如果是我當reviewer 除非是連白癡都一眼能看出來

我覺得比較需要註解的註解

不會

認真說的話，在團隊合作時，寫的code讓別人能看懂是你的責任，但你不一定要用註解的方式

你看推文不就分兩派了XD

現在有了LLM之後 程式碼的註解用途比以前更多了

會分不清abc幹嘛已經不是註解問題了，而是他媽不要用abc

自己都會忘記的東西 要給別人猜 試著理解你當時在想啥

跟投影片只貼圖一樣靠北

寫的好的話還不算太嚴重

真的有註解焦慮就請copilot幫忙寫就好

看老闆在不在意

確實是寫得好就不用註解，但如果是長期營運的專案，很難全部都是好code

很多時候註解不是只是寫 還要人看得懂

現在看你可能覺得自己寫得很好 但十年後你再看可能至少要花半天來重讀 回想還不夠惹人厭哦

確實是寫得好就不用註解 <--- 這句話本身就不可證偽幹話

註解寫得不好 確實會讓你解讀錯 也是個問題

看情況，就算你真的不想寫也要把變數名稱設定好

最爛的是code改了，註解還沒改，草你媽

我有在註解裡連載過偵探小說

print("hello") # 印出 hello

PR送出來的時候 幾乎是唯一你有機會要求撰寫者解釋code

爛code+錯的註解比單純沒註解更垃圾

改了程式註解沒改更痛苦是真的 一個誤導可能一天就過去

不加註解讓其他人看不懂 這樣公司也不敢炒你

clean code 第四章就是在叫你各位別寫註解了

大概跟聯絡簿不簽名一樣

"這之後會寫個詳盡的document"=謊言

你如果變數名稱取什麼a b c i j x 三小的 最好就給我寫註解

你之後自己也會看不懂

不下註解我隔週就忘記我寫了啥 哭

commit log有寫好就好

不只是寫code的會需要註解啊，有些管線配得超複雜的又不加個標註，真的下個月就忘記是幹嘛的了

除非有什麼特別的問題要提醒 不然正常都不寫的吧

尤其是一堆magic number 又不寫註解為什麼這邊要帶入100 那邊要帶入3000 最後就是一直在通靈程式碼

不寫註解一陣子後，連作者都不知道那段程式是在幹嘛的

要有改版紀錄，就算別人不看code，也要知道改了啥

AMTS: 把說明文件寫好還比較重要 <--- 註解都寫不好的，

要加寫註解，那簽薪水合約也要該加錢

what the fuck那個案例，經典之處在於那是一個超級棒的變數搜尋起始值，但又不是數學上最佳的 (有一點偏差，但也夠好用了)然後寫的人沒說他是怎麼找到這個值的 接手的也問不到

註解OK，但我覺得code以外的東西像是文件log啥的有寫清楚我覺得比較重要

至少節省人家看懂你在寫三小的時間啊

命名真的難 寫詳細就很冗長 簡寫又最好另外加註解

商業機密

如果是給自己看懂的註解那其實就不是註解，是自我提醒而已

寫說明文件這種事情，只有 騙子 和 菁英 在講

不寫也會害到自己吧 寫了幾千行後自己也會忘記

最好的code是能直接看懂 但一般人就給我乖乖寫註解

陳年code最快樂的是註解一堆都跟code合不起來

PR Approver還有立場要求對方寫更多註解；程式碼送進去

現在應該沒什麼差了，直接丟AI

Repo之後 她不爽寫文件或註解你絕對沒輒

可是快速反方根算法是真的就只能那樣寫啊 而且那東西就算寫了註解也未必一般水準的工程師就看得懂XD

他這邊不是講寫死代碼嗎 想講hard code那種的吧

覺得可以完全不加的真的有在寫嗎 久了你連自己寫的都看不懂

公司祖傳屎山代碼不加註解，敬請見證

能直接看懂的code本身就不是什麼大東西，上萬行的你看懂要多久

變數寫的很直白就沒差 最哭的是全用a1 a2這種的

不寫信不信一個月後回來看連你自己都看不懂

what the fuck那個是較低運算量下求得足夠有效的近似值吧

現在可以叫chat gpt幫你加

什麼一個月 六日放假回來就不認得了

當然模組是一定要寫這是在幹啥就是了

#我前面的都沒寫 我當然也不寫囉

現在有不少AI工具是可以讀了你的repo之後扮演像小幫手的身分回答你很多廣泛問題。這種有沒有註解就會差超級多

到時連自己都看不懂就好笑了

足以放進柯南世界的殺人動機

沒有註解的code，AI就只能給些罐頭回答你一個 enum class 註解只寫一行或不寫當然無妨啦

不寫的話自己都會忘記個八成

我看過註解英文文法爛到看不懂的 也看過非ASCII註解然後亂碼的 歡樂無限

現在AI可以幫你生註解

有時候有問題的不是邏輯看不懂，是為什麼要有這段邏輯

我在弄公司老舊程式的CODE 一堆糞CODE不註解

有兩派 一派是命名的好的不用寫 另一派是最好給我寫爛，我覺得加減都要寫，有些寫死在程式裡面的 還有歷史故事 最好都留著，免得到時候要考古

自己寫的不加註解你離開半年再碰都不知道自己在幹啥

寫得好就不用註解的標準是啥?一堆自以為寫得好的

現實公司就沒有真的在提倡把code寫好寫到不用註解的你要用這個藉口不寫註解，到時候在公司天花板飛來飛去就不要該該叫

設無意義變數讓後面的猜

這個看能力分階段耶 寫的好的確不用太多註解也能看懂

AI現在問題是，你不太懂的，AI也不懂時會瞎掰唬的你以為他講的是正確的吧

你們別再瞎吹AI惹 新進來的搞出一大堆炸彈 被炸死還

不會 能力差的才寫

上面那個邏輯可能跟一些老舊硬體有關 這種又更痛苦了你不測根本不會知道

資料庫欄位不寫說明才頭痛 名稱看不出用途只能通靈

不太可能完全不寫 就大概寫一下這段程式在幹嘛就好

自己寫的作文 會自己加上注釋嗎？

你有自信一年後還看得懂的別人基本上也有機會看懂，這樣不寫當然沒關係

code和作文等級不同 code是一種魔法

不註解變數名又亂取的應該要被抓去關

所以寫CODE並不是同一類功能9成一樣套公式的東西嗎??

實際上是看情況 很多code是顧名思義的在寫

有的BUG是兼容性問題，這種可能就沒有啥原因邏輯，因為

code 不是作文 註解才是作文

因此還需要加上註解才看得懂?

配合的程式、裝置就是這樣搞，也只能特定方式因應

傻了嗎？ 註解是給自己看的，給別人的都是鳥註解

一堆莫名的邏輯又不敢去刪除他怕是有用的

現在都丟ai看了

只在一個層面上做單純一件事的code是這樣但現實在跑的code可能是100層疊起來的邏輯運作

自己寫的都不一定看得懂了更何況別人寫的

真的，很多商業邏輯很複雜，文件也不見得齊全，接手的人真的很痛苦

//企劃說要這樣做

幾百行變數名有寫直白是能不用註解拉 可是超過這數量

複雜的真的需要註解阿，主建構者都不一定記得全部的細節了，其他的更不用說

你傳狀態只用數字，不寫註解就是在浪費之後接手的人的時間

/*我不知道這幹嘛的 但不要改這個變數 */

有一種直白叫做自己覺得直白

寫死還不註解，超欠幹==

後幾乎都是分成一堆一堆的模組 這時候還沒註解就GG

註解是寫給自己看的

更恐怖的是寫這100層的人都有可能寫出「code實際上會產生但寫的人渾然不知的嚴重後果」

有時候加註解的code才是更坑人的 有些人改完功能沒改註解...

你到火車站沒時刻表也能上車阿，沒毛病

寫爛又不寫註解的人不該寫CODE，只是來拖累其他人

寫得再好也怕疊床架屋阿，該駐就要駐

程式就是文件，一個人寫文件都用自己發明的詞彙然後都不解釋，你感受看看

寫死或是magic number的碰都不敢碰

註解寫爛 那PR的 Reviewer要叫她改啊 不能看不懂還送

不過圖中的例子的確是最欠幹的 寫死不註解是最可怕的

你有沒有要給別人看？ 沒有 那你記得就好 有 那你不想被問到煩還是被靠杯就乖乖加 將心比心一下

西恰到底是有多少工程師

以都給WINDOWS用的來說好了，難道不是詞彙都規定好的

先求有註解，再求讓所有人都可以看懂

會被修改的東西才有寫註解的必要，使用說明那種該寫的是文檔

辭典之類的東西下去邊寫作文的嗎?

後面：前面的不寫註解我接手很難懂

//以前我跟上帝知道這是啥，現在只剩上帝知道了

當限制來自沒有道理的業務邏輯時 不註解別人根本不知道

寫的好其實不用註解也很好讀，大部分情況都是寫太爛太複雜才加一堆註解

如果你明確知道問題只出在第89層，你可以把寫的人叫出來電，但實際的狀況是裡面可能有10個你根本不知道位置和觸發方法的問題，而且這整坨東西已經在市場中客戶手上天天執行，這時你能相信的只有某島國零食了

//這段沒用，但是刪了會error，別刪

檔 不能沒有 註解

任何的code 都有可能被修改啊

你看得懂別人作文全部的邏輯嗎w

你是在windows給你的架構之上做事沒錯，但你自己要做的事情可能就有100層邏輯了

沒註解還可以硬讀 只是很吃力 沒欄位文件的超級靠腰...

前提是Code本身寫得有可讀性但偏偏一堆ninja code卻又不註解的

只要這隻程式你過好幾個月回來還是看得懂，或是別人看得懂，以這個概念來說，你要不要寫註解就沒那麼重要，重要的是未來看得懂

寫code不註解，連未來的自己都會詛咒你

但未來的事，沒人能打包票

我個人只會寫 為什麼要做這件事的註解跟誰叫我改的

我覺得寫註解像是英文作文寫的太差怕人看不懂所以還要附中文翻譯一樣，如果你英文寫得清楚根本不用中文翻譯維護註解等同於維護兩倍的程式碼，最多就寫程式結構或思路就好

會被修改的東西才有寫註解的必要？？？除非你敢確定debug時不會碰到

另外一個問題，如果windows現有的架構有會導致不確定性結果的bug，請問你是要用你全部的上班時間打電話去微軟靠夭，還是夾緊你的括約肌，把眼淚吞下去，想盡辦法頂著這個bug還能把你的工作做好?

涉及到計算方面的，再怎麼好讀回頭再看也記不得為啥要這樣算

加註解可以讓原作者和其他人看得懂

我認識的不寫註解又寫得很難懂的，大多他的CODE問題多

可讀性夠高可以不加

只能說 有多少屎山代碼證明了那些覺得自己寫很好的都……

註解沒更新的才哭 跟code對不上

///記得刪掉

code夠好不用寫註解 跟很有錢買東西不用看價錢一樣

註解是用來記錄違反常理的事情 有些事情不是自己可以決

Kiri大的解釋利好血汗但又真好懂XDD原來是這個意思

//這邊先這樣 之後再改 去你媽的 之後是什麼時候

看狀況 完全不加 要交接很難 通常命名會很清楚 怕的是abc void a(x) 這種天才

實務上真會出現a,b,c這種變數嗎?這不只寫的人要被幹吧

那種亂命名來搞的 公司哪會讓你merge進去

有一種好是自己覺得好

我做過6~7間公司 能讓我覺得寫得好不用註解的人沒幾個

我的話 閒的時候會把需求寫進去 忙的時候只註明magicnumber的由來跟用途

超內層為了加速運算而寫出的小函式可以允許

就懶阿 反正也沒人會看

這個真的要寫

你要先確定公司有review欸(

不過ijk這種有的是用在很多層的迴圈裡吧

你以為所有公司review都會看那麼仔細嗎？

4，不寫連你自己都看不懂自己寫的

很多公司不是能執行就過了嗎，誰會逐步執行一行一行看

中大型公司review至少會有一定的程度，那個真的有用

未來的你會最恨你

小型的就....你覺得鳥的程式會給熊review嗎 當然沒有

未來的你：我當初寫這段是要幹嘛的？

當然不會一行一行看啊 但這種一眼瞄過去就很明顯

不懶就注一下 別人在看才會比較輕鬆

當未來要debug的時候確實是那時的你最恨當初的你

大家都把濾網捅破還裝沒事 那就大家一起死

我覺得註解最需要的地方就是接別人爛CODE又沒時間重構的時候 已經花很大力氣好不容易看懂了 一定要寫下來到底在幹麻

有的公司連git版控都沒有，這版改了什麼還要自己diff

本體盡量寫好 註解只在必要的時候寫就好 不然改code連註解也要一起改也是很麻煩

Clean code

維運到20年前的糞code 就知道有多開心了 有註解至少知道需求是什麼

別再說寫的好不用加註解了，每個人都嘛自我感覺良好認為自己很會寫很好讀，我帶的案子看到一個註解都沒有誰管你寫什麼一律抓來噴

大公司對程式的要求不是像什麼書本上的美妙範例而是一些類似軍事管理的要求要所有人遵守除非你就是想跟所有人對著幹 否則就乖乖遵守就好對程式無規則要求的職場不會比較好玩

不加註解是要人家通靈喔

跟配線不標示線號一樣嗎

淦你不寫註解數年後回來修，你看得懂或跟別人解釋當時為什麼這樣寫，你就可以不寫註解

// 客戶堅持要這樣做

學校時，課程作業會把clean code當評分標準嗎？還是答案對就好？

真的 不加註解真的讓人不爽

學校的程式作業 註解都馬是交給助教看的 出問題重寫

學校一般不太會管 因為這個給公司電就好

可以啊 你就永遠不要讓別人維護 跟自己永遠看得懂自己在幹嘛XD我自己上個月寫的程式我可能就看不懂這什麼狗幹邏輯了

text-align: left; /* 客戶說要偏右 */然後你就不知道是客戶又改了還是註解漏改

真的漂亮到一看就讚嘆的code是有可能存在的可是你的無註解code就是被噴了啊 那就是不夠漂亮嘛

不加 幾個月後來看自己也看不懂了

// just magic

學校的程式作業不會多大且目的明確，不寫註解其實也還好

當下的你：這段帥爆了，不用註解也知道在幹嘛

會動就好

所以才需要reviewer啊

變數名，函數名，class名都取的很標準的，可以不寫或寫很少，但一定規模以上不寫幾乎不可能

可能會有這樣的狀況text-align: left; // 不加的話頁面垂直對齊會失效哪個人敢刪掉這條註解就給我刪看看

不加註解，過一段時間連你自己都看不懂好嗎

基本上好的程式看naming要能看出大部分，複雜的才要特別寫註解

註解還好，程式夠乾淨、名子別蝦雞巴取都還看的出來，一個泛型當戰神用才討人厭= =

code review真的不是騙小孩的笑話，它真的有用

學校作業一堆連排版都壞七八糟

不加註解只有神或廢物，廢物占99%

有寫接手交接所需的時間比較少，但一般取名取很差的，註解也寫的很差

不過寫嵌入式系統資源有限之類的，有時變數不能用太多，

以前code review我還覺得"幹 怎麼一直要我寫一堆註解"

曾經覺得隨手寫個小程式輔助用的就不用加註解了

新人剛進公司的code被評價為矮噁是很正常的不用灰心，遵守規則就好

不怕沒有註解，就怕亂註解誤導後續接管的人，整組壞光光

可能會一個變數多種用途吧

code很好不用寫的通常就是……

行業標準的註解就去看自動生成文件那些怎寫就知道了

肉便器代碼 用過一次就不理的話可以

// 敝公司碼農領的薪水用行數計算

寫得爛還不承認的最爛

漂亮的程式碼不等於容易看懂的程式碼反而容易讀懂的程式碼 常常是過於冗長打個比方就是好的程式碼就是一個漂亮的公式簡潔又高效沒看過證明 你是要怎麼了解公式怎麼來的？你不了解 怎麼客製優化和調整參數

除非一看就知道在幹嘛，不然還是寫一下吧…半年後自己都看不懂了

不加註解我連自己1個月前寫的code都看不懂..

你不寫可以 但你不要給別人review

不寫註解= 小組組員問你問題你已讀不回

沒啦 已讀不回應該是 github上面人家留comment你直接啥都不做就按下 resolved這種很容易起糾紛的

一個月後可能換個project就想不起之前在趕嘛

不註解就是後面自己或者接手的人完全看不懂

不加comment真的有夠夭壽，後人還要通靈通個老半天

看你寫的code好不好懂 但不管再怎麼會寫code的人

這跟在萬神殿問到本子名的瞬間就刪文一樣惡劣嗎

跟好不好懂沒有關係啊 你開一個新的class 在我讀程式碼前就該有一段文章在描述這class是幹嘛的而不是我要讀了程式碼之後才知道你在幹嘛

有型別的語言問題小一點

現在有 Copilot，寫作文比以前方便多了

中心思想就是：好好做個人，讓別人能看懂你的code你要每行都註解還是把87%註解集中在關鍵處就看你反正別人能看懂就沒事，看不懂就一起浪費時間

那看是什麼語言 有必要的話我就在file name跟class name把這個class是做什麼的直接寫完了

你一個class做的事情要用500字來寫不就代表class太大了...

那個比較像document，但順手寫成註解也可以

document這個東西我想都不敢想了

// 因客戶說他老花眼一直輸錯認證碼因此需要把輸入的值1=I=L，2=Z，5=S

clean code 的許多準則很好，但不是絕對準則，許多跟算法

我上面說了 嘴巴上說會寫document的 不是精英就是騙子

會加但不會有很多 通常是特殊情況會解釋一下 一般來說你的程式碼本來就該寫得讓人看得懂 不然review 怎麼可能會過

那你覺的這是一隻狗算不算講完他能作的事情

但很複雜的多個class我就直接寫module REAME了*README

除非那個 code 沒有其他人要看，而且你自己的記憶力超好，不然即使自己用的 code 都該為了未來的自己寫註解

當你看過註解和程式之間的走向完全不同的時候你就會有另

自己都看不懂還不加註 不就找自己麻煩

@kirimaru73 不算 你還要告訴我為什麼這裡有吃狗 要幹嘛

一種看法了

自己寫的code大概半年不碰就會忘光了 一定要寫

我也沒在寫註解了，乾淨架構下去，然後變數跟方法命名寫好，基本上看得很清楚

那些我就會直接寫在class Dog的上面了 應該和你期望的一樣

clean architecture有幫助 但不是萬解

某種意義上 寫註解就跟買保險很像，這個東西就是盡可能避免未來某一天「幹!!!這到底是三小」的機會但也可能最終發現註解寫得不好所以沒有用但絕對比不寫好得多

我自己的判斷方式 只要nested到一定程度(3層之類) 就一定

問題不是這段在做什麼，而是為什麼要這麼作

要寫 不然不熟的人絕對浪費時間看

重點把是你的架構訂好，依循著架構放檔案，各種依賴跟參考都有照著規則比寫一堆狗屎註解重要

這個本來就是分兩派好嗎..

大型project最後都難免變違章建築

以前教授說他都寫德文 不想給別人看懂

這年頭lint都會檢查啊 即便如此還是有可能寫得很複雜

不加註解自己也會看不懂吧

不加註解，我還真的無法一瞬間看出來在幹嘛

一個月前的自己:自己寫的一定懂 一個月後的我:這段是啥鬼

自己的程式加註解都要思考幾分鐘在幹嘛了，更不用說別人的我相信世界上有天才不需要註解，但那個人絕對不是我

比不簽聯絡簿還噁心

有一派是code好不用註解，但現實通常是隨時間跟經手的人變多gg

看你的程式別人需不需要用，需要的話還是要註解

雖然取名能解決很多閱讀問題 但註解可以直接省下這些問題，特別是遇到取名new或是obj的人

還有一種是註解裡故意埋炸彈給接手的垃圾

自己寫都不一定知道在幹嘛，一定要加註

寫code的動機是“客戶說”那就註定好不了。乖乖把“客戶希望能夠1+1=5”寫在註解上

不加註解死全家

不寫註解一樣能埋炸彈特例就別說了

看過一本講refactor的有提到盡量不要寫註釋，只有特殊情況才要寫

一堆亂七八糟的調整都嘛是來自“客戶要求”，別想會多好

//呃...就命名字面上的用途

除非整個團隊英文能力都很好，不然clean code的意思是變數與函式的命名要清楚到能直接看懂程式的意思

我同事兩百行code有一百行是註釋不知道在衝三小

這個問題其實很簡單 現在回去翻自己幾年前寫的 測測自己不看註解的情況下要用多久能全理解

當然有些特例 像是寫random但實際上有加權時就要註解

除了註解本來就有很多地方可以記錄資訊啊 你commit msg也是要寫清楚 clean code就是追求程式碼本身就是註解 function跟class名稱都要有意義

但大多數人連命名都亂七八糟的

我是覺得可以讓命名、結構易懂比寫註解重要，不然程式

有時註解反而在騙人 不如專注在把命名做好

寫很爛又沒註解 就王八蛋

看不看得懂是一回事 寫了是幫之後看的人省時間就算code寫得好懂 每次重看也是浪費時間

有自信永遠不帶給自己和他人困擾就別加，我連一個月前自己在excel寫的VBA 都可能看不懂

註解寫了也要記得更新 改code不改註解寫心酸的

Chatgpt 都會寫好註解

自己寫的都不一定記得了。

我看現在大師的說法是追求程式的可讀性要高，夠高的話不註解也很清楚

我都有git了還註解啥

真的寫到很簡單根本不用註解

除非你是那種Code可讀性極高 誰來都能馬上理解的神人

不然就build script最後加doxygen 沒寫直接build fail

有很多地方可以放解說，不需要都寫在註解

commit msg跟README還有design doc都可以寫

然後變數用ABCD1234不命名 爽不爽

命名就知道是在幹嘛了 幹嘛還要註解==

對 超級

寧願加註解也不要相信自己看得懂自己的東西你自己寫的日記都有可能不知道你在寫什麼更何況是代碼

有的流程、特殊邏輯，變數跟方法命名都無法表達的

回頭看自己三個月前寫的東西都有可能看不懂了

其實不會

2025還有人把clean code當聖經 幾年前就戰過了

寫代碼不加註解。就算只有自己會看也是一段時間連自己都看不懂

寫得再好也不可能理解起來比註解還好吧，註解都亂寫的他程式會好好寫嗎...

超多的好嗎 超討厭

寫註解就是要告知這坨大便是什麼原因產生的啊

真的很賭爛

看你是當個人日記還是出版書籍來寫啊，只是個人日記過幾個月連自己都不知道在寫什麼了

對耶 註解寫得好的人那原始碼應該不會爛到哪吧

issue解一解 忙了半年之後回頭過來看 就忘記我在幹嘛了

三個月後自己看都忘記了

這麼說好了，寫出易懂的程式是一個理想；但現實是不可能完全達到的，不管是有特殊邏輯，或是寫的東西並沒有那麼好懂。一定或多或少要有註解輔助其實註解寫的好不代表原始碼會多花，我遇過一個leader註解寫很勤且很多，也要求底下的人照做；但我接手他的code後改到快吐了*多好

偏底層的程式要搞加速或省資源的時候就管不了可讀性了

有時候註解說的是一回事，程式碼寫的卻是另一回事，所以註解真的比較好嗎？

不用三個月 忙一點同時兩三個案子 下個禮拜就忘了

其實，真正優秀的團隊，是真的不用註解，含在design pattern惹..

各種惡用巢狀迴圈，即使裡面寫了滿滿的註解，我還是很難修；最後我就直接打掉重寫了

遇過資深工程師意見超多+話超多+文件超長，但是一半左右是廢話的

無註解是比較理想化，實際有些東西還是要註解會比較清楚

你兩個月後回去看自己的程式就差不多忘了

不可能無註解比較好啊 你有註解你的程式碼我不用全懂

實際上一定會需要註解，大部分是用在special case or workaround

連自己都看不懂

搞底層韌體有時候會需要計較這段code怎麼寫編出來可以少幾個指令或多少RAM 這種不留註解沒人知道你幹嘛這樣做

這串吊出一堆寫扣大佬

我自己寫程式也是偏向少註解，因為用code說話比較好。

4

我自己是無法理解自己看不懂這件事啦,可能我的思考迴路是基本很難變動的那種

現在有LLM其實也沒差了我覺得

自己寫得看久了當然會看懂，只是你要花多少時間去看寫註解可以幫助自己回想的快很多

對阿 懂不懂是一回事 主要是省時

我公司就是喔 主管還自以為code寫很棒

說寫Code不用註解的，都是待在同事都是高手，離職率超

有些狀況是寫理由 看得懂code也不一定知道為甚麼這樣寫

超靠北

大神寫出來的就算加註解一般人也看不懂 邏輯完全跟不上

我待過沒Code Review的公司，接手離職人員的專案，我只想寄一箱手榴彈去問候他

本篇講的就是寫死的，寫死又不留註解，後面接力的人大家都要當通靈王

如果有workaround 或是 複雜邏輯 沒加就垃圾人

就像你創出一道菜沒做筆記某天上了菜單 別說要同事復刻連自己都不一定記得調味的份量

TODO 需要增加註解

改code完沒改註解更加糟糕欸嘿