在写一个日期不同而价格不同的数据库设计,用每日一条记录会简单一点。 现在用的是时间段的。最小单位是一天。如果当天临时变,采用日记记录表。
代码有点多,换成贴图,格式好看一点。
因为图片太长,微博会压缩,文末是超长原图
原图连接 微博的图片会被压缩 https://i.loli.net/2018/08/31/5b88fbf9b9f8e.png
1
b821025551b 2018-08-31 17:24:57 +08:00 1
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
php01 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 1
php 天下第一,不做 php 好多年。。。手动滑稽
|
18
sagaxu 2018-08-31 18:07:54 +08:00 via Android 1
零分,又啰嗦又没用
|
19
UIXX 2018-08-31 18:21:30 +08:00 2
一些复杂的图形算法是这样写注释的。但是这个...我觉得不是很适合这样写。有点过度注释,效果可能并不是太好。
说到底,你说的是业务逻辑,条件分支多。最适合的改代码方式就是理解了业务逻辑后再看代码,而不是边看代码边捋业务逻辑。 如果是这样更好: 1、业务逻辑单独描述,不会给人概念断层的感觉。 2、函数内变量名称与业务逻辑描述有所对应 3、有意识地格式化一下代码,用代码结构来唤起人对于其中业务的建模 |
20
eluotao 2018-08-31 19:37:43 +08:00
这个长图用什么插件截的.能否告知.
|
21
May725 2018-08-31 20:29:44 +08:00 1
感觉参数部分,如果没有额外的说明,可以去掉。
其他我还是感觉挺好的 |
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 1
楼主有这个追求是好的,但说实话,不怎么样…
一是这个逻辑还没复杂到必须要用图来解释意图,优化下代码逻辑效果会更好; 二是后面的维护者不一定有这个心继续维护这个图,很可能就出现代码实际逻辑与注释不一致的情况,反而让接手的人糊涂 |
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
lihongjie0209 2018-08-31 23:03:58 +08:00
代码写清楚了很少需要注释, 代码写不清楚再用注释再写一遍也不会有什么帮助.
|
30
asadegg 2018-09-01 08:59:32 +08:00 2
@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 小文件是公认的好的编程风格吧
|