世界月新日异,计算机技术的变化可是最有代表性,手机基本上每年都更新迭代,每隔几个月总会有让人耳目一新的新技术新体验出现, 让人应接不暇。作为it男,看见这些炫酷的数码产品,真是馋的流口水呀。可惜囊中羞涩,根本跟没钱去买新品,一个手机都只能 到降价平稳期才敢下手,有个两三年都不敢换。作为穷人,只能努力工作咯。
作为互联网从业人员,在各种奇葩业务逻辑中浸淫多年,也有了点自己的小技巧。不然真会被代码折磨致死,从此失去信心,进而患上忧郁症。 还是要抗的住压力,怼的了产品经理,脸皮够厚,体格够壮。 下面聊聊我个人的小想法
$role_has_api = app(ApiForRoleRepository::class)->get($roles_api_has_search); if (!$role_has_api) { return false; } return true;
return app(ApiForRoleRepository::class)->get($roles_api_filters);
以上两种写法第二种明显简洁,但是我还是偏向于使用第一种。为什么呢 1.函数返回值尽量类型一致,这样调用的地方处理返回值比较简单,由于php为弱类型语言,可以自己在函数内进行变更 2.B代码片段返回值依赖了被调用的函数,这样容易给人困扰,返回值是什么 还要跟进去看 3.B代码不利于调试排错, A代码块在增加日志时不用对已有代码进行更改,只需增加日志代码,B代码却需要修改原始代码,增加变量来进行日志 跟踪。 同时在使用git进行diff比较时 A 也更清晰
if (!$project_is_open = $this->projectIsOpen($params['project_id'])) { return false; }
if (!$this->projectIsOpen($params['project_id'])) { return false; }
我更倾向于第一种,貌似化蛇添足
1.同样 第一种利于增加代码进行扩展,利于排错
我对王垠大神的《编程的智慧》 中提到的观点很赞同
代码不是一蹴而就的,灵感是星星点点,陆陆续续到来的。所以代码需要反复提炼。每当我们过段时间回头看自己代码的时候总能发现一些改进。 大神都这么说,作为悟性普通,能力普通的程序猿,在面对自己代码缺陷时还有什么可脸红的? 只要能反复推敲,不断进步就是好的。最怕的是 吝啬代码,不愿意做出改变
优雅的代码大体的结构上来看,就像一些整整齐齐,套在一起的盒子,井然有序,思路清晰.
要能给函数的作用起个名字,如果你没有词汇能给你的函数起名字的时候,说明这个函数可能不是个好的函数,需要警惕了
对重复常用的代码,不管有多短,都 应该提取出去做成函数。
真正的好代码是自解释的,直接看名字就知道干的啥事
这样容易造成混淆,尽量减少局部变量的作用域
由于中间变量具有意义,步骤清晰,变得很容易理解
并不是语言提供什么,就一定要用上它,只用经过千锤百炼,觉得值得信赖的一套
不要盲目依赖操作符优先级
要一眼能看出代码是想干嘛
不要忽略分支,不要偷懒
现实工程中应该看的近一点,不要被"将来"所拖垮