这边怎么老是吵著小孩子头上有几根毛的问题。
说不用注解的，都是英雄主义作祟，自己因为自己的程式码天下最简洁易懂，这种看不清
自己的人还挺多的。
团队合作就是要注解，除非你不在乎团队！
你以为大家都是你肚子里的蛔虫？
我光是写一行code：
key = salt + DateTime.Now.AddHours(-4).ToString(“MMdd”);
就会一直有人来问为什么要这样写，-4什么意思？
最后我加上一行注解从此耳根清净
// 厂商要求每天清晨4点以后要更换加密金钥
大家讲了半天，注解只有一个缺点，就是过时美人维护。而我认为这才是真正该教育改善
的文化和心态：不是我写的注解，所以我没有维护的责任。
这才是真正的弊端，而不是倡导clean code。
一个连别人的注解都不愿维护的人（更糟者连自己的注解都不维护），你期望他修改别人
的function真的负起什么修改的责任？function功用变了，他回去改function name 然后
把呼叫到这个function的所有程式码都调整过？别傻了孩子！
连注解都懒惰不维护的会跟你搞refactoring？
用不写注解来解决注解过时或错误的问题，根本“掩耳盗铃”嘛！
更何况注解带来的利益，用遇到几个误解的注解，就想要全盘否定，根本以偏概全。
还有一种注解我也常写，我这边的解决手法参考到什么google 解答，我会把blog or sta
ckoverflow 的连结放在注解内，让后人知道这个解法的思路怎么来。
团队战不是给这些自命清高不写注解的小孩子们玩的！

光看一个独立的数字，就知道为何你需要注解注解不是罪，但是有更多自带注解的写法，可以省去维护的心力，例如这种孤独的数字，应该先define再引用

推

-4你可以先用有意义的名称define起来...

像是7-11

美人维护？？？

大家可以说说会用什么字眼去define那个-4，可以让我免除那行注解？我觉得怎么define都不如我那行注解简单扼要

#define MinusFour = -4

楼上我笑了

#define customersayotmustchangeevery4hr=-4

楼上define误解后人喔，每天清晨四点不是每四小时喔。

这篇把为什么要注解写的超好用DEFINE也没注解那一行好

AddHours(-4)很难马上看出来 我会放在function里或是类似key = shouldReset() ? getNewKey() : key然后把厂商要求那段写在shouldReset()的block注解

timeOfChangingKeyAsHourPerDay = 4; addHours(-timeOfChangingKeyAsHourPerDay)这样呢？

不管要不要写注解，都该尽可能让程式码本身可达意

结果你自己就是你骂的那种人啊～ 不写注解自以为屌 弄到一堆人来问才加注解 话说你应该是要命一个好的名称才是 但真的想不到 最少加注解 没关系 尽力就好

就这篇功能的意图，key可以改名dailyKey，-4可以define为renewTimeOffset之类的，当初如果这样写可能不用补注解也不会被烦

楼上的例子也不错

像这种东西，应该写在commit log里面啦，大哥

#define SEVENELEVEN = -4

if now >= 04:00 不就好了..是要define什么?

这是典型magic number...

这个怎么会写在 commit log…一眼能不能分辨差很多好吗

Commit log是让你写故事的啊，厂商要求这种东西就是一个商业故事至于你代码要写-4 +4 magic number define等等，那千奇百怪，延伸就更多了

Magic number 赞。写 commit log 让后人用 blame 去查前因后果。

我笑了 写得这么烂的话真的一定要注解不然真的没人知道那-4用来干嘛的

这种可以写在config 注解在config就好 改也方便

天才小钓手是你

典型的magic number我会用changeKeyEveryDay当function名

MAGIC NUMBER.....code smell

笑的人要不要把自己的code贴上来，让大家review，自以为屌？

这个例子很好啊，有些case写注解是最省事的资讯传递方式这个不大能算Magic number，实务上很多case必须这样搞...尤其在商业逻辑部分很多东西用程式角度来看是没有逻辑的这个例子你变量再怎么命名都不会比加一行注解清楚的...BTW, 这篇的第一句话跟我对这个版的感想一样...:p

典型的不会命名变量只好写注解

结果某次commit有人把数字改了注解没改 然后接手的直接看了

推你这篇，说不用注解的人真是自我感觉良好

注解就当成清晨四点往后写逻辑 然后就.....XD该写注解的地方当然该写啦 但我觉得比起写不写注解更重要的是 注解你要写 你就要把它当成code的一部份 要改code就是要去改注解吧？多少人有只改code 注解却没改的恶习？

连注解都不想维护的会好好维护变量命名...这我不大信...

写code的人百百款阿 变量命名已经是普世价值 再白痴的也会稍微注意 但维护注解动机可就不像把变量命名好这么强烈而且有时也根本是案子一忙一急 注解就“忘了改”不是不改喔平常都有改只是这次“刚好忘了” 阿就是一堆刚好忘了 才造就不可信任的注解啊 XDDDD还有一个副作用就是信任度的问题 只要有几个地方注解跟code对不起来 会导致你日后再看这个专案时 不信任上面的注解所以一切还是要回归到人自己的责任上

写Magic Number的烂扣也敢推上来看啊

这篇好笑 拜托你这种人一定要写注解

小朋友爱写hard code,还好意思说什么耳根清静...

你的确蛮需要写注解

这例子明明注解比define好商业逻辑这么多 每个常数要一个个都def 傻了吗

这个例子我觉得写得不错有时候这才是最好的方法能解决问题的就是好方法

还好我不是你同事 不会写扣去种田-4这种magic number到处乱塞

这种设定性数字应该写去config了 ，hard code害人

要一直开commit log来看也太累

这个例子是你原本就写的太烂

config写在code里 贵公司哈哈哈哈哈哈哈哈哈哈最好笑的是这篇就是自介文

自己扣写这种程度也好意思说别人吵头上几根毛

真的 config别写在程式，不然改个设定还要重新编译

完美示范Magic Number!

哇，人家是年薪300万耶，靠剪贴剪出一片天，在板上发废文问大家会不会在公司打手枪，(然后被版主水桶)。顺便呛翟本乔技术再强又怎样。呵呵，继续放著这篇，别删文给信徒膜拜吧

对！还没专文批一下翟本乔！感谢提醒！

写code功力令人佩服...

所有这篇的错字要不要维护一下？

Magic number

这篇十分工程 比板上嘴砲强多了

推

拜托你写注解

推

推这篇~这才是现实情况

商业逻辑是超脱程式的东西 毕竟不写出来谁知道啊

我个人认为-4应该写成变量然后用个好的命名