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

[DavidNineRoc]

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

---

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

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

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

[May725]

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

[achenme]

感觉比看代码还费劲。

[way2create]

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

[Chaos11]

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

[feiyuanqiu]

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

[zhzer]

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

[feiyuanqiu]

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

[mingyun]

一看就是 laravel

[lihongjie0209]

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

[asadegg]

@lihongjie0209 注释无用论海星

[msg7086]

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

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

[DavidNineRoc]

@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 是处理数据库中只有一条匹配的记录，并且这条记录是两边都是超过（包含贴合）前端给定日期的。图中上面的箭头线代表数据库记录下面区间代表前端的时间

[cncqw]

自嗨型注释，markdown 程序员。。

[zongren]

反正我听说每个文件不要超过 100 行

[wawehi]

过渡注释

[Bibilli]

注释不是要简洁明了吗？特么这注释看着咋想打人

[alvince]

函数注释没有具体说明（包括参数，异常等）
方法内行注释过于啰嗦，没有重点
0 分

[DavidNineRoc]

@cncqw 那是
@zongren 这个应该是骗你的。
@wawehi 还好还好。
@Bibilli 没事，有网线，打不过来。
@alvince 参数和异常，参数这几个都是主键类型的多

[zongren]

@DavidNineRoc 小文件是公认的好的编程风格吧