前言经常听到一些跟狗屎的对话A：哇，我刚去改**项目的代码，有点怀疑人生狗屎B：我现在的项目就像一个狗屎山C：我隔壁的哥们，每天写代码很随意。我舍不得我的刀。今天和大家聊聊我眼中好孩子的一些编码习惯，不是编码风格习惯。当然，强烈推荐大家的代码风格对齐psr-12和psr-1。psr-1基本编码规范，psr-12编码标准支持该规范扩展、扩展和替换了PSR-2，即编码风格指南，并要求遵守基本编码标准PSR-1。推荐一本书《代码整洁之道》，这本书我都快看完了，推荐一下！！！过多if嵌套判断案例后台有判断用户是否参与活动案例代码的功能){返回真；}}else{返回假；}}else{returntrue}面对这种多条件判断，可以尝试使用拦截法和逆向思维拦截法，只要满足条件就立即返回结果，不用嵌套if。可以理解为横向判断变成纵向判断。Comfort从上到下View>从左到右ViewReversethinking上学的时候大家都知道。查找不符合条件的条件比查找不符合条件的条件要好。这种逻辑代码可以少很多。如果（用户！=VIP）{返回真；}if（用户参与任务）{returnfalse;}if（用户过期时间<=1个月以内）{returntrue;}返回假；没有过多的try-catch嵌套我遇到过很多项目中try-catch过度嵌套，导致顶层的try-catchcatch孤独。示例代码函数insertUser($data){try{userIsInValid();}catch(Exception$exception){}}functionuserIsInValid(){try{//逻辑判断}catch(Exception$exception){returntrue;}返回真；}这样的代码是没有问题的，但是如果假设userIsInValid出现了代码级的错误，虽然不会破坏业务的健壮性，但是没有办法知道问题出在哪里。可能有人会说给Excetion加个log，但是如果嵌套的try-catch太多，查log也是一件很痛苦的事情。1.尽可能在业务最顶层包裹异常，除非是网络IO请求函数。2.如果一定要嵌套异常，需要定义每个异常的类型。3.根据具体的异常尝试捕捉。不建议直接catchException。4.exception和log是一个cp，不要忘了。["code"=>400014,"wx_message"=>"公司没有足够的钱支付","error_message"=>"企业余额不足"],"AMOUNT_LIMIT"=>["code"=>400015,"wx_message"=>"金额限制","error_message"=>"金额超出或被微信风控屏蔽"],.....];如果(array_key_exists($code,$errorCodeMappins)){packApiData($errorCodeMappins[$code]['code'],$errorCodeMappins[$code]['wx_message'],[],$errorCodeMappins[$code]['error_message']);}packApiData(999999,"undefinedmessage",[],"Unknownerror");}建议errorCodeMappins不要放在函数中，可以放在类的顶部或者特殊的枚举类。使用errorCode可以避免调整主流程代码，可以保证主流程代码相对精简，可以针对不同的代码定义错误if($code=="SEND_FAILED"){//支付错误，检查列表看最终结果if($orderInfo[1]['status']=='SUCCESS'){//还是成功，会扣余额PDOQuery($dbcon,'UPDATEuserSETmoney=money-?WHEREopen_id=?',[$payAmount,$openId],[PDO::PARAM_INT,PDO::PARAM_STR]);packApiData(200,'成功',[$orderInfo[1]]);}else{packApiData(400017,'微信支付失败',[],'微信支付支付失败');}}packApiDataByOrderError($code);在合适的场景中使用设计模式。以上只能针对错误码进行修改。如果我们需要不同的错误来进行逻辑处理怎么办？.这时候可以考虑使用设计模式（比如使用多态代替条件表达式）来固化设计模式，但是不要过度使用，否则整个项目会更难维护。你一定坚信，以后你的队友不知道是个什么生物回调代码映射[$代码]；$class->handle();}interfaceOrderStateImp{publicfunctionhandle($context);}classOrderSendFailedimplementsOrderStateImp{publicfunctionhandle($context){}}$callbackCodeMappings也建议配置特殊的枚举文件。给出的代码比较粗糙，但其实可以更稳健地做出一些判断，统一处理浮点计算结果。由于PHP是一种弱对象语言，它总是会面临一堆情况。为什么订单数据错误？接口有问题。$int=0.58;var_dump(intval($int*100));output:57在浮点数中，58被认为是57.999999999999999999999……9999无限接近58。intval强制整数相乘时，默认采用截取的方式。四舍五入，所以最好养成使用BCMath$int=0.58的好习惯；intval(strval($int*100))或BCMATHbcmul(0.58,100,0)每次计算一个浮点数；鼓励使用Globalerrorcode来控制错误编写接口我们很熟悉下面的json格式{"success":true,"error_code":0,"message":"","results":[]}为以下code熟悉if(***){$this->error(999,"****",[]);}此类结果的错误代码容易重复，没有统一管理。事实上，唯一的错误代码应该有助于如下。1.前端可以根据错误码做逻辑处理2.根据错误码可以直接快速定位到错误码。建议1050001,"message"=>"用户已被停用"];}$this->error(UserErrorCode::USER_DISABLE_ERROR);错误码建议1-2位-项目代码|3-4位-模块代码|5-7位特定业务错误代码是可靠的命名约定不可靠的命名总是会产生误导。比如变量名为userArrayList，我以为是数组列表变量，其实是对象列表。1.做出有意义的区分。例如，singleUserItem和userItem有什么区别？例如，getUserList和getUsers有什么区别？我真的不知道怎么读。尽量用拼音来硬拼。例如，百度的一个接口对接变量的名称是hundredDegree，而不是baidu。其他的可以参考《代码简洁之道》使用中间件。接口总会遇到很多类似的操作，比如1.身份检测2.权限判断3.请求参数过滤调整4.记录接口信息5.接口限流每个接口的实现我都看过，也看过初始化一个ControllerBase类，实现这些，子类Controller继承这些。其实我们可以把它分离成中间件来实现好处。我们可以根据不同的接口组合和选择中间件，而不是专门编写代码。函数的单一职责是最重要的，最重要的，恶心的代码大多来自函数的职责不明确，有的全部塞在一起，一块一块的。事实上，关于单一职责的文章有很多，描述了如何测试或编写符合标准的单一职责。画流程图如果你能把业务流程图画得很清楚，那么你的职能职责也就确定了。=0,<60,返回[Fail]3.如果分数>=60,<70,返回[Pass]4.如果分数>=70,<80返回【一般】5.如果score>=80，<90返回【Good】5。如果分数>=90，<100返回【优秀】6。如果score=100返回【满分】
