饿死抬头
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完没改注解更加糟糕欸嘿