PHP PSR-1 Basic Code Specification (Chinese version)

PHP PSR-1 Basic Code Specification (Chinese version)

Basic code Specification

This specification formulates the relevant standards for the basic elements of Code,
To ensure a high degree of technical interoperability between shared PHP code.

Keywords "must" ("must"), "must not/must not be" ("must not"), "Need" ("REQUIRED"),
"Will" ("Shall"), "no" ("Shall not"), "should" ("should"), "shouldn't" ("should not"),
Detailed descriptions of "recommended" ("RECOMMENDED"), "Can" ("may") and "optional" ("OPTIONAL") can be found in RFC 2119.

1. Overview

• The PHP code file must be 或 标签开始；

• PHP代码文件必须以 不带BOM的 UTF-8 编码；

• PHP代码中应该只定义类、函数、常量等声明，或其他会产生 从属效应 的操作（如：生成文件输出以及修改.ini配置文件等），二者只能选其一；

• 命名空间以及类必须符合 PSR 的自动加载规范：PSR-0 或 PSR-4 中的一个；

• 类的命名必须遵循 StudlyCaps 大写开头的驼峰命名规范；

• 类中的常量所有字母都必须大写，单词间用下划线分隔；

• 方法名称必须符合 camelCase 式的小写开头驼峰命名规范。

2. 文件

2.1. PHP标签

PHP代码必须使用 长标签 或 短输出标签；
一定不可使用其它自定义标签。

2.2. 字符编码

PHP代码必须且只可使用不带BOM的UTF-8编码。

2.3. 从属效应（副作用）

一份PHP文件中应该要不就只定义新的声明，如类、函数或常量等不产生从属效应的操作，要不就只有会产生从属效应的逻辑操作，但不该同时具有两者。

“从属效应”(side effects)一词的意思是，仅仅通过包含文件，不直接声明类、
函数和常量等，而执行的逻辑操作。

“从属效应”包含却不仅限于：生成输出、直接的 require 或 include、连接外部服务、修改 ini 配置、抛出错误或异常、修改全局或静态变量、读或写文件等。

以下是一个反例，一份包含声明以及产生从属效应的代码：

 // 从属效应：修改 ini 配置ini_set('error_reporting', E_ALL);// 从属效应：引入文件include "file.php";// 从属效应：生成输出echo "\n";// 声明函数function foo(){ // 函数主体部分}

下面是一个范例，一份只包含声明不产生从属效应的代码：

 // 声明函数function foo(){ // 函数主体部分}// 条件声明**不**属于从属效应if (! function_exists('bar')) { function bar() { // 函数主体部分 }}

3. 命名空间和类

命名空间以及类的命名必须遵循 PSR-0.

根据规范，每个类都独立为一个文件，且命名空间至少有一个层次：顶级的组织名称（vendor name）。

类的命名必须 遵循 StudlyCaps 大写开头的驼峰命名规范。

PHP 5.3及以后版本的代码必须使用正式的命名空间。

例如：

 // PHP 5.3及以后版本的写法namespace Vendor\Model;class Foo{}

5.2.x及之前的版本应该使用伪命名空间的写法，约定俗成使用顶级的组织名称（vendor name）如 Vendor_ 为类前缀。

 // 5.2.x及之前版本的写法class Vendor_Model_Foo{}

4. 类的常量、属性和方法

此处的“类”指代所有的类、接口以及可复用代码块（traits）

4.1. 常量

类的常量中所有字母都必须大写，词间以下划线分隔。
参照以下代码：

 namespace Vendor\Model;class Foo{ const VERSION = '1.0'; const DATE_APPROVED = '2012-06-01';}

4.2. 属性

类的属性命名可以遵循 大写开头的驼峰式 ($StudlyCaps)、小写开头的驼峰式 ($camelCase) 又或者是 下划线分隔式 ($under_score)，本规范不做强制要求，但无论遵循哪种命名方式，都应该在一定的范围内保持一致。这个范围可以是整个团队、整个包、整个类或整个方法。

4.3. 方法

方法名称必须符合 camelCase() 式的小写开头驼峰命名规范。

因psr-0已废弃故没有转

原文：PizzaLiu github

