Use PEAR to write your PHP Program

As mentioned above, PEAR manages the PEAR application code library according to certain categories. Your PEAR code can be organized into appropriate directories, others can easily retrieve and share your results. PEAR is not only a code repository, but also a standard. Using this standard to write your PHP code will enhance the readability and reusability of your program and reduce the chance of errors. PEAR builds a framework for you by providing two classes to implement functions such as destructor and error capture. You can use these functions through inheritance.

PEAR encoding rules include indentation rules, control structures, function calls, function definitions, comments, including code, PHP tags, file header comments, CVS tags, and URL samples, constant naming. The following is a brief introduction:

Indent rules:
In PEAR, four spaces are required for code reduction, and TAB is not used. If you use VIM, put the following settings into your ~ /. In vimrc: set expandtab
Set shiftwidth = 4
Set tabstop = 4
If you use Emacs/XEmacs, set indent-tabs-mode to nil.

But you like to use (X) Emacs to edit PHP files like me, I strongly recommend you install PHP-MODE so that when you write PEAR code, it will automatically adjust your shrink style, of course PHP-MODE has many excellent features that you can download the latest PHP-MODE from the list of resources.

Control Structure:
The control structure mentioned here includes: if for while switch. For control structures, in keywords (such as if ..) leave a space box and then use parentheses to avoid confusion with function calls. In addition, you should try to use curly braces {} as far as possible {}, even if the syntax is optional. In this way, you can avoid logical doubts or errors when adding new code lines. Here is an example: if (condition 1) & (condition 2 )){
Statement 1;
} Esleif (Condition 3) | (Condition 4 )){
Statement 2;
} Else {
Statement 3;
}

Function call:
For function calling, the function name and left parenthesis (there should be no space between them. For function parameters, there must be the same space separation between the separated comma and the next parameter, there must be no space between the last parameter and the right brace. The following is a standard function call; $ result = foo ($ param1, $ param2, $ param3 );
Non-standard writing:
$ Result = foo ($ param1, $ param2, $ param3 );
$ Result = foo ($ param1, $ param2, $ param3 );

In addition, if you want to assign values to the results returned by the function, there must be spaces between the equal sign and the assigned variable. In addition, if you are using a series of related values, you should add appropriate spaces, align them like this: $ result1 = $ foo ($ param1, $ param2, $ param3 );
$ Var2 = $ foo ($ param3 );
$ Var3 = $ foo ($ param4, $ param5 );

Function Definition:
Function definition follows the "one true brace" Convention: function connect (& $ dsn, $ persistent = false ){
If (is_array ($ dsn )){
$ Dsninfo = & dsn;
} Else {
$ Dsninfo = DB: parseDSN ($ dsn );
}
If (! $ Dsninfo |! $ Dsninfo [phptype]) {
Return $ this-> raiseError ();
}
Return true;
}
As shown above, optional parameters must be at the end of the parameter table and always return meaningful function values whenever possible.

Notes:
Online documents of classes should be converted to PHPDoc, just like JavaDoc. PHPDoc is also an application of PEAR, more detailed introduction you can go to http://www.phpdoc.de/view. In addition to the online documentation of classes, we recommend that you use non-document comments to interpret your code. When you see a piece of code, consider: Oh, I don't need to describe it carefully in the document. So you 'd better make a simple comment on the code to prevent you from forgetting how it works. For the form of annotation, C's/**/and C ++'s // are both good. However, do not use Perl or shell's # annotation method.

Code included:
Whenever you need to include a class file unconditionally, you must use requre_once; when you need to include a class file, you must use include_once; this ensures that the files you want to include will only be contained once, and the two statements share the same file list, so you do not have to worry about confusion between the two statements. Once require_once contains a file, include_once will no longer contain the same file, and vice versa.

PHP code Tag:
Define Your php code at any time, instead of simply using it. This ensures PEAR compatibility and facilitates cross-platform porting.

Annotation Declaration of the file header:
All PHP code files that need to be included in the PEAR Core Release. At the beginning of the file, you must add the following comments:/* vim: set expandtab tabstop = 4 shiftwidth = 4: */
// + ------------------------------------------------------------------------ +
// | PHP version 4.0 |
// + ------------------------------------------------------------------------ +
// | Copyright (c) 1997,199 8, 1999,200 0, 2001 The PHP Group |
// + ------------------------------------------------------------------------ +
// | This source file is subject to version 2.0 of the PHP license, |
// | That is bundled with this package in the file LICENSE, and is |
// | Available at through the world-wide-web at |
// | Http://www.php.net/license/2_02.txt. |
// | If you did not receive a copy of the PHP license and are 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 $
For Files Not In the PEAR core code library, we recommend that you have such a comment block at the beginning of the file to indicate copyright, protocol, author, and so on. At the same time, we also add the vim modeline In the first line, so that we can maintain the PEAR code style in VIM.

CVS flag:
As shown above, add the cvs id tag to each file. If this tag is not found in the edited or modified file, add it, or replace similar representations in the original file (such as "Last modified)

URL sample:
You can refer to RFC 2606 and use "www.example.com" as all URL samples.

Constant Name:
Constants should be capitalized as much as possible. To facilitate understanding, use underscores to separate each word. At the same time, you should use the package name or class name where the constant is located as the prefix. For example, constants in the Bug class should start with Bug. The above are PEAR encoding rules. For detailed Encoding Rules, refer to the description of CODING_STANDDARD file in PEAR. To better understand these encoding rules, you can also refer to the code of the existing PEAR core module.

Start using PEAR

 

It's easy to use PEAR. You just need to define your own PEAR program: require_once "PEAR. php ";
Class your_class_name extends PEAR {
Your class definition...
}

Of course, you need to follow the PEAR encoding rules mentioned above, and then you can implement what you want to do inside your class. Next, let's discuss it. In fact, PEAR provides us with two pre-defined classes: PEAR: This is the base class of PEAR. All PEAR extensions must be derived from it. PEAR_Error: base class for processing PEAR errors. You can choose to derive your own error processing class.

Generally, you should not directly create a PEAR instance, but instead derive a new class and then create an instance of the new class. As a base class, PEAR provides us with some useful functions, mainly including destructor and error handling.

Destructor
PHP supports constructor, but does not support destructor. However, PHP provides the register_shutdown_function () function, which can call back the registered function before the script ends. Therefore, PEAR uses this feature, simulation of destructor is provided. If you have a PEAR subclass called mypear, you can define