PHP编码风格 - PSR-1

 提示:转载请注明原文链接

 本文链接:https://360us.net/article/15.html

基本代码规范
本章节包含应该考虑怎样的代码元素规范来确保共享的PHP代码之间有一个较高水平的技术互操作性。
本文出现的关键字 "MUST"(务必), "MUST NOT"(不必), "REQUIRED"(要求), "SHALL"(将要), "SHALL NOT"(不应该), "SHOULD"(应当), "SHOULD NOT"(不应当), "RECOMMENDED"(推荐), "MAY"(可能), 和 "OPTIONAL"(可选)在RFC 2119里面有解释。

1、概述
  1.1、文件务必(MUST)只使用<?php<?标签。
  1.2、PHP代码文件务必(MUST)只使用utf-8无BOM格式编码。
  1.3、文件应该(SHOULD)要么声明符号(类,函数,常量等),要么引起副作用(生成输出,改变.ini设置等),不应该(SHOULD NOT)两件事都做(下面有解释)。
  1.4、命名空间和类应该(MUST)遵循PSR-0规范。
  1.5、类名必须(MUST)用StudlyCaps风格声明。
  1.6、类常量必须(MUST)只用大写字母和下划线声明。
  1.7、方法名必须(MUST)用camelCase(驼峰命名法)风格声明。

2、文件
  2.1、PHP标签
       PHP代码需(MUST)使用长标签<?php ?>或者短标签<?= ?>,不要使用(MUST NOT)其他的变种标签。
  2.2、字符编码
       只使用(MUST)UTF-8无BOM格式的编码。
  2.3、副作用(Side Effects)
       一个文件应该(SHOULD)只声明新符号(类,函数,常量等),并且不引起其他的副作用,或者只(SHOULD)执行副作用的逻辑,就是不要(SHOULD NOT)都做。
       副作用(side effects)这个词的意思是执行逻辑和类,函数,常量等没有直接的关系,而只是包含(including)文件。
       副作用(side effects)包括但不限于:生成输出,显示的使用require和include,连接外部服务,修改ini设置,触发错误和异常,修改全局或者静态变量,读或者写文件等等。
       下面一个例子是同时包含了声明和副作用:

<?php
// side effect: change ini settings
ini_set('error_reporting', E_ALL);

// side effect: loads a file
include "file.php";

// side effect: generates output
echo "<html>\n";

// declaration
function foo()
{
    // function body
}

        下面是一个只有声明没有副作用的例子:

<?php
// declaration
function foo()
{
    // function body
}

// conditional declaration is *not* a side effect
if (! function_exists('bar')) {
    function bar()
    {
        // function body
    }
}

3、命名空间和类的名字
    命名空间名和类名需(MUST)遵循PSR-0规范。
    意思是说,一个类就一个文件,并且在一个最小级别的命名空间里面:顶级供应商名(vendor name)。
    类名的风格必须(MUST)是StudlyCaps(驼峰命名法的变种)。
    PHP5.3或者更高版本的代码,需(MUST)使用正式的命名空间。
    例如:

<?php
// PHP 5.3 and later:
namespace Vendor\Model;

class Foo
{
}

    PHP5.2或者更早版本的代码,类名需(SHOULD)使用Vendor_作为前缀的伪命名空间约定。

<?php
// PHP 5.2.x and earlier:
class Vendor_Model_Foo
{
}


4、类常量,熟悉和方法
    这里的术语类,泛指类、接口(interface)和traits。
    4.1、常量
      类常量的声明必须(MUST)只使用大写字母和下划线。例如:

<?php
namespace Vendor\Model;

class Foo
{
    const VERSION = '1.0';
    const DATE_APPROVED = '2012-06-01';
}

    4.2、属性
      本指南特意避免任何建议关于使用诸如$StudlyCaps, $camelCase, 和 $under_score形式的属性名。
      无论使用何种命名约定,都应该(SHOULD)在一个合理的范围内始终坚持下去。
      这个范围可能是一个供应商级(vendor-level),包级(package-level),类级(class-level),或者是一个方法级(method-level)。
    4.3、方法
      方法名的声明必须(MUST)使用诸如camelCase()的形式,就是驼峰命名法。

本文翻译自:http://www.php-fig.org/psr/psr-1/


本文链接:https://360us.net/article/15.html