作为程序员，有没有让你感到既无语又崩溃的代码注释？ 第1页

在 StackOverflow 上有一个类似的问题，问大家见过哪些超秀的注释，不少程序员纷纷吐槽自己见过的那些逆天注释，我们抽出一些精彩的分享过来：

1.

//我写这一行的时候，只有上帝和我知道我在写什么

//现在，只有上帝知道了

2.

//somedev1 - 6/7/02 添加对登录屏幕的暂时追踪功能

// somedev2 - 5/22/07 暂时个屁

（仿佛看到两个程序员相隔时空的diss）

3.

//喝大了，等会再修bug

4.

//有魔法，别碰。

5.

//开森地调bug吧，傻x

（隔着屏幕都想打他一顿）

6.

/*

*你可能觉得自己看懂下面的代码了，

*然而你并没有，相信我。

*糊弄过去算了，不然你会好多个晚上睡不着觉，

*嘴里骂着这段注释，觉得自己很聪明，

*真能“优化”下面的代码。

*现在关上文件，去玩点别的吧。

*/

7.

//这代码真是烂透了，你懂得，我也懂得。

8.

//先往下看，后面再喊我傻X。

9.

//我也不确定我们到底需不需要这个，但是删了又特害怕。

10.

#要想理解递归，移步本文件底部

然后翻到文件底部：

#要想理解递归，移步本文件顶部

11.

//本人对本代码概不负责，

//他们让我写的，非本人自愿。

12.

//就不给你们写注释

//这代码写得这么费劲

//所以你们读着也得费劲

13.

//如果这段代码跑的通，那就是Paul DiLascia写的。要是跑不通，

//那我就不知道是谁写的了

14.

//这公式没毛病，你要不信自己去算

15.

//要是你想被炒鱿鱼，那就删吧

16.

//如果将来读到这行代码，我会穿越回来，然后一死以谢天下。

17.

//谨以此代码和我所有的工作献给我的老婆Darlene，

//这段代码要是放出去，

//她就得照顾我还有三个孩子了。

（潜台词是自己代码写的太烂，会丢了工作或者造成公司倒闭）

18.

//别删这行注释啊，删了程序就崩了

最后放个大招，在 GitHub 上有这么一个脚本，前面好好的，很正常，到了中间作者忽然用注释对 Adobe PSD 来了一大段的疯狂吐槽：

//到了这个份儿上，我得给你说说这个 Adobe PSD 格式。

//PSD 可不是个好格式，它甚至都是不个坏格式，叫它坏格式都是

//对 PCX 和 JPEG 这些坏格式的一种侮辱。不，PSD 是一种烂到家的格式。

//我忙活这段代码好几个星期了，我对 PSD 日渐增长的仇恨，

//如同数百万个太阳燃烧成的怒火，绵绵不绝。

//如果有两种不同的做事方法，PSD 会两个都试一遍。

//然后再以正常人无法想象的方式想出三个甚至三个以上的方法，

//把它们也都试一遍。PSD 把“前后矛盾”上升成了一门艺术。比方说，

//为啥它忽然就决定这些特定组块对齐 4 比特，而且这种对齐方式

//不应该包含在尺寸内？其它地方的组块要么没对齐，

//要么对齐方式包含在尺寸内。这里就没包含在内。

//这三种方式任何一种都是可以的，智商正常的格式都会只用一种，

//我们的 PSD 当然是三种都用了，而且不止三种。

//从 PSD 文件里拿到数据，就跟从你那 58 岁生日时被一条抓狂的淡水鲨鱼干掉的

//上岁数的怪叔叔家的阁楼上想找出点好东西一样。

//用鲨鱼这个比方不是我要表达的重点啊，但是我现在正在苦思冥想，

//那些小题大做搞出这种文件格式的人该有怎样搞笑的人生啊。

//之前吧，我想找到这种文件格式的最新说明书。

//为此，我必须向他们申请许可，他们才考虑送我

//这本神圣的“秘籍”。整个过程还得向他们传真

//一些文件的复印件，或者可能还得签点秘密协议。

//我只能觉得，他们把这个流程搞这么复杂就是因为

//他们造出了这么恶心的东西，心里有愧。我是自然不会

//按他们的意思走这个流程的。但是假如我真的

//这么做的话，我会把说明书的每一页都打印出来，

//一把火给它烧了。要是能有超能力，

//我会把说明书的所有复印件都收集过来，

//放到宇宙飞船上，直接发配到太阳。

//

//PSD 不是我喜欢的文件格式。

看来是实在忍无可忍了。吐槽完这一段后，作者又继续淡定地写完了脚本。

这段脚本的地址：

https://github.com/zepouet/Xee-xCode-4.5/blob/master/XeePhotoshopLoader.m#L108

参考资料：
https:// stackoverflow.com/quest ions/184618/what-is-the-best-comment-in-source-code-you-have-ever-encountered

是的，会短命。

泰拳是一项极度残忍的格斗项目。

残忍到什么程度呢？

首先，泰国出生的孩子生下来的时候就要进行严酷的选拔，不适合打泰拳的小孩全部做成小鬼卖给有钱人。

被留下来的小孩六个月的时候就要进行严酷的训练，三岁的时候这些小孩中深蹲不到100kg 硬拉不到100kg的小孩全部要被杀掉。

再留下的小孩开始每天25小时的泰拳训练，泰拳有八臂拳之誉，意思就是拳肘膝腿都可以用来击打对方，其可怕的泰式扫腿是泰拳杀伤力最强的招式。这些小孩每天重点要练的就是扫腿，从每天10万腿开始慢慢练，练到五岁时又有一次选拔，一扫腿不能击沉一艘蒙古航母的小孩又要被杀掉。

更残忍的训练我就不说了，怕被折叠。

总之，经过这种训练的泰拳手杀伤力极强，但也会相应的减少很多寿命。

这世上有一种选手叫泰拳手，他/她生来就练泰拳，一生都只能在练泰拳，他/她累了，就睡在泰拳馆里，这种选手一辈子就只能不练泰拳一次，那就是他/她死的时候。

附一些残忍的泰拳照片：

生无可恋的小选手

被低扫扫中后痛苦的女选手

死亡的女选手

因图片来自网络，来源无法确认，避免涉及到肖像权问题已删。

我会去拳馆照几张女选手的照片给大家补上。

------------------------更新分割线---------------------------

鉴于太多人不知道反讽这一表达方式，还是最后认真说明一下。

练泰拳是真的不会短命

如今，泰拳作为一项国际上成熟的体育运动，有自己的规则，有自己的技术体系，有自己的成熟的格斗赛事，可以说是世界范围内非常安全的体育运动项目了。

泰拳训练和其他格斗竞技项目的学习过程一样，入门的时候先是学站姿，也就是标准的泰式正面站架，脚踩三宫步。然后就是基本击打技术的学习，一般就是最出名的泰式扫腿，内围的顶膝，直拳勾拳，肘击，泰式扭摔。这些技术的学习一般是通过空击，手靶和腿靶来完成。这些技术的扎实和实战运用部分就要靠对练来完成，比如你的教练会让你们两人穿上腿护具，只准用当天学习的右腿扫腿技术互相对抗，很安全。技术定型之后用踢重沙袋，强度靶，节奏靶来提升肌肉耐力和进一步加强力量。

这些技术训练的中间会穿插一些体能训练。等你练了一段时间有一点点模样了才会让你打实战，而且实战通常是要穿护具的，并且不能用肘击。

如果你想往职业路线走，这时候可能就要有一些比较强悍的训练方法了，我的拳馆请的泰教每天要用十公斤的小杠铃杆在自己的小腿胫骨上来回滚，以此来加强胫骨硬度。

但总之，这项运动是非常安全，有趣的对抗项目，而且对于个人自我保护能力，意志品质都是很好的锻炼，减肥效果也不错。

至于某些网上的传言说什么打断腿再接上增加力量之类的传言，我在这里可以很负责任的告诉大家都是扯淡，在中国民间比较有名的泰拳选手播求的训练视频哪里都有，科学上网在YouTube一搜一大堆，我反正没有看到过播求把自己腿打断。至于踢树的话，人家踢的树是软的。

-------------------------------二更-------------------------------

破1K了，谢大家谬赞。

写这个的本意就是为了调侃一下当年我自己上过当的地下黑拳、泰拳扫腿踢断钢筋系列的都市传说。但

---

  yzgyyang 网友的相关建议: 
      

利益相关，狗家云员工，谈谈我的看法，权当抛砖引玉。

云服务的特点是，当开始大量使用的某个云服务商的话，如果要迁移到另一个，就会有巨大的成本。因为公司内部已经写了大量的代码，工具，以及培训了大量员工，去适配云本身。到了这种程度，除非该服务商作死，天天数据库丢数据，或者搞site down，正常公司不可能大规模切换，最多使用混合云的思路。

从这个角度来看，Amazon现有的地位在短期内是不可撼动的，除非它的自己作死。它签下的公司不太可能流失，同时那些公司也会进一步增长。

谷歌云能拼的就是增量，也就是新的公司，新的领域，或者新的流行技术。

新的领域，例如机器学习，各家云都在发力，谷歌靠的是tensorflow, TPU和AI Service.

新的流行技术，比如k8s搞微服务架构，谷歌就搞了云上k8s服务。

新的公司，一是提高普及率，让创业公司习惯是使用，万一创业公司像Airbnb 那样变成独角兽，而且整个基础设施都在云上，那就爽了；二是去抢Amazon的已有客户，或者银行这种想用用云的。

谷歌云的发展，要看中长期的竞争和市场容量。

我不太赞成其它答案的吐槽，谷歌太高冷了，谷歌一线工程师不oncall，Amazon服务好等等，作为一个在前东家做基础设施，饱受AWS摧残的工程师，我这就不吐槽了AWS怎么坑人的了。

早年AWS最重视云计算，大量推广，在学校赞助云计算课程，大量中小公司使用，特别是一些变成了独家兽，这是AWS的成功。但是从我的角度，AWS产品也不是都成功的。AWS提供的关系型数据库产品，S3，EC2，是非常好的，其它一般。我前东家，比如数据仓库用的是Hive, 日志/消息队列用的是Kafka，大数据处理用Spark，微服务架构上K8S。对于这些问题，AWS曾经并没有一锤定音的解决方案，或者说AWS在这些领域曾经没有足够的积累？虽然AWS现在也在提供这些产品，但谷歌云的产品设计对我来说更合理，pubsub搞消息队列，dataflow做数据处理，bigquery搞数据仓库，gcs对标s3，计算引擎和k8s服务也有，AI相关的也不差。从我对基础设施的需求理解，谷歌云给的解决方案很全面了。

---