从代码风格说起，更好的团队协作
0 / 18 / 创建于 7年前
RryLee 的个人博客
在多次 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 协议》，转载必须注明作者和本文链接
关于 LearnKu
粤公网安备 44030502004330号
不如试试 php-cs-fixer
@liyu001989 之前用过，但是更喜欢手动 format，从第一行开始代码质量就定下了
phpstorm 可以设置 PSR-2 风格
@Cooper 换头像了，没认出来
@Summer 哈哈
phpstorm 的代码对齐是遵循的哪个规范？
@Cooper
@jinwei
不是还有 laravel 专用的风格吗 :smile:
问下 PhpStorm 有 use 按照长度从短到长排序 这个快捷键或其它插件吗？
@QiyueShiyi phpstrom 就是按索引，我找过，没有发现。。。
sublime 的话，其实可以用 SublimeLinter 进行检查的，装上去用段时间写起来就规范了。
@RryLee
判断函数是否存在的用途是什么呢？
1.假如以前存在这个函数，重复定义运行时就会报错。假如有了这么个判断更不好排错了，直接调用以前存在的了。
2.假如以前不存在这个函数，这个写的也没啥意义。
@Boomdawn 先举个很实际的例子，如果你在 TP 中引入 illuminate/support，你会发现很多错误，都是因为 TP 的 function 没有提前判断。
使用第三方库的时候，难免会遇到方法重名的问题，如果你们团队不适用 composer，那当我没说。至于排错，代码都是你和同事一行一行写出来的，发现方法参数不一致，或者效果不一致的时候，很快就可以找到是因为使用的方法不对，那么解决方案应该是换个名字或者其他。再说，不是有 IDE 这种神器吗，这种警告很容易找到。
我们避免的是你的代码或者 package 造成对他人代码的不便。
@RryLee
你这个比喻不合理哦。两个package 如果有重名的全局函数，除非是两个函数体也完全一致，那么必然有一个无法正常工作了。假如大家的package 都按照你这个先判断是否存在的逻辑来写，首先IDE不会直接提示出来，程序跑起来的时候也是只会跑先载入的package 的函数，这两个package都不是自己团队写的话，那排查问题真的不容易，得寻找调用栈，到底调用的是哪一个。
假如一开始都不这么判断存在写的话，直接就明确的报出来是什么函数重复定义了，多简洁明了啊。最终的解决方案应该是写package的时候，就尽量不写全局函数，函数都带上命名空间就OK了。
@Boomdawn :100: 是这么个道理，但是全局 helper 还是需要的，laravel 中那么多全局函数也不是白定义的
我觉得laravel这么写，是因为它站在一个框架的角度，而不是一个包的角度，宁愿自身牺牲一些辅助函数，也要让别的包能好好运行，从而整个框架能正常的开箱。但是我们开箱框架再来开发就没必要这么写了，因为你又不能去包容别的包，而让自己的功能失效。所以不要再判断是否存在了。。。 还有写包给别人用也不要写全局函数了，不然人家写框架的，又要像laravel这样来做妥协。。。@RryLee
@Boomdawn 正解，对于自己定义的方法确实如此，在开发package时，不影响核心逻辑的辅助方法是应该提前判断的
git写个钩子，不遵守PSR-2规范的禁止提交:smile:
@张小张 最近正准备做