fig-php PSR Specification Series 1-Basic coding specification

1. Introduction to Fig-php and PSR

Fig-php developed a series of PHP development specifications, referred to as PSR, here is the Framework interoperability Workgroup (Framework interoperability Group) abbreviation, PSR is the PHP standard recommended (PHP Recommendation) is abbreviated. The fig-php Working Group was originally based on a project representative's discussion of the commonalities between two projects to find ways to work together. The main audience is the project team, but other people in the PHP community are watching. If others are willing to adopt the norms here, then welcome, but this is not the goal of the Working Group. No one in the workgroup will tell you how to build the app.

As of 2015.07, PSR has a total of five specification documents published, namely:

PSR-0 Automatic loading (2014.10.21 obsolete, replacement specification for PSR-4)

PSR-1 Basic Coding Specification

PSR-2 Coding Style

PSR-3 Log Interface

PSR-4 Improved auto-loading

PSR-7 HTTP Message interface

These specifications will be learned in multiple series below, this document is series 1.

2. PSR-1: Basic Coding specification

This specification discusses some of the underlying code specifications so that future code sharing can have a higher degree of technical interoperability between different code.

This specification must (must), not (must not), should (should), should not (should not), the meaning of keywords such as can/might (May) can be found in RFC 2119.

2.1 Overview

The source file must (must) use only

The encoding format of the PHP code in the source file must (must) use only UTF-8 without a byte order mark (BOM). Note: see resources [BOM] for more BOM information.

A source file is recommended only for declarations (classes, functions, constants (constant), etc.) or only for auxiliary operations (for example, output information, modify. ini configuration, etc.), but you should not do both at the same time (should not).

Namespaces (namespace) and classes (class) must follow a PSR auto-load specification: PSR-0 or PSR-4. (Translator Note: Since PSR-0 has been discarded, this is actually equivalent to having to follow the PSR-4 specification.) ）

Class name must use StudlyCaps notation.

(Translator Note: see resources [StudlyCaps], StudlyCaps is an arbitrary case of uppercase and lowercase letters, some of which can be ignored as a notation.) For example, messages may be hidden in uppercase and lowercase letters, such as "shoebox" uppercase letters can be spelled "SEX", lowercase grandmother can spell "hobo", webmail service Hotmail was originally written as Hotmail, capital letters can be spelled out HTML. ）

Constants in class must consist only of uppercase letters and underscores (_).

The method name must be written using the CamelCase (camel-style) notation.

2.2 Files

2.2.1 PHP Tags

The PHP code must use only long tags ( ) or short output labels ( ), and no other tags.

2.2.2 character encoding

The encoding format of the PHP code must use only UTF-8 with no byte order mark (BOM).

2.2.3 Auxiliary function

A source file is recommended only for declarations (classes (class), Functions, constants (constant), etc.) or only for auxiliary operations (for example, output information, modify. ini configuration, etc.), but it is not recommended to do both.

Phrase assist (side effects) means some execution logic that is not directly related to declaring (class), Functions (function), constants (constant), and so on.

(Translator Note: [psr-1-translation 1] side effects translated into side effects, [psr-1-translation 2] in the translation of the subordinate effect, all feel unintelligible, here translation as a complementary role should be better).

(Translator note: the original merely from including the file is not clear what the meaning, left to confirm later).

Ancillary actions include, but are not limited to: generating output, explicitly using require or include, connecting external services, modifying INI configuration, triggering errors or exceptions, modifying global or static variables, reading or modifying files, and so on.

The following is an example file that contains both a declaration and an auxiliary function, which should be avoided:

 
  \ n ";//Declaring function foo () {    //body}

The following is an example file that contains only declarations, which should be advocated:

   
2.3 Space Name (namespace) and class name
  
Namespaces (namespace) and classes (class) must follow an automatic loading specification PSR-0 or PSR-4.
  
This means that there can be only one class in a source file, and at least one level in the namespace: that is, a top-level organization name (vendor name).
  
Class name must use StudlyCaps notation.
  
The code after PHP5.3 must use the formal namespace (namespace)
  
Example:
  
    

  
php5.2.x code suggested using pseudo-namespace Vendor_ as the class name prefix
  
     

  
Constants, properties, and methods for class 2.4
  
The term class refers to all classes (class), interfaces (interface), and trait.
  
2.4.1 Constants
  
Class constants must (must) consist only of uppercase letters and underscores (_). Example:
  
      
2.4.2 Property
  
Class Property naming can follow $stulycaps, $camelCase or $under_score in a style, this specification does not make mandatory requirements, but regardless of which naming method, should be (should) within a certain scope of consistency. This range can be the entire team, the entire package, the entire class, or the entire method.
  
2.4.3 method
  
The method name must (must) be declared using the CamelCase style.
3. References
  
[BOM] A bill of the BOM head of the murder,
  
[Php-fig] Php-fig, http://www.php-fig.org/
  
[psr-1-translation 1] PSR-1 Basic code specification, HTTPS://GITHUB.COM/HFCORRIEZ/FIG-STANDARDS/BLOB/ZH_CN/%E6%8E%A5%E5%8F%97/PSR-1-BASIC-CODING-STANDARD.MD
  
[psr-1-translation 2] PHP PSR-1 Basic Code Specification (Chinese version), http://segmentfault.com/a/1190000002521577
  
[PSR-4] fig-php PSR Specification Series 4-Automatic loading,
  
[RFC2119] Key words for use with RFCs to indicate requirement levels, March 1997, Http://www.ietf.org/rfc/rfc2119.txt
  
[rfc2119-Ruan Yi Feng] RFC2119: The verb that represents the request, http://www.ruanyifeng.com/blog/2007/03/rfc2119.html
  
[StudlyCaps] Studly caps, Https://en.wikipedia.org/wiki/Studly_caps
