Lecture
This section of the standard describes which code elements should be considered standard, necessary to ensure a high level of technical interaction between common (shared) PHP code.
The keywords “MUST BE” / “MUST” (“MUST”), “MUST NOT” / “NOT SHOULD” (“MUST NOT”), “REQUIRED”, “NEED” (“SHALL”), “NOT” ALLOWED (SHALL NOT), FOLLOW (SHOULD, NOT SUB) ("OPTIONAL") in this document should be treated as described in RFC 2119.
The files MUST use only the tags <?php and <?= .
Files with PHP code MUST use only UTF-8 without BOM.
In one file, SHOULD either declare characters (classes, functions, constants, etc.), or perform side effects (ie, produce output, change .ini values, etc.), but DO NOT have to do another at the same time.
Namespaces and classes MUST conform to the PSR standards describing autoloading: [PSR-0, PSR-4].
Classes MUST be given names in the style of StudlyCaps .
Constants of classes MUST be given uppercase names with an underscore character as a separator.
The methods MUST be given in the style of camelCase .
PHP code MUST use full <? Php tags or an abbreviated form <? =. Use of other tag options is NOT ALLOWED.
PHP code MUST use only UTF-8 without a BOM.
The file SHOULD declare new characters (classes, functions, constants, etc.) without performing side effects, or SHOULD follow the logic, but DO NOT do both at once.
The expression "side effects" means the execution when connecting a file of actions that are not directly related to the declaration of classes, functions, constants, etc.
“Side effects” include (but are not limited to): generating output, explicitly using require or include , connecting to external services, changing ini values, throwing in errors or exceptions, changing global or static variables, reading or writing files, and so on.
Below is an example of a file containing both ads and side effects, i.e. an example of how not to do it:
<?php // побочное действие: изменение значений ini ini_set('error_reporting', E_ALL); // побочное действие: подключение файла include "file.php"; // побочное действие: генерация вывода echo "<html>\n"; // объявление function foo() { // тело функции } The following code contains ads without side effects, i.e., shows an example of how to do it:
<?php // объявление function foo() { // тело функции } // условное объявление *не является* побочным действием if (! function_exists('bar')) { function bar() { // тело функции } } Namespaces and classes MUST comply with the autoloading standards [PSR-0, PSR-4].
This means that each class must be located in a separate file and be in a namespace of at least the first level - corresponding to the name of the developer.
Classes MUST be given names in the style of StudlyCaps .
Code written for PHP versions 5.3 and newer MUST use formal namespaces.
Example:
<?php // PHP 5.3 и новее: namespace Vendor\Model; class Foo { } In code written for PHP versions 5.2.x and earlier, SHOULD use pseudo-namespace convention using the Vendor_ prefix in class names.
<?php // PHP 5.2.x и более ранние: class Vendor_Model_Foo { } The term “class” refers to all classes, interfaces, and treits.
Constants of classes MUST be given uppercase names with an underscore character as a separator.
Example:
<?php namespace Vendor\Model; class Foo { const VERSION = '1.0'; const DATE_APPROVED = '2012-06-01'; } This guide intentionally avoids any guidance regarding the use of the $StudlyCaps , $camelCase , or $under_score for property names.
Whatever the naming convention used, it SHOULD be consistently applied to the entire relevant area of the code. This area may be represented by a developer, package, class, or method level.
Methods MUST be given names in the style of camelCase() .
Comments
To leave a comment
Software and information systems development
Terms: Software and information systems development