文档仓库地址：https://github.com/hfcorriez/fig-standards
PSR规范中文版
PSR-0自动加载
PSR-1基本代码规范
PSR-2代码样式
PSR-3日志接口 为何规范
摘录翻译了官方的一句话 本组织旨在通过讨论我们代码项目的共同点以找出一个协作编程的方法。
在此想到了一篇文章《Google为何要执行严格的代码规范》中有这么一段话：
在谷歌，我可以查看任何的代码，进入所有谷歌的代码库，我有权查看它们。事实上，这种权限是很少人能拥有的。但是，让我感到惊讶的却是，如此多的编码规范—缩进，命名，文件结构，注释风格—这一切让我出乎意料的轻松的阅读任意一段代码，并轻易的看懂它们。这让我震惊—因为我以为这些规范是微不足道的东西。它们不可能有这么大的作用—但它们却起到了这么大的作用。当你发现只通过看程序的基本语法结构就能读懂一段代码，这种时间上的节省不能不让人震撼！
各位看官我就不用多说关于规范的事情了。
写在最后
规范不是义务的，当然你也可以选择自己的方式，但使用规范会让你的合作更轻松。如今各种更现代化应用的编写已不像从前，一个应用一般都有非常多的模块组成，如果不执行规范，只会让整个项目的理解和沟通更加复杂。
若使用了规范，对项目和自己的好处当然不言而喻的。
所有已接受的规范参考：https://github.com/hfcorriez/fig-standards/tree/zh_CN/接受
代码样式规范
本指南的意图是为了减少不同开发者在浏览代码时减少认知的差异。 为此列举一组如何格式化PHP代码的共用规则。
各个成员项目的共性组成了本文的样式规则。当不同的开发者在不同的项目中合作时，将会在这些不同的项目中使用一个共同的标准。 因此，本指南的好处不在于规则本身，而在于共用这些规则。
在 RFC 2119中的特性关键词”必须”(MUST)，“不可”(MUST NOT)，“必要”(REQUIRED)，“将会”(SHALL)，“不会”(SHALL NOT)，“应当”(SHOULD)，“不应”(SHOULD NOT)，“推荐”(RECOMMENDED)，“可以”(MAY)和“可选”(OPTIONAL)在这文档中将被用来描述。
1. 大纲
代码必须遵守 PSR-1。
代码必须使用4个空格的缩进，而不是制表符。
一行代码长度不应硬性限制；软限制必须为120个字符；也应当是80个字符或者更少。
在namespace声明下面必须有一个空行，并且use声明代码块下面也必须有一个空行。
类的左花括号必须放到下一行，右花括号必须放在类主体的下一行。
方法的左花括号必须放在下一行，右花括号必须放在方法主体下面。
所有的属性和方法必须有可见性(译者注：Public, Protect, Private)声明；abstract和final声明必须在可见性之前；static声明必须在可见性之后。
控制结构的关键词必须在后面有一个空格； 方法和函数不可有。
控制结构的左花括号必须放在同一行，右花括号必须放在控制主体的下一行。
控制结构的左括号后面不可有空格，右括号之前不可有空格。
1.1. 示例
本示例包含上面的一些规则简单展示：
namespace VendorPackage;
use FooInterface;
use BarClass as Bar;
use OtherVendorOtherPackageBazClass;
class Foo extends Bar implements FooInterface
{
public function sampleFunction($a, $b = null)
{
if ($a === $b) {
bar();
} elseif ($a
相关文章
