手记

看完这篇,你的PHP代码优雅一个档次


引言

今天老王同学跟我说,他的代码好糟糕,像一坨xiang。问我要怎么

提高自己的代码质量,让自己代码看得顺眼一点,舒服一点, 就像

看到大长腿MM,两眼放光那种。

于是我: 你先这样,然后这样,然后再那样。。。。。。

老王同学: 别闹, 到底是哪样?

好的, 我要开始装13了。。。

基本规范

先说一下最基本的东西:

  • 变量名使用驼峰命名。不懂的单词不要用拼音,而是要查词典找到对应的单词。

  • 常量命名使用大写下划线方式命名。如:SYSTEM_EROOR = 50000

  • 缩进使用Tab键,不要打一堆空格做缩进。

  • 类名首字母大写驼峰命名,需要见名知其意,注释说明这个类的功能。例如:

  • 方法名驼峰命名,方法行数尽量控制在80行左右,注释说明函数干嘛用的。

  • 花括号独占一行,例如:

  • foreach慎用引用,例如以下代码会有问题:

预期结果是输出: 2 4 6,实际结果是2 4 4, 至于为什么可
以看我之前的文章: PHP中&符号你真的了解吗?
可以使用
array_walk`方法避免这个问题, 示例:

  • 避免if, elese嵌套过深,很多嵌套可以通过提前终止来消除, 举个简单的例子:

建议使用第二种方式,不符合条件的直接返回,剩下的就是符号条件的,那么避免了在if里面写很多代码。

  • 多个if/else使用switch来替代,PHP8.0版本可以使用match更为简洁。

  • phpstorm中安装SonarLint插件。如果你写的代码出现虚线,说明不太理想,那么可以根据提示修改,相信有强迫症的同学一定会改,久而久之代码就很规范了。例如:

    方法未使用,方法名不规范已经告诉你了,可以快捷修改,也可以自己修改。

框架规范

  • 前面说得都是比较基础的东西,接下来才是主要的内容。

  • 相信很多同学都用过常用的thinkphplaravelyii等流行框架之一。

  • 这些框架都是MVC架构的,看过很多人的代码,要么把业务逻辑写在控制器里面,要么写在Model里面, 写在Model里面相比写控制器里面的还相对好一点。其实对于大型项目都不太友好。

  • 下文以Laravel框架为例。

参数验证

  • API需要进行参数验证,但是参数验证写在哪里比较优雅呢?可能很多人在controller定义规则,然后在调用验证方法,那么验证那段代码将在每个API里面出现,例如我同事写的。

    这段代码在每个API里面均会出现一次,岂不是很啰嗦,那么如何解决呢?

  • 在Laravel的http目录下建立一个Requsts目录,用于存放请求的参数验证类。建立一个BaseRequest类:

比如登录需要参数验证再建立一个LoginRequest类继承这个BaseRequest

  • 使用的时候只要在Controller的方法中注入这个请求类即可。

这里获取请求参数的时候会对表单进行验证,否则参数验证失败会调用刚刚Request积累定义的方法抛Json异常,返回信息给客户端。

控制器

控制器的主要工作负载获取请求数据和返回内容,不应做更多的事情,那么可以定义一个Service层来处理业务逻辑。
所以我的控制器的代码只有一行。

  • 在Laravel的app目录下建立一个Services文件夹用于存放Service类,建立一个BaseService类:

然后建立一个UserService来处理用户相关的业务逻辑。

在UserController中注入这个UserService使用:

Model

Model不建议写业务逻辑。Model主要是用来定义一些内容,不应该操纵数据。

Model的数据操纵应该放在Repository中,在Laravel的app目录下建立一个文件夹Repositories

定义BaseRepository:

定义UserRepository,用于用户数据相关的操作, 在构造方法中注入UserModel:

常量

项目中很多常量该怎么定义?

在app目录创建一个Constant目录, 再建立一个Contstant类来保存这些自定义常量。

这样的好处是:

  • 自定义常量可以集中的管理。

  • 修改常量值的时候,只需要在这个类中找修改一次即可,代码更新维护性好。

附录


0人推荐
随时随地看视频
慕课网APP