
在写一个日期不同而价格不同的数据库设计,用每日一条记录会简单一点。 现在用的是时间段的。最小单位是一天。如果当天临时变,采用日记记录表。
代码有点多,换成贴图,格式好看一点。
因为图片太长,微博会压缩,文末是超长原图 
原图连接https://i.loli.net/2018/08/31/5b88fbf9b9f8e.png
1 b821025551b 2018-08-31 17:24:57 +08:00 0 分,10 行代码能解决掉掉问题写了 600 多行。 |
2 DavidNineRoc OP @b821025551b 请指教。 |
3 iblislsy 2018-08-31 17:28:33 +08:00 贴代码的正确姿势捏 |
4 jrient 2018-08-31 17:29:28 +08:00 return 0; |
5 anteros 2018-08-31 17:29:47 +08:00 一句话,我喜欢别人这样写注释。但是我不喜欢这样写注释 |
6 ipwx 2018-08-31 17:40:16 +08:00 via iPhone 注释太多辣,本来一眼扫过去能看清楚的逻辑愣是被拆开来了 |
7 mcfog 2018-08-31 17:40:57 +08:00 大概 40%注释是自动生成了,另外 40%左右类似 //下面我要装逼了 装逼(); |
9 DavidNineRoc OP |
10 ljspython 2018-08-31 17:43:43 +08:00 喜欢看有这样注释的代码,但是别指望我写这样的注释 |
11 DavidNineRoc OP @mcfog IDE 自动生成不讨论,主要是用来代码提示。 我说的注释是画图 >_< |
12 lxy42 2018-08-31 17:54:48 +08:00 注释太多了,有些注释略显多余。 这些注释看起来都是在介绍业务逻辑,你不觉得维护起来很麻烦吗?我个人倾向于在文档中描述清楚业务逻辑,在注释中稍微注明一些“坑”即可。 |
13 iblislsy 2018-08-31 17:55:43 +08:00 @DavidNineRoc 有很多贴代码的链接...找一个帖进去,会生成一个链接 |
14 lxy42 2018-08-31 17:58:18 +08:00 还有一点就像#6 说的,有些简单的操作其实一眼就能通过名字猜出含义,但是被大量注释分割开了。 |
15 DavidNineRoc OP |
16 iblislsy 2018-08-31 18:01:35 +08:00 |
17 cexy 2018-08-31 18:06:41 +08:00 php 天下第一,不做 php 好多年。。。手动滑稽 |
18 sagaxu 2018-08-31 18:07:54 +08:00 via Android 零分,又嗦又没用 |
19 UIXX 2018-08-31 18:21:30 +08:00 一些复杂的图形算法是这样写注释的。但是这个...我觉得不是很适合这样写。有点过度注释,效果可能并不是太好。 说到底,你说的是业务逻辑,条件分支多。最适合的改代码方式就是理解了业务逻辑后再看代码,而不是边看代码边捋业务逻辑。 如果是这样更好: 1、业务逻辑单独描述,不会给人概念断层的感觉。 2、函数内变量名称与业务逻辑描述有所对应 3、有意识地格式化一下代码,用代码结构来唤起人对于其中业务的建模 |
20 eluotao 2018-08-31 19:37:43 +08:00 这个长图用什么插件截的.能否告知. |
21 May725 2018-08-31 20:29:44 +08:00 感觉参数部分,如果没有额外的说明,可以去掉。 其他我还是感觉挺好的 |
22 achenme 2018-08-31 20:33:21 +08:00 感觉比看代码还费劲。 |
23 way2create 2018-08-31 20:35:13 +08:00 日期不同而价格不同,感觉真拗口 |
24 Chaos11 2018-08-31 20:54:47 +08:00 在 v2 想得到赞扬是很难的(与本帖无关 |
25 feiyuanqiu 2018-08-31 20:58:32 +08:00 via Android 楼主有这个追求是好的,但说实话,不怎么样… 一是这个逻辑还没复杂到必须要用图来解释意图,优化下代码逻辑效果会更好; 二是后面的维护者不一定有这个心继续维护这个图,很可能就出现代码实际逻辑与注释不一致的情况,反而让接手的人糊涂 |
26 zhzer 2018-08-31 21:01:18 +08:00 如果变量名和函数名都是外星语言的话注释写的不错 |
27 feiyuanqiu 2018-08-31 21:17:28 +08:00 另外,再指出几个值得商榷的点哈 1. 注释应该描述代码想干什么,而不是代码干了什么。你的注释大部分时间在翻译代码,实际上并不助于别人理解 2. controller 干的事太多太杂了,业务逻辑、数据库查询这些不应该在这一层做,而该它做的请求参数校验似乎又没做? 3. $method = $this->handleStoreMethods[$collections->count()] 真的不会出现为 null 的情况吗? |
28 mingyun 2018-08-31 22:27:37 +08:00 一看就是 laravel |
29 代码写清楚了很少需要注释, 代码写不清楚再用注释再写一遍也不会有什么帮助. |
30 asadegg 2018-09-01 08:59:32 +08:00 @lihongjie0209 注释无用论海星 |
31 msg7086 2018-09-01 11:03:34 +08:00 我感觉最大的一个问题是,同一段代码中注释太长,业务逻辑被打散了(正如上面很多人说的那样)。 比如 StoreOverConfine 这个方法,一共就 3 种,那直接把这 3 种写在方法头部的说明里即可。 注释有两个作用。 一个是让人知道这段代码是做什么的。这是给调用者看的注释。 一个是让人知道这段代码是怎么做的。这是给开发和调试者看的注释。 你可以看看你写的注释,哪些属于第一种,哪些属于第二种。 比如 StoreOverConfine 我就没看懂到底是做什么的。 |
32 DavidNineRoc OP @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 是处理数据库中只有一条匹配的记录,并且这条记录是两边都是超过(包含贴合)前端给定日期的。图中上面的箭头线代表数据库记录下面区间代表前端的时间 |
33 cncqw 2018-09-01 13:52:59 +08:00 自嗨型注释,markdown 程序员。。 |
34 zongren 2018-09-01 15:05:54 +08:00 反正我听说每个文件不要超过 100 行 |
35 wawehi 2018-09-01 15:27:25 +08:00 过渡注释 |
36 Bibilli 2018-09-01 15:41:21 +08:00 注释不是要简洁明了吗?特么这注释看着咋想打人 |
37 alvince 2018-09-01 16:01:47 +08:00 函数注释没有具体说明(包括参数,异常等) 方法内行注释过于嗦,没有重点 0 分 |
38 DavidNineRoc OP |
39 zongren 2018-09-04 12:01:11 +08:00 @DavidNineRoc 小文件是公认的好的编程风格吧 |