写了一个区间段修改的逻辑，这个注释能打几分！

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 2267 天前的主题，其中的信息可能已经有所发展或是发生改变。

在写一个日期不同而价格不同的数据库设计，用每日一条记录会简单一点。现在用的是时间段的。最小单位是一天。如果当天临时变，采用日记记录表。

代码有点多，换成贴图，格式好看一点。

因为图片太长，微博会压缩，文末是超长原图

原图连接 微博的图片会被压缩 https://i.loli.net/2018/08/31/5b88fbf9b9f8e.png

压缩

注释

记录

图片

39 条回复 • 2018-09-04 12:01:11 +08:00

b821025551b

2018-08-31 17:24:57 +08:00

0 分，10 行代码能解决掉掉问题写了 600 多行。

DavidNineRoc

2018-08-31 17:27:10 +08:00

@b821025551b 请指教。

iblislsy

2018-08-31 17:28:33 +08:00

贴代码的正确姿势捏

jrient

2018-08-31 17:29:28 +08:00

return 0;

php01

2018-08-31 17:29:47 +08:00

一句话，我喜欢别人这样写注释。但是我不喜欢这样写注释

ipwx

2018-08-31 17:40:16 +08:00 via iPhone

注释太多辣，本来一眼扫过去能看清楚的逻辑愣是被拆开来了

mcfog

2018-08-31 17:40:57 +08:00

大概 40%注释是自动生成了，另外 40%左右类似

//下面我要装逼了
装逼();

Rizio

2018-08-31 17:42:02 +08:00

@php01 +1

DavidNineRoc

2018-08-31 17:43:25 +08:00

@iblislsy 直接贴，换行不好控制
@jrient 不应该是 exit(0); >_<
@php01 有些地方不写多一点注释，害怕自己一个月后再回来看也懵逼
@ipwx 可能是自己写的，然后觉得正好把区分的地方写逻辑。

ljspython

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

喜欢看有这样注释的代码，但是别指望我写这样的注释

DavidNineRoc

2018-08-31 17:44:50 +08:00

@mcfog IDE 自动生成不讨论，主要是用来代码提示。我说的注释是画图 >_<

lxy42

2018-08-31 17:54:48 +08:00

注释太多了，有些注释略显多余。
这些注释看起来都是在介绍业务逻辑，你不觉得维护起来很麻烦吗？我个人倾向于在文档中描述清楚业务逻辑，在注释中稍微注明一些“坑”即可。

iblislsy

2018-08-31 17:55:43 +08:00

@DavidNineRoc 有很多贴代码的链接...找一个帖进去，会生成一个链接

lxy42

2018-08-31 17:58:18 +08:00

还有一点就像#6 说的，有些简单的操作其实一眼就能通过名字猜出含义，但是被大量注释分割开了。

DavidNineRoc

2018-08-31 17:59:51 +08:00

@ljspython 哈哈，果然是 PHP 老手
@lxy42 因为以前接手过一个老旧项目，看一点代码去找文档，看一点去找文档维护才是真的心累。其他地方的代码基本就写一点坑，就这个控制器多一点。
@iblislsy gist?

iblislsy

2018-08-31 18:01:35 +08:00

https://paste.ubuntu.com/

cexy

2018-08-31 18:06:41 +08:00

php 天下第一，不做 php 好多年。。。手动滑稽

sagaxu

2018-08-31 18:07:54 +08:00 via Android

零分，又啰嗦又没用

UIXX

2018-08-31 18:21:30 +08:00

一些复杂的图形算法是这样写注释的。但是这个...我觉得不是很适合这样写。有点过度注释，效果可能并不是太好。
说到底，你说的是业务逻辑，条件分支多。最适合的改代码方式就是理解了业务逻辑后再看代码，而不是边看代码边捋业务逻辑。
如果是这样更好：
1、业务逻辑单独描述，不会给人概念断层的感觉。
2、函数内变量名称与业务逻辑描述有所对应
3、有意识地格式化一下代码，用代码结构来唤起人对于其中业务的建模

eluotao

2018-08-31 19:37:43 +08:00

这个长图用什么插件截的.能否告知.

May725

2018-08-31 20:29:44 +08:00

感觉参数部分，如果没有额外的说明，可以去掉。
其他我还是感觉挺好的

achenme

2018-08-31 20:33:21 +08:00

感觉比看代码还费劲。

way2create

2018-08-31 20:35:13 +08:00

日期不同而价格不同，感觉真拗口

Chaos11

2018-08-31 20:54:47 +08:00

在 v2 想得到赞扬是很难的（与本帖无关

feiyuanqiu

2018-08-31 20:58:32 +08:00 via Android

楼主有这个追求是好的，但说实话，不怎么样…
一是这个逻辑还没复杂到必须要用图来解释意图，优化下代码逻辑效果会更好；
二是后面的维护者不一定有这个心继续维护这个图，很可能就出现代码实际逻辑与注释不一致的情况，反而让接手的人糊涂

zhzer

2018-08-31 21:01:18 +08:00

如果变量名和函数名都是外星语言的话注释写的不错

feiyuanqiu

2018-08-31 21:17:28 +08:00

另外，再指出几个值得商榷的点哈
1. 注释应该描述代码想干什么，而不是代码干了什么。你的注释大部分时间在翻译代码，实际上并不助于别人理解
2. controller 干的事太多太杂了，业务逻辑、数据库查询这些不应该在这一层做，而该它做的请求参数校验似乎又没做？
3. $method = $this->handleStoreMethods[$collections->count()] 真的不会出现为 null 的情况吗？

mingyun

2018-08-31 22:27:37 +08:00

一看就是 laravel

lihongjie0209

2018-08-31 23:03:58 +08:00

代码写清楚了很少需要注释, 代码写不清楚再用注释再写一遍也不会有什么帮助.

asadegg

2018-09-01 08:59:32 +08:00

@lihongjie0209 注释无用论海星

msg7086

2018-09-01 11:03:34 +08:00

我感觉最大的一个问题是，同一段代码中注释太长，业务逻辑被打散了（正如上面很多人说的那样）。
比如 StoreOverConfine 这个方法，一共就 3 种，那直接把这 3 种写在方法头部的说明里即可。

注释有两个作用。
一个是让人知道这段代码是做什么的。这是给调用者看的注释。
一个是让人知道这段代码是怎么做的。这是给开发和调试者看的注释。
你可以看看你写的注释，哪些属于第一种，哪些属于第二种。
比如 StoreOverConfine 我就没看懂到底是做什么的。

DavidNineRoc

2018-09-01 12:16:29 +08:00

@iblislsy what?
@cexy 这个是必须的
@UIXX 大哥搞图形算法的？
@eluotao 不是截图的，用网站生成的，
@May725 参数只要是喜欢用 ide 生成
@achenme 哈哈，这是必须的
@way2create 也是第一次，不知道该怎么表达，有点类似机票那种感觉，
@Chaos11 批评学习也好
@feiyuanqiu 所以我可以做好代码逻辑和图形一样，方便一下后来人。
@feiyuanqiu 因为这里的逻辑有点绕，我个人不是很喜欢 repository 层，而 laravel 的 orm 能让看的人清楚知道做什么。表单验证我觉得非常不必要在 controller 做，而是通过 request 去验证，然后注入控制器。我的 ListingPriceRequest 已经做了表单验证，这个取数组不会出现 null，因为前面已经删除了被包含在中间的，能出现的只有 0 （没有记录），1 （在左边或者右边），2 两边同时出现。
@mingyun 宾狗
@lihongjie0209 代码写清楚了，再加点注释更好>_<
@msg7086 get 到，以前只知道注释是表达做什么了。StoreOverConfine 是处理数据库中只有一条匹配的记录，并且这条记录是两边都是超过（包含贴合）前端给定日期的。图中上面的箭头线代表数据库记录下面区间代表前端的时间