HREF = "style.css" rel = "stylesheet" type = "text / css">
PHP coding specification
Original: http://pear.php.net/manual/en/standards.php Translation: Liao Yue Lei Last update: 2003/05/06
Content list
Inditive Control Structure Function Call Function Definition Note Contains Code PHP Code Markhead Release Block Use CVS Example URLS Name Connection
indentation
Ind retains 4 spaces, not TAB. If you use Emacs to edit PEAR code, you should set Indent-Tabs-Mode as NIL. Below is an example of a Mode Hook, which is used to set Emacs compliance with indentation criteria (you must make sure that these settings take effect when editing the PHP file):
(DEFUN PHP-MODE-HOOK () (Setq Tab-Width 4 C-Basic-Offset 4 C-Hanging-Comment-Ender-P Nil Indent-Tabs-Mode (NOT (String-Match "/// (PEAR) / / | PEAR / / / (Buffer-file-name))))))))))))))))))
Here is the equivalent of VIM rules:
SET ExpandTab Set ShiftWidth = 4 Set SoftTabStop = 4 set tabstop = 4
Control structure
The control structure contains IF, for, while, switch, etc. Here is an example of an IF statement and an example of a switch statement:
An example of if statement:
Sample of Switch statement:
The control statement should have a space between the control keyword and the parentheses, and this is different from the function call.
It is highly recommended that you always use the curly brackets to identify each part of the control structure. Even if it is technically not used where the currency is used. This can increase the readability of the code while avoiding the introduction of logical errors after increasing the new row.
Original code:
Else Return false;
Modified code:
IF (condition) Do Something; // A logic error RETURN TRUE; ELSE RETURN FALSE
Correct approach:
IF (Condition) {do something;} else {return false;}
Function call
When the function is called, there should be a blank character between the function name and the starting parentheses. There should be no spaces between parameters and start and end parentheses. In addition to the first parameters, other parameters should be separated by a space. Here is an example:
A space should be used on both sides of the sample code, assignment operation, etc. If it is the relevant assignment, the following form should be used to provide better readability:
>
Function definition
Follow the "One True Brace" agreed to declare the function:
"One True Brace" contemplate is the beginning of the curly brackets, rather than following other statements.
Parameters with default values should be located behind the parameter list (in fact the PHP language definition is also required). If appropriate, the function should always return a meaningful value. Here is a slightly longer example:
raiseerror ();} return true;}?>
Comment
Type (Class) online documentation should comply with PHPDOC (similar to javadoc) agreement. More information about phpdoc can access http://www.phpdoc.de/.
In addition, non-document comments strongly encouraged. General rules are to add short introductory comments for code that is easy to forget.
Recommended annotations (/ * * /) and standard C annotations (//) without using C notes should not be used (#).
Containing code
Regardless of where there is unconditional contains a type file, it should be used to use Require_once (). If conditional contains a type file (for example, using factory methods), include_once () should be used. Use any of the two to ensure that the type file contains only once. They share a list of files, so you don't need to worry about confusing them - a file will not be included again after INCLUDE_ONCE () after using the request ().
Remarks: include_once () and request_once () are a declaration instead of a function. You don't need to use parentheses to expand the file name (but use parentheses does not have an error).
PHP code tag
Always define the php code , Not to use . This is necessary to meet Pear consistency, but also to transplant the PHP code in different operating systems and different installation settings.
Head note block
All source code file headers issued by PEAR should contain the following comment block:
| // | your name
There is no hard specification to add a code contributor's name to the author list of the file annotation. Under normal circumstances, their changes belong to the "Substantial" directory (meaning about 10% to 20% of the code has been rewritten). There is an exception to code contributors to overwrite functions or contribute new program logic.
Simple code reorganization and bug fix should not increase new author, this is not appropriate.
Files in the core PEAR warehouse should have a similar comment block to illustrate copyright, license agreement and author. All files should contain a mode line (Modeline, for VIM and Emacs) to ensure consistency.
CVS
The content of this section is only suitable for use CVS packages on cvs.php.net.
In each file contains $ ID $ (the keyword between the two $ symbols can not have space, but because this document is also managed with CVS, I have to add a space to avoid being replaced by CVS) CVS keywords so that View the current status of the file and the last modification time and other information. If "Last Modified:" already exists, it is replaced with a $ ID $ tag. Other contents of this section assume that you have basic knowledge about CVS tags and branches.
The CVS tag is used to identify the revision made before the file release in your package. The following list is required for use and recommended CVS tags:
RELEASE_N_N
(Required) Used to mark a release version. If you don't use this tag, others have no way to get your package from the CVS server when you release a release version.
QA_n_n
(Branch, optional) If you think it is necessary to provide a candidate release version before publishing the release version, then a good idea is to add a branch. This branch allows you to isolate the release version and update these branches separately for these branches. During the period, normal development work can continue on the backbone.
MAINT_N_N
(Branch, optional) If you need to create a smaller modified release version (for example, after 1.2 after 1.2). Then you can create a branch to achieve your purpose.
Only Release tags are necessary, other tags are recommended for easy recommendation.
Below is an example of how to release the version to increase the tag for the "Money_FAST" package 1.2:
$ cd pear / money_fast $ cvs tag release_1_2 t fast.php t ready t package.xml
After the above operation, you can get your series of releases on the Pear Web site.
Here is an example of how to build a QA branch:
$ cvs tag qa_2_0_bp ... $ cvs RTAG -B -R QA_2_0_bp QA_2_0 $ cvs Update -R QA_2_0 $ CVS Tag Release_2_0rc1 ... and the the Actual Release, From The Same Branch: $ CVS Tag Release_2_0
The "QA_2_0_bp" tag is a "BRANCH POINT" tag for the start of the mark branch. Always use such markers to indicate the beginning of the branch is a good idea. The MAINT branch can use the Release tag as its branch starting point.
URL in the example
The URL address used in all examples should be "eXample.com", "eXample.org", "eXample.net".
Naming agreement
In general, the names of Class, Functions, and variables should always be able to describe the role of this code that allows code readers to easily know.
Classes
Class should have a descriptive name. You should avoid using abbreviations. The Class name should always start with a capital letter. The hierarchy of Pear Class can also be reflected from the Class name. Each level in the hierarchy is separated by underscore. A good Class name is, for example,:
LOG NET_FINGER HTML_UPLOAD_ERROR
Function and method
Functions and methods should be named using the "Studly Caps" style. The function should be prefixed by the name of the package to avoid name conflicts with other packages. The name of the name (after the prefix) should be lowercase, each new word should begin with uppercase letters. Here are some examples:
Connect () getData () buildsomewidget () XML_RPC_Serializedata () Private Class member and attribute (means that Class members and properties should only be used by members declared in the same class. However, PHP does not support mandatory private namespace) should be used One underscore starts. Example:
_Sort () _inittree () $ this -> _ status
constant
Constants should always use uppercase letters named, separated by underscore. The prefix of constant names should use uppercase Class / package names. For example: all constants used in DB :: pack are db_ start.
Global variable
If your package needs to define global variables, you should use the next line to follow the name and another underscore as the beginning. For example, the PEAR package uses a global variable name $ _pear_destructor_object_list.
Predefined Values True, False and Null
PHP's internal value true, false and null must be written with lowercase letters.
