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

[DavidNineRoc]

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

---

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

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

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

[b821025551b]

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

[DavidNineRoc]

@b821025551b 请指教。

[iblislsy]

贴代码的正确姿势捏

[jrient]

return 0;

[php01]

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

[ipwx]

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

[mcfog]

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

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

[Rizio]

@php01 +1

[DavidNineRoc]

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

[ljspython]

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

[DavidNineRoc]

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

[lxy42]

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

[iblislsy]

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

[lxy42]

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

[DavidNineRoc]

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

[iblislsy]

https://paste.ubuntu.com/

[cexy]

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

[sagaxu]

零分，又啰嗦又没用

[UIXX]

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

[eluotao]

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

[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 小文件是公认的好的编程风格吧