这是一个创建于 2808 天前的主题，其中的信息可能已经有所发展或是发生改变。
码农最讨厌两件事儿：
1.码代码的时候写注释 2.接手别人代码没注释
真的扎心了，我先笑十分钟。
 | 1 fhefh 2018 年 8 月 17 日 刚刚在一篇微信推文看到这句话 哈哈~ |
 | 2 WhatC 2018 年 8 月 17 日 via Android 1 相对还好吧，自己再捋一遍思路也 ok，2 这个就爆炸了，就怕留了个烂摊子给你。 |
 | 3 hxhc 2018 年 8 月 17 日 via Android  15 个人觉得写注释其实蛮舒服 |
 | 4 xujinkai 2018 年 8 月 17 日 via Android 接手代码没注释和接手代码一行一个注释哪个更不爽？ |
 | 5 noNOno 2018 年 8 月 17 日 1.个人觉得先理清楚逻辑蛮好的,逻辑变成文字就是注释 2.喵喵喵??? |
 | 6 ChiangDi 2018 年 8 月 17 日 via iPhone 再多注释也救不了傻逼代码 |
 | 8 U7Q5tLAex2FI0o0g 2018 年 8 月 17 日 致远星战况如何？ |
 | 9 Decouple 2018 年 8 月 17 日 代码即注释了解一下，合理的结构和高可读的命名，绝大部分的注释可以通过高质量的代码来避免 |
 | 10 zsdroid 2018 年 8 月 17 日 码农最讨厌两件事儿：一件事是改需求，另一件事还是改需求 |
 | 11 michaelcheng 2018 年 8 月 17 日 我挺喜欢写些注释的，因为有些代码，过两天自己都会忘 |
| 12 Decouple 2018 年 8 月 17 日 @Decouple 再补充一句，忘了在哪看到的，大意是，注释是一种对失败的妥协，表达出来的意思是：我写出来的这段代码别人（甚至不久后的自己）很难看懂，所以我不得不加点文字 |
 | 14 sambawy 2018 年 8 月 17 日 1 代码写得优雅一点 有没有注释都能看 代码写得烂一点 有注释都不想看 |
 | 15 mathzhaoliang 2018 年 8 月 17 日 @Decouple 这种说法明显教条了。高质量的代码往往离不开高质量的注释，注释和代码的比例往往大于 1。试想一下在逻辑复杂的项目里面没注释的话，也许别人每一行都看得懂，但连起来就看不懂。 |
| 16 Decouple 2018 年 8 月 17 日 @night98 为何得出这样的结论？粗略看了一下手头的项目，class 文件早已超过 200 个，然而注释极少，即使有注释也大多是一些对尚未完成功能的说明，而且注释为什么会和项目大小有很强的关系？如果结构复杂那应该用文档来说明而不是注释 |
| 17 Decouple 2018 年 8 月 17 日 @mathzhaoliang 我认为的是很多复杂的逻辑完全可以分解成数个简单的小模块再组合在一起，比如一个上百行的方法是很难保证可读性的，但是如果把逻辑拆分开最后变成一个十五行的方法，可读性肯定有很大提升。当然只针对大部分情况，无法拆分的另当别论 |
 | 18 Light3 2018 年 8 月 17 日 我还是比较烦 就是这个样子你快做啊 今天需求 今天上线 注释这个 不用太复杂 大体写一下每个 方法的 用处不就完了吗 |
 | 19 qiuqiuer 2018 年 8 月 17 日 via Android 1 产品经理想事情 2 产品经理想到事情 |
 | 20 night98 2018 年 8 月 17 日 @Decouple #17 以一个简单的页面显示分页为例。 方法 1 为通用分页，用户首次进入显示该方法数据，需要添加缓存 方法 2 为条件分页，用户筛选后显示该方法数据，需要添加缓存 方法 3 为默认条件分页，用户点击按钮后显示该方法数据，数据已缓存到内存 三个方法入参格式一致，返回格式一致 请问你如何通过命名来直接区分三个方法，以及在其他人阅读时无歧义的理解该方法作用？ |
 | 21 peterontheway 2018 年 8 月 17 日 这就是传说中的双标狗，宽己严人。人的本性就是如此呀。 |
 | 22 DonaidTrump 2018 年 8 月 17 日 via iPhone 这明明是 10 件事 |
| 23 Decouple 2018 年 8 月 17 日 @night98 1. retrieveData() 2. retrieveDataByCondition(condition) 3. retrieveDataByConditionFromCache(condition) 另外我想表达的不是完全不需要注释，而是绝大多数注释可以避免 |
 | 24 passerbytiny 2018 年 8 月 17 日 @Decouple 代码即注释有个前提，所有使用代码的人对代码的理解方式相同。这要求开发期必须有通畅的沟通，维护期必须有良好的交接。此时敏捷开发、领域模型通用语言就成了必要条件，一般团队是达不到这俩必要条件的。 |
| 25 night98 2018 年 8 月 17 日 @Decouple #23 绝大多数注释可避免的前提是： 1.团队成员水平基本一致 2.对当前业务较为熟悉 现在有几个团队能有这个条件？ 我并没有否认好的代码可以自解释，只是注释可以最快的让其他开发理解该方法或类所实际执行的事情，另外顺嘴说一句，有些开发写的注释还不如不写，写五个字的注释，基本等于没写。 |
 | 26 newtype0092 2018 年 8 月 17 日 @Decouple 你回想下上学时老师推导数学题的时候，是不是简单的题也有思路跟不上脑袋没转过弯的时候，难题也有一下冒出灵感得出比标准答案还优的解的时候，人的思路本来就不是机械化的东西，在关键的地方引导一下怎么就成了对失败的妥协了？ 代码的自注释只限于“做了什么”，你说的吧逻辑拆分的更小更易读也只是让别人更清楚你“做了什么”。 而阅读代码是基于“做了什么”而推导出“要达成什么目标”，代码再完美再简单易懂也无法省略这个推导过程。 好的注释就是给这个推导加一些提示，让推导过程更顺利，这显然是合理而必要的。 |
 | 27 0x8192dd 2018 年 8 月 17 日 并没有，我写代码必写注释，而且很享受写注释的时候总结思路的过程，写注释又不是写口水话，类似 readme 的注释该写还是要写的，不然隔几个月自己都不记得自己当时为什么这么写 |
| 28 Decouple 2018 年 8 月 17 日 @passerbytiny @night98 说的很有道理，敏捷开发惯了，有点想当然，但我依然觉得即使在这样的前提下也有很多注释可以避免，Martin Fowler 谈过这个问题： https://www.kancloud.cn/sstd521/refactor/194232 |
 | 29 4u1kto 2018 年 8 月 17 日 最窝心的难道不是给人写了注释，他们也看不懂代码吗。 |
 | 30 zhangchioulin 2018 年 8 月 17 日 我也觉得写注释挺舒服的。 |
| 31 Decouple 2018 年 8 月 17 日 @newtype0092 这一类注释确实是有必要的，可能说的有点偏激 |
 | 32 kimown 2018 年 8 月 17 日 via Android 注释只是锦上添花，我更希望项目代码有一个约定思路，复杂需求能用更合理的方式解决，而不是堆代码，堆变量 |
 | 33 wormcy 2018 年 8 月 17 日 via Android 我最讨厌 2 种人 1. 种族歧视的人 2. 黑人 |
| 34 4u1kto 2018 年 8 月 17 日  ) |
 | 35 toxicant 2018 年 8 月 17 日 1：为了让自己下周看代码时还知道上周五都干了啥... 2：可以考虑换一个工作环境了 |
 | 36 tohearts 2018 年 8 月 17 日 写注释可以让自己逻辑清楚，干嘛不写。 |
 | 37 PulpFunction 2018 年 8 月 17 日 @4u1kto 真的？ 代码行数估计能除 3 |
 | 38 tkmiles 2018 年 8 月 17 日 via iPhone 我倒是很喜欢写注释，主要怕忘记逻辑 |
 | 39 tingyunsay 2018 年 8 月 17 日 最起码函数头写个说明，函数变更什么的，现在看别人的代码看得脑袋大，尤其是交接过好几回的，用思维导图才慢慢理明白.... |
| 41 night98 2018 年 8 月 17 日 @Decouple #28 是的，高质量的注释才叫注释，有些开发我就不想说了，注释基本上保持在五个字以内，这种注释除了他自己知道怎么回事之外，其他人看了还可能有歧义，所以保持注释的质量也是很重要的。 |
 | 42 wzxlovesy 2018 年 8 月 17 日 via Android |
 | 43 ArthurMarcel 2018 年 8 月 17 日 合理的注释才是关键~ |
 | 44 iceheart 2018 年 8 月 17 日 via Android 记性越来越差，一般先写注释，然后看着注释填代码。 不然写着写着就忘了先前的思路了 |
 | 45 zj299792458 2018 年 8 月 17 日 via iPhone 现代代码还需要注释么，函数变量名能长到换行，一个方法声明能写 10 行(没错我说的就是 OC)，意思都一目了然，现代 IDE 调用时都是自动完成，只按前两个字母就全出来了，又不是嵌入式 c 代码，喜欢用单字母和缩写…… 个人感觉注释已经沦为屏蔽代码的工具了，很多时候看注释掉的代码能知道当年这里有什么问题，企图怎样做…… |
 | 47 skylerlin 2018 年 8 月 18 日 真的笑，笑出声 |
 | 48 sampeng 2018 年 8 月 18 日 via iPhone 写不写注释都有理由…这也要争论讨论一番？写注释的改变不了不写注释的习惯，不写注释的改变不了写注释的习惯。 简单的逻辑写注释也是浪费时间。除非是一个模块设计，或者是代码组织设计，这有必要。但简单逻辑像数据库操作、楼上举例分页之类的。真没多少注释好写，理解注释的意思一样要花时间。我宁愿直接看代码逻辑。当然顺手写出超过 50 行-100 行的大函数习惯的人肯定无法理解这个思维过程… 开源项目不写注释提交代码都是问题。不在讨论范围之列 接手代码完全没注释也是分情况的，简单项目…反正要推掉重来的。复杂项目，交接会大体有个逻辑线会讲清楚。什么？超级垃圾代码项目？我加班加点重写可好… |
 | 49 MonoLogueChi 2018 年 8 月 18 日 via Android 注释我一般都是写完一段之后再去补的，不习惯思路被打断。另外注释真的很重要，比如当我调用一个函数的时候，如果没有注释，我可能需要去找这个函数再看一遍才能确定参数。 |
 | 50 jmk92 2018 年 8 月 18 日 思路用注释写一遍，写代码轻松很多。 比如， //把冰箱门打开 ....开始码代码 //把长颈鹿放进去 .... //把门关上 ... |
 | 51 Mrkon 2018 年 8 月 18 日 最好还是精简注释，然后函数使用好的命名方式。 |
 | 52 leekafai 2018 年 8 月 18 日 via Android 我一般先写注释再写代码的。写好了注释，搞清楚自己要干嘛，然后去装杯水，回来再写代码，最后测试完了，删掉一部分不必要的注释。 |
 | 53 YogurtTnT 2018 年 8 月 18 日 via iPhone 哇，那源码中的那么多注释怎么说 AQS 那注释都是一篇文章 |
 | 54 e8c47a0d 2018 年 8 月 18 日 首先接手别人的代码这件事本身就窝心 |
Select Language