比如我，代码里面如果需要用到人造的随机数、魔鬼数字等，我会把它写成自己的生日或者他的生日，32 位整数的 16 进制 0x19980101 这样，位数刚好。
或者在注释里面放一尊佛像啥的。

感觉部分批判的人没理解啥是“魔鬼数字”，32 楼说的就是这个意思

98 年的真会玩

一般这个问题，都会问一句，难道你们是没有 code review 么

98 年的真会玩

98 年的真会玩

HoHoHo 是吧

我恨不得，让别人永远不要发现这是我写的代码。。。。。
你竟然还想着留痕。

98 年的真会玩

我的 bug 就是我留的彩蛋

公司的没有，写好注释就行了。
写自己个人的项目，会留下彩蛋，自己个人项目都是仔细打磨，精益求精的。

// do not comment this
// do_something();

公司的项目留彩蛋是不是疯了？ code review 要是作为 issue 报给 compliance 或者 security 还混不混了。。

前端同事 var 了好多个 cnm 变量 。。

公司请你来是干活解决问题的，不是让你展示自己的。我要是老板就不敢要你这种程序员，今天留彩蛋，明天不知道留什么东西进去。个人项目随意留。

这些彩蛋不影响功能和安全性，选其他数字也是一样的啊

// 这块代码有 bug ，但是测试没测出来，我也就不管了，之后复现了，谁改就当发现个彩蛋吧。

// 这里也有个彩蛋。

// 这里有个恐龙蛋。

// 这里没有一个彩蛋，有两个。

// 好吧，说的全都是骗你的，这句也是。

上次圣诞留彩蛋的惊喜不

我们有个项目里，有个小人在马桶上拉粑粑的图...启动的时候会在控制台打印出来。还有一句话：Don't shit in the code

不会，有什么用呢？

微软谷歌的代码也有彩蛋，百度的也会
code review 如果只关注格式和语法规则，纯粹是浪费时间和内卷

一般这个问题，都会问一句，难道你们是没有 code review 么

记得上次圣诞节彩蛋事情嘛

Ant Design 的故事还记得不

算也不算，我喜欢在句末留逗号，所以看注释就知道代码是不是我写的，

Ant design 的彩蛋影响到功能了，但是像魔鬼数字这种对功能没有任何影响吧？

//
// oo0oo
// o8888888o
// 88" . "88
// (| -_- |)
// 0\ = /0
// _/`---'\_
// .' \| |// '.
// / \||| : |||// \
// / _||||| -:- |||||- \
// | | \\ - /// | |
// | \_| ''---/'' |_/ |
// \ .-\__ '-' ___/-. /
// '. .' /--.--\ `. .'
// ."" '< `.___\_<|>_/___.' >' "".
// | | : - \.;\ _ /;./ - : | |
// \ \ _. \_ __\ /__ _/ .- / /
// =====-.____.___ \_____/___.-`___.-'=====
// `=---='
//
//
// ~~~~~~~~~~~
//
// 佛祖保佑 永无 BUG
//
//
//

//
//
// oo0oo
// o8888888o
// 88" . "88
// (| -_- |)
// 0\ = /0
// _/`---'\_
// .' \| |// '.
// / \||| : |||// \
// / _||||| -:- |||||- \
// | | \\ - /// | |
// | \_| ''---/'' |_/ |
// \ .-\__ '-' ___/-. /
// '. .' /--.--\ `. .'
// ."" '< `.___\_<|>_/___.' >' "".
// | | : - \.;\ _ /;./ - : | |
// \ \ _. \_ __\ /__ _/ .- / /
// =====-.____.___ \_____/___.-`___.-'=====
// `=---='
//
//
// ~~~~~~~~~~~
//
// 佛祖保佑 永无 BUG
//
//
//

var sb = new StringBuilder();

[:/doge]

魔数就魔数，魔鬼数字是什么鬼......另外 code review 是不会允许留什么彩蛋的......

彩蛋没有，但代码里充斥着我自己造的轮子。

想过这种代码后来维护的人敢处理么？不是得一脸懵 B 生怕这有个什么特殊逻辑在那

怎么定义是不是彩蛋？万一是臭蛋呢？你一个人说了算吗？
怎么定义彩蛋在未来对公司的影响，你能 100%预料到吗？
别人接手你的代码，他看到这种代码，是否会让他感到迷惑，增加心智负担？

不要做这种多余而且徒增风险的事情。

说到 magic number ，有个经典案例： www.zhihu.com/question/271409373/answer/367796835

98 年的真会玩

代码嘛，留点属于自己的痕迹也正常

年轻人编程的心态就是不一样，想起了 10 几年前的自己，真好

把某款战机的部分代码里的循环 index 都写成了我的名字缩写

验签失败的错误码 418
所有用户未设置密码时，默认密码是我和前女友的名字，正好比可用密码短一位。

分享一个在 openswan 的 Makefile 里的彩蛋，你敲 make war 就会弹出 not love?

想着自己的名字可以一起跟着翱翔蓝天，保家卫国

完全不会。毕竟是公司的。

98 年的真会玩

单元测试里面有些地方需要 mock 参数会用自己名字和工号

梁静茹给你唱一首《勇气》

只有我关注到「自己的生日或者他的生日」吗

你这『魔鬼数字』是什么鬼？
magic number ，不是 demon number
魔法数字

IETF RFC 里一堆彩蛋，你们不还得照着彩蛋编代码？
HTTP 状态码 418 451

对于这种 magic number 的情形，我司一般都是直接用 commit 编号（单调递增的数字）

闲的蛋疼

会，我 own 的代码随机数种子都是 19260817 。

当然，review 的时候也是几百个 reviewers 一致通过的。

在前东家的 repo 里留下了好多 9527[手动狗头]

19260817
这个还是质数

逻辑漏洞就是我的彩蛋

好奇第一个把 magic number 翻译成魔鬼数字的是谁啊

开 jupyter notebook 的端口都是从 8964 开始开

前东家留下过 666 ，不过老美们并看不懂

谁还不时不时皮一下呢 :)

codereview 时不用解释这些数字么？

几百个 reviewers 🤯

这个算吗？

int timeout = 100;
while (timeout --> 0) {
...
}

不用

临时变量可能会用自己喜欢的车命名或者其他爱好相关的物件型号来命名（比如山地车的套件）
反正就是替换成 i a b k j 都不影响理解的地方会随便搞搞

我们一般只有主程才有资格留彩蛋，因为他们的代码不用别人 review ，其他人的 review 必要会提 comment

＃48 这个 engineering coding 呢，坠痛苦的，就是这个 code review ，而且這個效率 efficiency

www.zhihu.com/question/271409373
百度的 BRPC 里的一个彩蛋，就是 Magic Number

代码不审核吗？怎么可能放彩蛋，如果有人放炸弹怎么办？

Guava 里的 com.google.common.base.CharMatcher 算是经典彩蛋

不会刻意去留，因为第三方组件问题写兼容时候会附带一些吐槽。

彩蛋是要找的，不找发现不了的！
说了这么久怎么没人提 antd 的彩蛋？依稀记得 18 年 antd 的圣诞彩蛋。不少人甚至因为这事丢了工作「不知真假」。

啥叫魔鬼数字 magic number?

只敢玩 magic number ，比如 64 位无效指针我曾经写过 (void *)0x717a3fa112b77274 [doge]

我也一下想起这个了，其实像这样无害的没什么大问题

以前在鹅厂，写单元测试时写过自己的入职时间、毕业时间作为时间字段的填充值，算吗

锦瑾你真会玩

go 的 2006-01-02 15:04:05 也是吧

如果是电影彩蛋类似的东西,非严谨场合倒还可以接受.
如果非要留下自己的信息相关整出来什么密钥之类的,这和狗狗撒尿宣示地盘有什么区别呢,尤其是一些"类容"之类的东西属实整不会了

留彩蛋不如留后门[二哈]

彩蛋是隐藏的、无害的，Code Review 解释清楚当然能过。
至于 HoHoHo ，那种并不是无害的。那是炸弹，不是彩蛋。

没必要。。话说之前一哥们在代码里面写了句 CNM ，然后被全部门通报批评

虽然没查过这玩意有没有通用翻译，但是从没听说过有人管这个叫魔鬼数字

那叫魔法数字不叫魔鬼数字

＃29 我也是，几年前公司用的框架比较新，啥功能都不完善，我就写了两个轮子放到了 composer ，然后安到了公司项目里。刚去看了下 composer.json 里还在用 dev-master ，得提醒一下技术锁版本，要不然真成彩蛋了……

那不叫彩蛋, 那叫缺德

98 年的真会玩

＃12 发现了已离职前端同事的 sb 、nt 变量

2008 年出生的攻城狮接手你的代码，

一看

写的这么烂？

没有，只留了一堆注释和自己的签名，代码洁癖，写的每行代码自己负责

在前公司写代码的时候，如果心情不好变量名就以 fk 开头，fk 就是那啥_uc_的意思
测试自己写的代码的时候，测试数据总是填 1145141919810 的一部分

不恰当的彩蛋会给人不专业的感觉，换句话说“净整那没有用的”

你们怎么知道是 98 年的？

0x19980101

之前设计一个文件格式的时候，魔数用的 0x66CCFF

刚开始工作的时候会，后来就没那个心情了

98 年的真会玩

写得好还行，写得垃圾只会留下骂名

███████╗███████╗██╗██╗ ██╗███████╗██╗ ██╗ ██████╗ ██████╗ ██╗ ██████╗
██╔════╝██╔════╝██║██║ ██╔╝██╔════╝██║ ██║██╔═══██╗██╔══██╗██║ ██╔══██╗
█████╗ █████╗ ██║█████╔╝ █████╗ ██║ █╗ ██║██║ ██║██████╔╝██║ ██║ ██║
██╔══╝ ██╔══╝ ██║██╔═██╗ ██╔══╝ ██║███╗██║██║ ██║██╔══██╗██║ ██║ ██║
██║ ███████╗██║██║ ██╗███████╗╚███╔███╔╝╚██████╔╝██║ ██║███████╗██████╔╝
╚═╝ ╚══════╝╚═╝╚═╝ ╚═╝╚══════╝ ╚══╝╚══╝ ╚═════╝ ╚═╝ ╚═╝╚══════╝╚═════╝

取决于产品类型和公司文化；我们是一个交互型产品，留一个不影响任何操作的彩蛋，是一个很有意思的事情。

肯定不留啊，免得以后别人骂我 s13

或者在注释里面放一尊佛像啥的。 我觉得挺 low 的，还不如认真写个注释。

过不了 code review ，而且会显得有点幼稚。。。

把分析（ analytics ）相关的变量 /函数命名成 anal_xx 这种算彩蛋么。

请问你怎样处理同事间的质疑，如果有的话？我有时候写了些比较适合业务使用的类库，部分同事会一脸嫌弃地说看不懂，好复杂，明明不需要去看代码，提供的接口也是很容易使用的，有时候会感到开发热情被打击

我以为又快到圣诞节了 会有很多人想起 antd 的圣诞彩蛋来着😂