PHP编码建议

PHP编码建议.md

1. 每个函数行数不宜过长，逻辑复用的地方尽量抽象出来，单个函数太长，做的事情会过多，而且会增加维护的时候看代码的上下文切换。单个函数小，功能少，更容易明白。如果一个函数调用了多个函数进行的逻辑，如果逻辑比较复杂，建议写好注释，减少对调用的具体函数的逻辑关注，调用的函数的正确性由被调用的函数去保证。
2. 函数的参数建议传递的是普通的值，如 int, string, bool, 对象 等类型，不建议传递 数组。数组作为参数的时候，调用方还要关注里边的key，value等，不够明确类型。当然不做强制要求，综合开发方便和可维护性。
3. 业务逻辑不建议直接在controller和console中书写任何的逻辑业务，所有的逻辑业务建议写在Service文件夹中，方便被共用。controller和console中只建议获取输入和输出响应以及对各种service业务逻辑的调用组装等，为了方便service中的函数的公用，不建议在直接吧 $request 这样的作为参数传递给 service中的函数，也就是不要在controller和console之外的地方进行输入参数的获取，而是用参数的方式传递。
4. 编写代码的时候要将就可维护性，一定要简单，不要为了逼格复杂化，要方便其他同事也参与维护，除非是觉得很完美的设计，如果是公用的基础库（如composer包，基类）一定要具有可扩展性（如 public、protected、private 关键字的合理使用，一些属性的setter方法的提供等)和尽量具有可测试性
5. 涉及到配置的地方，如果是不同的环境（开发环境，测试环境，生产环境）不同的，需要定义在.env文件中，如果不同环境相同但是是涉及到公司相关账户或则服务器账号密码等需要保密的变量也要定义在.env文件中，而且不建议采用其他的方式引入到git版本库中，避免所有有git权限的开发人员都查看到。
6. 在composer包和一些基础的中涉及到环境变量和配置等的，一定要通过构造函数的方式进行设置，不要采用在__construct方法中调用获取配置的方式，如果框架用的是依赖注入，在类实例化的时候尽量建议不要采用new关键字的方式去生成对象，因为一旦类要进行修改构造函数的时候，会到处去修改，建议一律采用provider的方式去提供实例化的对象工厂方式生成，在调用的地方注入对应的类或则接口或采用框架容器的方式去（如laravel的app()->make(ClassName::class)或app(ClassName::class)，如果采用这种方式建议对对象的变量进行注释声明方便ide跳转，方便其他项目参与人员看代码增加可维护性）
7. URL尽量语义化，不一定完全要求restful的方式，http method不做强制要求，如url推荐POST /user/{user_id:\d+}/trade/{trade_id:\d+}，不推荐 POST /user/trade/create
8. 不是自己负责的代码不要去改，一定要经过模块开发的人确认后确定有谁来负责修改，因为你可能不知道里边具体实现的原因或则会不会修改后引起其他地方的错误（比如是否有命令行脚本异步更新数据，命令行脚本的地方是否需要也进行逻辑更新等）
9. 同理对于数据库，不是自己模块的数据表不要在未经模块开发的人确认后去进行修改
10. PHP The Right Way 代码不光要你能懂，还要让你的队友能懂； 不要炫技。