Use PEAR to write your PHP program_PHP Tutorial-PHP Tutorial-php.cn

如前所述，PEAR按照一定的分类来管理PEAR应用代码库，你的PEAR代码可以组织到其中适当的目录中，其他的人可以方便地检索并分享到你的成果。 PEAR不仅仅是一个代码仓库，它同时也是一个标准，使用这个标准来书写你的PHP代码，将会增强你的程序的可读性，复用性，减少出错的几率。 PEAR通过提供2个类为你搭建了一个框架，实现了诸如析构函数，错误捕获功能，你通过继承就可以使用这些功能。

PEAR的编码规则包括缩进规则，控制结构，函数调用，函数定义，注释，包含代码，PHP标记，文件头的注释块，CVS标记，URL样例，常量的命名这11方面。下面简要地介绍一下：

缩进规则：
PEAR中需要使用4个空格来缩排代码，并且不使用TAB。如果你使用VIM，将下列设置放入你的~/.vimrc中：set expandtab
set shiftwidth=4
set tabstop=4
如果，你使用Emacs/XEmacs,需要把indent-tabs-mode 设置成nil。

不过你象我一样喜欢用(X)Emacs编辑PHP文件，我强烈推荐你安装PHP-MODE，这样当你编写PEAR代码的时候，它会自动调整你的缩排风格，当然PHP-MODE还有许多很优秀的特性，你可以从资源列表中的地方下载最新版的PHP-MODE。

控制结构：
这里所说的控制结构包括: if for while switch 等。对于控制结构，在关键字（如if for ..）后面要空一个格，然后再跟控制的圆括号，这样，不至于和函数调用混淆，此外，你应该尽量完整的使用花括号{}，即使从语法上来说是可选的。这样可以防止你以后需添加新的代码行时产生逻辑上的疑惑或者错误。这里是一个样例：if ((条件1) && (条件2)) {
    语句1；
}esleif ((条件3) || (条件4)) {
    语句2；
}else {
    语句3；
}

函数调用：
对于函数调用，函数名和左括号( 之间不应该有空格，对于函数参数，在分隔的逗号和下一个参数之间要有相同的空格分离，最后一个参数和右括号之间不能有空格。下面是一个标准的函数调用；$result = foo($param1, $param2, $param3);
不规范的写法：
$result=foo ($param1,$param2,$param3);
$result=foo( $param1,$param2, $param3 );

此外，如果要将函数的返回结果赋值，那么在等号和所赋值的变量之间要有空格，同时，如果是一系列相关的赋值语句，你添加适当的空格，使它们对齐，就象这样：$result1 = $foo($param1, $param2, $param3);
$var2 = $foo($param3);
$var3 = $foo($param4, $param5);

函数定义：
函数定义遵循"one true brace"习俗：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;
}
如上所示，可选参数要在参数表的末端，并且总是尽量返回有意义的函数值。

关于注释：
对于类的在线文档，应该能够被PHPDoc转换，就象JavaDoc那样。PHPDoc也是一个PEAR的应用程序，更详细的介绍你可以去 http://www.phpdoc.de/ 查看。除了类的在线文档，建议你应该使用非文档性质的注释来诠释你的代码，当你看到一段代码时想：哦，我想不需要在文档里去仔细描述它吧。那么你最好给这段代码作一个简单的注释，这样防止你会忘记它们是如何工作的。对于注释的形式，C的 /* */和C++的//都不错，不过，不要使用Perl或者shell的#注释方式。

包含代码：
无论什么时候，当你需要无条件包含进一个class文件，你必须使用requre_once;当你需要条件包含进一个class文件，你必须使用 include_once;这样可以保证你要包含的文件只会包含一次，并且这2个语句共用同一个文件列表，所以你无须担心二者会混淆，一旦 require_once 包含了一个文件，include_once不会再重复包含相同的文件，反之亦然。

PHP代码标记：
任何时候都要使用定义你的php代码，而不要简单地使用,这样可以保证PEAR的兼容性，也利于跨平台的移植。

Comment statement in the file header:
For all PHP code files that need to be included in the PEAR core release, you must add the following comment statement at the beginning of the file: /* vim: set expandtab tabstop=4 shiftwidth=4 : */
// +------------------------------------------------- --------------------------------+
// | PHP version 4.0 -------------------------------------------------- ----------------+
// | Copyright (c) 1997, 1998, 1999, 2000, 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 Your Name |
// +----------------------------------- ----------------------------------+
//
// $Id$
For files that are not in the PEAR core code base, it is recommended that you also have a similar comment block like this at the beginning of the file, indicating copyright, license, author, etc. At the same time, add VIM’s MODELINE in the first line, so that PEAR’s code style can be maintained in VIM.

CVS tag:

As shown above, add the CVS ID tag to each file. If the file you edit or modify does not have this tag, please add it, or replace it with something similar in the original file. Expression form (such as "Last modified", etc.)

URL samples:

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

Constant naming:

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

Get started with PEAR

Using PEAR is very simple, you only need to define your own PEAR program like this: require_once "PEAR.php";

class your_class_name extends PEAR{
Your class definition...
}

Of course, you need to abide by the PEAR coding 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 2 predefined classes: PEAR: This is the base class of PEAR, and all PEAR extensions must inherit and derive from it. PEAR_Error: PEAR's error handling base class, you can choose to derive your own error handling class.

Generally speaking, you should not create an instance of PEAR directly, but derive a new class yourself, and then create an instance of this new class. As a base class, PEAR provides us with some useful functions, the most important ones are destructor and error handling

Destructor

PHP supports constructors, but does not support destructors. However, PHP provides the register_shutdown_function() function, which can call back the registered function before the script terminates. Therefore, PEAR takes advantage of this feature to provide Destructor simulation. If you have a subclass of PEAR called mypear, then in the mypear class, you can define a