今天最窝心的文字：码农最讨厌两件事儿

码农

注释

讨厌

代码

54 条回复 • 2018-08-18 20:33:27 +08:00

1

fhefh

2018-08-17 15:06:52 +08:00

刚刚在一篇微信推文看到这句话哈哈~

2

WhatC

2018-08-17 15:14:22 +08:00 via Android

1 相对还好吧，自己再捋一遍思路也 ok，2 这个就爆炸了，就怕留了个烂摊子给你。

3

hxhc

2018-08-17 15:31:02 +08:00 via Android

15

个人觉得写注释其实蛮舒服

4

xujinkai

2018-08-17 15:32:50 +08:00 via Android

接手代码没注释和接手代码一行一个注释哪个更不爽？

5

noNOno

2018-08-17 15:32:57 +08:00

1.个人觉得先理清楚逻辑蛮好的,逻辑变成文字就是注释
2.喵喵喵???

6

ChiangDi

2018-08-17 15:35:33 +08:00 via iPhone

再多注释也救不了傻逼代码

7

jamfer

2018-08-17 15:38:24 +08:00

3

男人最讨厌的两件事
1.ML 要戴套
2.GF 不是处

8

littleylv

2018-08-17 15:39:13 +08:00

致远星战况如何？

9

Decouple

2018-08-17 15:41:03 +08:00

代码即注释了解一下，合理的结构和高可读的命名，绝大部分的注释可以通过高质量的代码来避免

10

zsdroid

2018-08-17 15:42:40 +08:00

码农最讨厌两件事儿：一件事是改需求，另一件事还是改需求

11

michaelcheng

2018-08-17 15:43:57 +08:00

我挺喜欢写些注释的，因为有些代码，过两天自己都会忘

12

Decouple

2018-08-17 15:48:21 +08:00

@Decouple 再补充一句，忘了在哪看到的，大意是，注释是一种对失败的妥协，表达出来的意思是：我写出来的这段代码别人（甚至不久后的自己）很难看懂，所以我不得不加点文字

13

night98

2018-08-17 15:48:40 +08:00

@Decouple #9 这个东西基本上等于扯犊子，超过 100 个 class 以上就基本上不成立了。

14

sambawy

2018-08-17 15:50:22 +08:00

1

代码写得优雅一点有没有注释都能看代码写得烂一点有注释都不想看

15

mathzhaoliang

2018-08-17 15:54:26 +08:00

@Decouple 这种说法明显教条了。高质量的代码往往离不开高质量的注释，注释和代码的比例往往大于 1。试想一下在逻辑复杂的项目里面没注释的话，也许别人每一行都看得懂，但连起来就看不懂。

16

Decouple

2018-08-17 15:55:36 +08:00

@night98 为何得出这样的结论？粗略看了一下手头的项目，class 文件早已超过 200 个，然而注释极少，即使有注释也大多是一些对尚未完成功能的说明，而且注释为什么会和项目大小有很强的关系？如果结构复杂那应该用文档来说明而不是注释

17

Decouple

2018-08-17 16:02:14 +08:00

@mathzhaoliang 我认为的是很多复杂的逻辑完全可以分解成数个简单的小模块再组合在一起，比如一个上百行的方法是很难保证可读性的，但是如果把逻辑拆分开最后变成一个十五行的方法，可读性肯定有很大提升。当然只针对大部分情况，无法拆分的另当别论

18

Light3

2018-08-17 16:08:02 +08:00

我还是比较烦就是这个样子你快做啊今天需求今天上线
注释这个不用太复杂大体写一下每个方法的用处不就完了吗

19

qiuqiuer

2018-08-17 16:09:03 +08:00 via Android

1 产品经理想事情
2 产品经理想到事情

20

night98

2018-08-17 16:11:57 +08:00

@Decouple #17 以一个简单的页面显示分页为例。
方法 1 为通用分页，用户首次进入显示该方法数据，需要添加缓存
方法 2 为条件分页，用户筛选后显示该方法数据，需要添加缓存
方法 3 为默认条件分页，用户点击按钮后显示该方法数据，数据已缓存到内存
三个方法入参格式一致，返回格式一致

请问你如何通过命名来直接区分三个方法，以及在其他人阅读时无歧义的理解该方法作用？

21

shihty5

2018-08-17 16:15:05 +08:00

这就是传说中的双标狗，宽己严人。人的本性就是如此呀。

22

tulongtou

2018-08-17 16:23:12 +08:00 via iPhone

这明明是 10 件事

23

Decouple

2018-08-17 16:23:50 +08:00

@night98
1. retrieveData()
2. retrieveDataByCondition(condition)
3. retrieveDataByConditionFromCache(condition)

另外我想表达的不是完全不需要注释，而是绝大多数注释可以避免

24

passerbytiny

2018-08-17 16:30:19 +08:00

@Decouple 代码即注释有个前提，所有使用代码的人对代码的理解方式相同。这要求开发期必须有通畅的沟通，维护期必须有良好的交接。此时敏捷开发、领域模型通用语言就成了必要条件，一般团队是达不到这俩必要条件的。

25

night98

2018-08-17 16:32:26 +08:00

@Decouple #23
绝大多数注释可避免的前提是：

1.团队成员水平基本一致
2.对当前业务较为熟悉

现在有几个团队能有这个条件？

我并没有否认好的代码可以自解释，只是注释可以最快的让其他开发理解该方法或类所实际执行的事情，另外顺嘴说一句，有些开发写的注释还不如不写，写五个字的注释，基本等于没写。

26

newtype0092

2018-08-17 16:36:28 +08:00

@Decouple 你回想下上学时老师推导数学题的时候，是不是简单的题也有思路跟不上脑袋没转过弯的时候，难题也有一下冒出灵感得出比标准答案还优的解的时候，人的思路本来就不是机械化的东西，在关键的地方引导一下怎么就成了对失败的妥协了？
代码的自注释只限于“做了什么”，你说的吧逻辑拆分的更小更易读也只是让别人更清楚你“做了什么”。
而阅读代码是基于“做了什么”而推导出“要达成什么目标”，代码再完美再简单易懂也无法省略这个推导过程。
好的注释就是给这个推导加一些提示，让推导过程更顺利，这显然是合理而必要的。

27

0x8192dd

2018-08-17 16:39:35 +08:00

并没有，我写代码必写注释，而且很享受写注释的时候总结思路的过程，写注释又不是写口水话，类似 readme 的注释该写还是要写的，不然隔几个月自己都不记得自己当时为什么这么写

28

Decouple

2018-08-17 16:43:38 +08:00

@passerbytiny
@night98
说的很有道理，敏捷开发惯了，有点想当然，但我依然觉得即使在这样的前提下也有很多注释可以避免，Martin Fowler 谈过这个问题： https://www.kancloud.cn/sstd521/refactor/194232

29

4u1kto

2018-08-17 16:45:00 +08:00

最窝心的难道不是给人写了注释，他们也看不懂代码吗。

30

zhangchioulin

2018-08-17 16:46:07 +08:00

我也觉得写注释挺舒服的。

31

Decouple

2018-08-17 17:05:59 +08:00

@newtype0092 这一类注释确实是有必要的，可能说的有点偏激

32

kimown

2018-08-17 17:13:02 +08:00 via Android

注释只是锦上添花，我更希望项目代码有一个约定思路，复杂需求能用更合理的方式解决，而不是堆代码，堆变量

33

wormcy

2018-08-17 17:15:46 +08:00 via Android

我最讨厌 2 种人
1. 种族歧视的人
2. 黑人

34

4u1kto

2018-08-17 17:18:55 +08:00

![看这个注释](

)

35

toxicant

2018-08-17 17:30:07 +08:00

1：为了让自己下周看代码时还知道上周五都干了啥...
2：可以考虑换一个工作环境了

36

tohearts

2018-08-17 17:37:43 +08:00

写注释可以让自己逻辑清楚，干嘛不写。

37

PulpFunction

2018-08-17 17:50:11 +08:00

@4u1kto 真的？代码行数估计能除 3

38

tkmiles

2018-08-17 18:00:12 +08:00 via iPhone

我倒是很喜欢写注释，主要怕忘记逻辑

39

tingyunsay

2018-08-17 18:26:22 +08:00

最起码函数头写个说明，函数变更什么的，现在看别人的代码看得脑袋大，尤其是交接过好几回的，用思维导图才慢慢理明白....

40

boboliu

2018-08-17 18:29:10 +08:00 via Android

@jamfer 你这个不够自相矛盾，应该是
1. GF 婚前不给啪
2. GF 不是处

41

night98

2018-08-17 18:34:17 +08:00

@Decouple #28 是的，高质量的注释才叫注释，有些开发我就不想说了，注释基本上保持在五个字以内，这种注释除了他自己知道怎么回事之外，其他人看了还可能有歧义，所以保持注释的质量也是很重要的。

42

wzxlovesy

2018-08-17 19:01:52 +08:00 via Android

@night98 你的说法才不成立，注释太多反而容易引起误解，特别是注释没跟上代码的时候，你是该看注释还是代码？

『代码整洁之道』了解一下

43

ArthurMarcel

2018-08-17 19:20:56 +08:00

合理的注释才是关键~

44

iceheart

2018-08-17 23:11:17 +08:00 via Android

记性越来越差，一般先写注释，然后看着注释填代码。
不然写着写着就忘了先前的思路了

45

zj299792458

2018-08-17 23:19:53 +08:00 via iPhone

现代代码还需要注释么，函数变量名能长到换行，一个方法声明能写 10 行(没错我说的就是 OC)，意思都一目了然，现代 IDE 调用时都是自动完成，只按前两个字母就全出来了，又不是嵌入式 c 代码，喜欢用单字母和缩写……

个人感觉注释已经沦为屏蔽代码的工具了，很多时候看注释掉的代码能知道当年这里有什么问题，企图怎样做……

46

ykrl089

2018-08-17 23:56:06 +08:00

@hxhc 注释写的比代码还多！

47

skylerlin

2018-08-18 00:07:18 +08:00

真的笑，笑出声

48

sampeng

2018-08-18 00:19:26 +08:00 via iPhone

写不写注释都有理由…这也要争论讨论一番？写注释的改变不了不写注释的习惯，不写注释的改变不了写注释的习惯。

简单的逻辑写注释也是浪费时间。除非是一个模块设计，或者是代码组织设计，这有必要。但简单逻辑像数据库操作、楼上举例分页之类的。真没多少注释好写，理解注释的意思一样要花时间。我宁愿直接看代码逻辑。当然顺手写出超过 50 行-100 行的大函数习惯的人肯定无法理解这个思维过程…

开源项目不写注释提交代码都是问题。不在讨论范围之列

接手代码完全没注释也是分情况的，简单项目…反正要推掉重来的。复杂项目，交接会大体有个逻辑线会讲清楚。什么？超级垃圾代码项目？我加班加点重写可好…