PHP coding specification

PHP coding specification Original: http://pear.php.net/manual/en/standards.php Translation: Liao Yue Lei Last Update Date: 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

Ind retaining uses 4 spaces instead of 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-end-p nil indent-tabs-mode (not (string-match "/// (buffer-file-name)) (Buffer-file-name)) String-match "/.php $"))))))) This is the same effect VIM rule: set expandtab set shiftWidth = 4 set softwareTabstop = 4 set tabstop = 4

The control structure control structure includes 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: The control statement should be in control keywords and There should be a space between the starting 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: if (condition) return true; Else Return false; modified code: if (condition) Do Something; // A logic error RETURN TRUE; Else Return false; correct approach: if (condition) {do something; Return True;} else {returnaf false;}

When the function calls the call to the function, 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 above the above. If it is a related assignment, the following form should be used to provide better readability: Function Definition Follow "One true BRACE "agreement function: " one true brace "agreement is the beginning of the curly brackets Not followed by 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;}?>

The online document of the comment type (Class) should comply with PHPDOC (similar to javadoc) agreed. 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 (#).

Contains code in any way unconditionally 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 uses To define the PHP code, not to use Shorthand. This is necessary to meet Pear consistency, but also to transplant the PHP code in different operating systems and different installation settings.

All source code file headers issued by head injection block PEAR should include the following comment block: | // | your name | / / --------------------------------------------- ------------------------ //// $ ID $?> There is no hard rule to add a code contributor's name to the file. Notes in the author list. 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.

The contents of this section using CVS apply only to 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) is used to tag 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 "Money_FAST" package 1.2: $ cd pear / money_fast $ cvs tag release_1_2t fast.phpt ready, you can get your series on the Pear Web website. Release the version. Here is an example of how 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 "QA_2_0_BP" tag is a "Branch Point" tag for labeled branches. 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.

The URL address used in the example in the example should be "eXample.com", "example.org", "example.net".