从代码风格说起,更好的团队协作

在多次 review 新同事代码时,不停的评论哪里应该换行,哪里应该加上一个空格等等,就会思考,这些事情难道不是一开始就默认会做好的吗,我们 review 代码的时候应该全心力的去看代码逻辑,结构,检查其中的疏漏,而不是被这些细节所影响。所以在每个新同事入职的第一天,团队代码风格应该被了解。

好的代码风格让人赏心悦目,今天在这里和大家一起探讨。

基础

首先阅读「PSR 规范」PSR-2 编码风格规范了解基础规范。后文主要是对其的一些补充。

namespace 以及 use 声明

  • namespace 应该与 <?php 间有一行换行
  • use 按照长度从短到长排序
  • 全部命名空间的类调用 use 申明代替 \
<?php

namespace App;

use App;
use App\Bar;
use App\Services\Baz;

class Foo
{
    App::run();
}

如果使用 sublime 作为文本编辑器,可以使用 PHP Companion 来引入命名空间。配置 use_sort_length 为 true 就可以自动为 use 按长度排序了。其他编辑器或者 ide 应该可以找到类似插件。

结构控制

if, elseif, else, foreach, while...

所有的 } 后必须有一行换行,{ 上面也应该有一行换行

<?php

start();

if (true) {
    //
}

end();

! 的使用

! 有一个空格

<?php

if (! $isTrue) {
    //
}

return ! empty($data);

try, catch

如果使用 php7.1 的话,有两个或以上异常做相同的处理,需要使用新的语法结构

<?php

try {
    //
} catch (FirstException | SecondException $e) {
    //
}

PHP 函数

非类,接口,trait 的函数命名使用下划线命名,且先调用 function_exists 查看是否已经申明

<?php

if (! function_exists('code_style')) {
    function code_style() {
        //
    }
}

laravel 不同的地方

. 字符串连接

. 左右两边都有空格

<?php

$coding = 'coding';

echo 'php ' . $coding . ' style';

供学习交流,有不同看法欢迎和我们讨论,???,地址在 LingxiTeam/php_coding_style_guide

本作品采用《CC 协议》,转载必须注明作者和本文链接
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 18
liyu001989

不如试试 php-cs-fixer

7年前 评论

@liyu001989 之前用过,但是更喜欢手动 format,从第一行开始代码质量就定下了

7年前 评论
Cooper

phpstorm 可以设置 PSR-2 风格

7年前 评论
Summer

@Cooper 换头像了,没认出来

7年前 评论
Cooper

@Summer 哈哈

7年前 评论

phpstorm 的代码对齐是遵循的哪个规范?

7年前 评论

@Cooper
@jinwei

不是还有 laravel 专用的风格吗 :smile:

7年前 评论
Luff

问下 PhpStorm 有 use 按照长度从短到长排序 这个快捷键或其它插件吗?

7年前 评论

@QiyueShiyi phpstrom 就是按索引,我找过,没有发现。。。

7年前 评论

sublime 的话,其实可以用 SublimeLinter 进行检查的,装上去用段时间写起来就规范了。

7年前 评论

@RryLee
判断函数是否存在的用途是什么呢?
1.假如以前存在这个函数,重复定义运行时就会报错。假如有了这么个判断更不好排错了,直接调用以前存在的了。
2.假如以前不存在这个函数,这个写的也没啥意义。

7年前 评论

@Boomdawn 先举个很实际的例子,如果你在 TP 中引入 illuminate/support,你会发现很多错误,都是因为 TP 的 function 没有提前判断。

使用第三方库的时候,难免会遇到方法重名的问题,如果你们团队不适用 composer,那当我没说。至于排错,代码都是你和同事一行一行写出来的,发现方法参数不一致,或者效果不一致的时候,很快就可以找到是因为使用的方法不对,那么解决方案应该是换个名字或者其他。再说,不是有 IDE 这种神器吗,这种警告很容易找到。

我们避免的是你的代码或者 package 造成对他人代码的不便。

7年前 评论

@RryLee
你这个比喻不合理哦。两个package 如果有重名的全局函数,除非是两个函数体也完全一致,那么必然有一个无法正常工作了。假如大家的package 都按照你这个先判断是否存在的逻辑来写,首先IDE不会直接提示出来,程序跑起来的时候也是只会跑先载入的package 的函数,这两个package都不是自己团队写的话,那排查问题真的不容易,得寻找调用栈,到底调用的是哪一个。
假如一开始都不这么判断存在写的话,直接就明确的报出来是什么函数重复定义了,多简洁明了啊。最终的解决方案应该是写package的时候,就尽量不写全局函数,函数都带上命名空间就OK了。

7年前 评论

@Boomdawn :100: 是这么个道理,但是全局 helper 还是需要的,laravel 中那么多全局函数也不是白定义的

7年前 评论

我觉得laravel这么写,是因为它站在一个框架的角度,而不是一个包的角度,宁愿自身牺牲一些辅助函数,也要让别的包能好好运行,从而整个框架能正常的开箱。但是我们开箱框架再来开发就没必要这么写了,因为你又不能去包容别的包,而让自己的功能失效。所以不要再判断是否存在了。。。 还有写包给别人用也不要写全局函数了,不然人家写框架的,又要像laravel这样来做妥协。。。@RryLee

7年前 评论

@Boomdawn 正解,对于自己定义的方法确实如此,在开发package时,不影响核心逻辑的辅助方法是应该提前判断的

7年前 评论

git写个钩子,不遵守PSR-2规范的禁止提交:smile:

7年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!