The Terms are structured to take into account the basic coding elements required to ensure a high level of coordination in shared PHP code.
prerequisite
To avoid ambiguity, the following terms are explained in advance.
-
~しなければなりません
: Must be, must. -
~してはいけません
: Strictly forbidden, forbidden. -
~したほうがいいです
: you should Recommended. -
~しないほうがいいです
: unsuitable, inappropriate practice. -
~してもいいです
: Possible, allowed.
Reference: RFC 2119
1. Overview
-
PHP code is
<?php
or<?=
You have to use tags. -
PHP character encoding must use UTF-8 (no BOM).
-
You should separate files for declaring symbols (classes, functions, constants, etc.) from files for doing side-effects (generating output, changing ini settings, etc.).
-
For namespaces and classes PSR-4 must comply with
-
The class name is
StudlyCaps
capitalize the first letter of a word, such as upper camel case must be defined in -
Class constants must be defined using all uppercase letters and underscores (snake case) as delimiters.
-
Method names are
camelCase
Lowercase the first letter of a word, like lower camel case must be defined in
2. File
2.1. PHP tags
PHP code is <?php ?>
or <?= ?>
You have to use tags. Do not use any other tags.
2.2. Character code
PHP character encoding must use UTF-8 (no BOM).
2.3. Side effects
Files for declaring new symbols (classes, functions, constants, etc.) should be separated from files for processing with side effects. Don't try to do both in one file
By "side effects" here I mean things that aren't directly related to declaring classes, functions, and constants that are performed just by including the file.
Operations with side effects include: However, the list is not exhaustive:
- Generate output
- direct
require
orinclude
Use of - Connections to external services
- Fix ini settings
- Raise errors and exceptions
- Modifying global and static variables
- Reading/writing from files, etc.
The following example contains both declarations and side effects. It's better not to write like this
<?php // 「副作用」:iniの設定を変更していますini_set ( 'error_reporting' , E_ALL ); // 「副作用」:ファイルを読み込んでいますinclude "file.php" ; // 「副作用」:出力を生成していますecho "<html> \n " ; // 宣言function foo () {
// function body }
The following example contains only declarations and no side effects. It's better to write like this.
<?php
// 宣言function foo () { // 関数本体} // 条件付きの宣言は副作用ではありませんif ( ! function_exists ( 'bar' )) { function bar () { // 関数本体} }
3. Namespaces and classes
PSR-4 must comply with
PSR-4 According to it should be 1 class 1 file. Also, at least the top-level (vendor name) namespace must be defined.
The class name is StudlyCaps
capitalize the first letter of a word, such as upper camel case must be defined in
As of PHP 5.3 you must use the correct namespace.
for example:
<?php
// PHP 5.3 以降
namespace Vendor\Model ;
class Foo
{
}
Prior to PHP 5.2, it's better to use the "Vendor_" prefix on class names to pseudo-namespace them.
<?php
// PHP 5.2以前class Vendor_Model_Foo { }
4. About class constants, properties and methods
Class here includes all general classes, interfaces and traits.
4.1. Constants
Class constants must be defined using all uppercase letters and underscores (snake case) as delimiters.
for example:
<?php
namespace Vendor\Model ; class Foo
{
const VERSION = '1.0' ;
const DATE_APPROVED = '2012-06-01' ;
}
4.2. Properties
You can define the property naming convention in the following format
-
upper camel case (
$StudlyCaps
) -
lower camel case (
$camelCase
) -
snake case (
$under_score
)
Whatever naming convention you use, it's a good idea to be consistent within the appropriate scope. Scope here refers to vendor level, package level, class level or method level.
4.3. Methods
Method names are camelCase
Lowercase the first letter of a word, like lower camel case must be defined in
*This article is based on the " Japanese document creation style standard rules "
*This article was written by our employee Wu Jie Lindelin.org This article was reprinted and published as a contribution article for .