世界月新日异,计算机技术的变化可是最有代表性,手机基本上每年都更新迭代,每隔几个月总会有让人耳目一新的新技术新体验出现, 让人应接不暇。作为it男,看见这些炫酷的数码产品,真是馋的流口水呀。可惜囊中羞涩,根本跟没钱去买新品,一个手机都只能 到降价平稳期才敢下手,有个两三年都不敢换。作为穷人,只能努力工作咯。

作为互联网从业人员,在各种奇葩业务逻辑中浸淫多年,也有了点自己的小技巧。不然真会被代码折磨致死,从此失去信心,进而患上忧郁症。 还是要抗的住压力,怼的了产品经理,脸皮够厚,体格够壮。 下面聊聊我个人的小想法

A

$role_has_api         = app(ApiForRoleRepository::class)->get($roles_api_has_search);
        if (!$role_has_api) {
            return false;
        }

        return true;

B

return app(ApiForRoleRepository::class)->get($roles_api_filters);

以上两种写法第二种明显简洁,但是我还是偏向于使用第一种。为什么呢 1.函数返回值尽量类型一致,这样调用的地方处理返回值比较简单,由于php为弱类型语言,可以自己在函数内进行变更 2.B代码片段返回值依赖了被调用的函数,这样容易给人困扰,返回值是什么 还要跟进去看 3.B代码不利于调试排错, A代码块在增加日志时不用对已有代码进行更改,只需增加日志代码,B代码却需要修改原始代码,增加变量来进行日志 跟踪。 同时在使用git进行diff比较时 A 也更清晰

A

if (!$project_is_open = $this->projectIsOpen($params['project_id'])) {
            return false;
        }

B

if (!$this->projectIsOpen($params['project_id'])) {
            return false;
        }

我更倾向于第一种,貌似化蛇添足

1.同样 第一种利于增加代码进行扩展,利于排错

  1. 尽量减少简写,这样排错的时候更加容易

我对王垠大神的《编程的智慧》 中提到的观点很赞同

.反复推敲代码

代码不是一蹴而就的,灵感是星星点点,陆陆续续到来的。所以代码需要反复提炼。每当我们过段时间回头看自己代码的时候总能发现一些改进。 大神都这么说,作为悟性普通,能力普通的程序猿,在面对自己代码缺陷时还有什么可脸红的? 只要能反复推敲,不断进步就是好的。最怕的是 吝啬代码,不愿意做出改变

.优雅的代码

优雅的代码大体的结构上来看,就像一些整整齐齐,套在一起的盒子,井然有序,思路清晰.

.写模块化的代码

避免写太长的函数

要能给函数的作用起个名字,如果你没有词汇能给你的函数起名字的时候,说明这个函数可能不是个好的函数,需要警惕了

制造小的工具函数

对重复常用的代码,不管有多短,都 应该提取出去做成函数。

每个函数只做一件事

避免使用全局变量和类成员

.写可读的代码

真正的好代码是自解释的,直接看名字就知道干的啥事

使用有意义的函数和变量名字

局部变量应该尽量接近使用它的地方

局部变量名字应该简短

不要重用局部变量

这样容易造成混淆,尽量减少局部变量的作用域

把复杂的逻辑提取出去,做出帮助函数

复杂的表达式提取出去,做成中间变量。

由于中间变量具有意义,步骤清晰,变得很容易理解

在合理的地方换行

.写简单的代码

并不是语言提供什么,就一定要用上它,只用经过千锤百炼,觉得值得信赖的一套

避免或减少使用自增自减表达式

合理使用括号

不要盲目依赖操作符优先级

避免使用continue 和break

如果出现了continue 往往只需把continue的条件反向,就可以消除continue

如果出现break 往往可以把break的条件合并到循环头部的终止条件里

有时候可以把break替换成return,从而去掉break

如果以上都失败,可以把循环里面复杂的部分提取出来,做成函数调用。

.写简单的代码

要一眼能看出代码是想干嘛

.写无懈可击的代码

不要忽略分支,不要偷懒

.正确处理异常

.正确处理NULL指针

尽量不要产生null指针

不要catch NullPointerException

不要把null 放进"容器数据结构"里面

防止过度工程

现实工程中应该看的近一点,不要被"将来"所拖垮

先把眼前的问题解决掉,解决好,再考虑将来的扩展问题。

先写出可用的代码,反复推敲,再考虑是否需要重用的问题。

先写出可用,简单,明显没有bug的代码,再考虑测试的问题。