引言

今天老王同学跟我说，他的代码好糟糕，像一坨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插件。如果你写的代码出现虚线，说明不太理想，那么可以根据提示修改，相信有强迫症的同学一定会改，久而久之代码就很规范了。例如:

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

框架规范

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

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

• 这些框架都是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类来保存这些自定义常量。

这样的好处是:

• 自定义常量可以集中的管理。
• 修改常量值的时候，只需要在这个类中找修改一次即可，代码更新维护性好。

原文地址：https://juejin.cn/post/6957290009682509854

作者：ClassmateLin