Copyright belongs to the original all ..... .....
Go PHP Coding Specification
In a more detailed explanation of the program in the preparation of the issues to be noted.
But the norm is just a habit, not a compulsion, and you can totally disobey it. But develop a good code writing habit,
Personally, I think it's necessary.
PHP Coding Specification
Original: http://pear.php.net/manual/en/standards.php
Translation: Lio Yure
Last Updated on: 2003/05/06
Table of Contents
Indent in
Control structure
Function call
function definition
Comments
Contains code
PHP Code Tags
Header comment Block
Using CVS
Example URLs
Naming conventions
--------------------------------------------------------------------------------
Indent in
Indents use 4 spaces instead of tab. If you use Emacs to edit the PEAR code, you should set Indent-tabs-mode
to nil. Here is an example of a mode hook that sets Emacs to conform to the indentation standard (you must make sure that you edit the PHP file
, these settings take effect):
(Defun Php-mode-hook ()
(Setq tab-width 4
C-basic-offset 4
C-hanging-comment-ender-p Nil
Indent-tabs-mode
(not
(and (String-match "/(Pear|pear)/" (Buffer-file-name))
(String-match ". php$" (Buffer-file-name))))))
Here are the same-effect vim rules:
Set Expandtab
Set shiftwidth=4
Set softtabstop=4
Set tabstop=4
--------------------------------------------------------------------------------
Control structure
The control structure contains if, for, while, switch, and so on. Here is an example of an if statement and an example of a switch statement:
Example of an IF statement:
| CODE: |
[Copy to Clipboard] |
if ((condition1) | | | (Condition2)) {
Action1;
} elseif ((Condition3) && (Condition4)) {
Action2;
} else {
DefaultAction;
}
?> |
|
Example of a switch statement:
| CODE: |
[Copy to Clipboard] |
Switch (condition) {
Case 1:
Action1;
Break
Case 2:
Action2;
Break
Default
DefaultAction;
Break
}
?> |
|
The control statement should have a space between the control key and the opening parenthesis to distinguish it from the function call.
It is strongly recommended that you always use curly braces to identify the parts of the control structure. Even if it is technically possible to not use curly braces. This
You can increase the readability of your code while avoiding the introduction of logical errors after adding new lines to the structure section.
Original code:
| CODE: |
[Copy to Clipboard] |
if (condition)
return true;
Else
return false; |
|
The Modified code:
| CODE: |
[Copy to Clipboard] |
if (condition)
Do something; A logic error occurred
return true;
Else
return false; |
|
The right approach:
| CODE: |
[Copy to Clipboard] |
if (condition) {
Do something;
return true;
} else {
return false;
} |
|
--------------------------------------------------------------------------------
Function call
When a function is called, there should be no white-space characters between the letter name and the opening parenthesis. There should be no space between the argument and the opening and closing parentheses.
In addition to the first argument, all parameters should be separated by a single space. Here's an example:
| CODE: |
[Copy to Clipboard] |
$var = foo ($bar, $baz, $quux);
?> |
|
Like the example code above, a space should be used on both sides of the assignment operation equals sign. If it is a related assignment operation, you should use the following
form to provide better readability:
| CODE: |
[Copy to Clipboard] |
$short = foo ($bar);
$long _variable = foo ($baz);
?> |
|
--------------------------------------------------------------------------------
function definition
Declare the function according to the "one True brace" convention:
| CODE: |
[Copy to Clipboard] |
function Foofunction ($arg 1, $arg 2 = ")
{
if (condition) {
Statement
}
return $val;
}
?> |
|
The "One true brace" convention is to start with a single row of curly braces instead of following the other statements.
Parameters with default values should be behind the parameter list (in fact the PHP language definition also requires this). If appropriate, the function should
Always returns a value that is meaningful. Here's a slightly longer example:
| CODE: |
[Copy to Clipboard] |
Function Connect (& $DSN, $persistent = False)
{
if (Is_array ($DSN)) {
$dsninfo = & $dsn;
} else {
$dsninfo = DB::p arsedsn ($DSN);
}
if (! $dsninfo | |! $dsninfo [' Phptype ']) {
return $this->raiseerror ();
}
return true;
}
?> |
|
--------------------------------------------------------------------------------
Comments
The online documentation for type (class) should conform to PHPDOC (similar to JAVADOC) conventions. More information about PHPDOC can be
Access to http://www.phpdoc.de/obtained.
In addition, the use of non-document annotations is strongly encouraged. The general rule is to add a brief introductory comment to the code that is easy to forget.
C-style Comments (/*/) and standard C + + annotations (//) are recommended instead of Perl/shell-style Comments (#).
--------------------------------------------------------------------------------
Contains code
No matter where you unconditionally include a type file, you should use Require_once (). If there is a conditional file that contains a type
(for example, using a factory method), you should use Include_once (). Using either of these can ensure that the type file contains only
A. They share a list of files, so you don't have to worry about confusing them?? A file that uses require_once () contains
Will not be included again in Include_once ().
Note: include_once () and require_once () are a declaration, not a function. You do not need to use parentheses to enlarge the file name
(However, there is no error with parentheses).
--------------------------------------------------------------------------------
PHP Code Tags
Always use To define the PHP code instead of using the Shorthand method. This is necessary to conform to the PEAR consistency
Required for porting PHP code in different operating systems and under different installation settings.
--------------------------------------------------------------------------------
Header comment Block
The header of all source code files published by PEAR should contain the following comment block:
| CODE: |
[Copy to Clipboard] |
/* Vim:set expandtab tabstop=4 softtabstop=4 shiftwidth=4: */
// +----------------------------------------------------------------------+
// | PHP Version 4 |
// +----------------------------------------------------------------------+
// | Copyright (c) 1997-2002 the PHP Group |
// +----------------------------------------------------------------------+
// | This source file was subject to version 2.0 of the PHP license, |
// | That's bundled with the "This" file LICENSE, and is |
// | Available at through-World-wide-web at |
// | Http://www.php.net/license/2_02.txt. |
// | If you do not receive a copy of the PHP license and is unable to |
// | Obtain it through the World-wide-web, please send a note to |
// | License@php.net so we can mail you a copy immediately. |
// +----------------------------------------------------------------------+
// | Authors:original Author |
// | Your Name |
// +----------------------------------------------------------------------+
//
$ ID $
?> |
|
There is no hard rule to add the name of a code contributor to the list of authors of a file comment. In general, their changes
belongs to the "substantial" directory (meaning about 10% to 20% of the code is rewritten). One exception is that the code contributor overrides the function
or to contribute new program logic.
Simple code reorganization and bug fixing should not add new authors, which is inappropriate.
Files that are not in the core PEAR repository should have a similar comment block to describe the copyright, license Agreement, and author. All files should be wrapped
Includes a pattern line (Modeline, for Vim and Emacs) to ensure consistency.
--------------------------------------------------------------------------------
Using CVS
The content of this section is only applicable to packages using CVS on cvs.php.net.
In each file contains $Id $ (the keyword between two $ symbols cannot have spaces, but because this document is also managed with CVS
, so you have to add a space to avoid being replaced by CVS) The CVS keyword to see the current status of the file and the last modification time
Interest. If the "Last Modified:" Message already exists, replace it with the $ID $ tag.
The rest of this section assumes you have a basic knowledge of CVS tags and branching (branches).
CVS tags are used to identify the revisions made before the files in your package are released. The following list is required and recommended for use with CVS tags:
Release_n_n
(required) is used to mark a release version. If you do not use this tag, others will not be able to release a release version in your
Get your package from the CVS server.
Qa_n_n
(branch, optional) If you think that you want to provide a candidate release before releasing the release version, a good idea is to add a
A branch. This branch allows you to isolate release releases and apply them separately before releasing release releases.
Update. During the period, normal development work can continue on the trunk.
Maint_n_n
(branch, optional) If you need to create a minor modified release version (for example, post 1.2.1 after 1.2). Then you can
Create a branch to achieve the purpose.
Only RELEASE marks are required, other marks are recommended for your convenience.
The following is an example of how to add markup to the release version of the "Money_fast" package 1.2:
$ CD Pear/money_fast
$ CVS Tag release_1_2
T fast.php
T README
T package.xml
By doing this, you can get a series of release 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 then the actual release, from the same branch:
$ CVS Tag Release_2_0
The "QA_2_0_BP" tag is a "branch point" tag that marks the beginning of the branch. Always use such markers to indicate branches.
The beginning is a good idea. The MAINT branch can use the RELEASE tag as its branch starting point.
--------------------------------------------------------------------------------
The URL in the example
The URL addresses used in all examples should be "example.com", "example.org", "example.net".
--------------------------------------------------------------------------------
Naming conventions
In general, the names of classes, functions, and variables should always be able to describe the role that code readers can easily understand.
Classes
Class should have a descriptive name. You should avoid using abbreviations when possible. Class names should always be opened with a capital letter
Began. The level of the PEAR class can be reflected from the class name as well. Each level in the hierarchy is delimited by an underscore. Good
Examples of class names are as follows:
Log
Net_finger
Html_upload_error
Functions and methods
Functions and methods should be named with the "studly caps" style. function should prefix the name of the package to avoid the
The function has a name conflict. The letter (after the prefix) of the name should be lowercase, and each new word should start with a capital letter. Below
are some examples:
Connect ()
GetData ()
Buildsomewidget ()
Xml_rpc_serializedata ()
Private class members and attributes (meaning that class members and attributes should only be used by members declared in the same class.) But
PHP does not support mandatory private namespaces) should start with an underscore. Example:
_sort ()
_inittree ()
$this->_status
Constant
Constants should always be named with uppercase letters, with underscores to separate words. Prefixes for constant names should use uppercase class/packets
Name. For example: DB:: All the constants used by the package have been db_ beginning.
Global variables
If your package needs to define global variables, you should start with an underscore followed by the name of the package and another underscore. For example, PEAR
The package uses a global variable named $_pear_destructor_object_list.
Pre-defined values True, FALSE, and NULL
PHP's built-in values of true, FALSE, and Null must all be written in lowercase letters.
