PEAR Standards
Perhaps the most important part of the PEAR project is finally defining an
official standard for creating reusable, well documented php packages. A
standard set of guidelines are necessary to make sure all PEAR packages are
available to as many developers as possible. Since PEAR is still in
development, the current set of rules and guidelines are subject to
discussion and change. If you take issue with any of these guidelines, or have
a better solution, you should let the developers know by posting to the
PHP-PEAR mailing list.
official standard for creating reusable, well documented php packages. A
standard set of guidelines are necessary to make sure all PEAR packages are
available to as many developers as possible. Since PEAR is still in
development, the current set of rules and guidelines are subject to
discussion and change. If you take issue with any of these guidelines, or have
a better solution, you should let the developers know by posting to the
PHP-PEAR mailing list.
Naming Guidelines
The extension .php must be used for all files containing php code. A related
set of one or more classes and functions are called a “package”. These
packages are organized into the PEAR package structure. The package structure maps
1:1 to the file system, but is based on the argument provided to the “use” or
“import” functions.
set of one or more classes and functions are called a “package”. These
packages are organized into the PEAR package structure. The package structure maps
1:1 to the file system, but is based on the argument provided to the “use” or
“import” functions.
- DB
- DB/common
- DB/mysql
- HTML
- HTML/Form
Because PHP does not implement name-spaces, class names must be
based on the package they are implemented in. The class name is derived by
simply replacing the slashes in the package name with under scores. Thus, the
package “DB/common” has it’s code in the file “DB/common.php”, and defines a
class called “DB_common”. This strategy should prevent any naming
collisions despite the lack of separate name-spaces.
based on the package they are implemented in. The class name is derived by
simply replacing the slashes in the package name with under scores. Thus, the
package “DB/common” has it’s code in the file “DB/common.php”, and defines a
class called “DB_common”. This strategy should prevent any naming
collisions despite the lack of separate name-spaces.
Functions should be named with underscores separating lowercase words, for
example
example
my_function
. Methods should use initial lowercase studly caps, likemyMethod
.