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