Home >Backend Development >PHP Tutorial >PHP Coding Standard PHP Coding Standard_PHP Tutorial
PHP Coding Standard PHP Coding Standard_PHP Tutorial
- WBOYOriginal
- 2016-07-21 14:57:57884browse
General principles:
1. Semantic
When you see the name, you know the meaning.
2. The common prefix
is means whether, get means reading, and set means writing. is is followed first by adjectives rather than nouns. For example, if the text is multilingual, is_multilingual should be used instead of is_multilanguage.
3. Singular and plural
Refer to the function naming rules of js: getElementById, getElementsByTagName, getElementsByName.
For example:
To get the names of my multiple friends, you should use getFriendsName instead of getFriendNames or getFriendName
To get a user, getUser
To get multiple users, getUsers
4. Redundant suffixes
Try not to use data, list, and info suffixes.
For example, pay attention to the naming of js, use getElementsByTagName instead of getElementsInfoByTagName.
You should use getFriends or getFriendsUserId instead of getFriendsList; you should use getUser instead of getUserInfo or getUserData.
But sometimes it’s hard to avoid it. For example, there are two functions, one is to get the user’s basic information, and the other is to get the user’s detailed information.
Get basic user information: nickname, avatar URI, function name getUserBasic or getUserBasicInfo? It feels inappropriate for the function name to end with an adjective, to be discussed.
Get user details: nickname, avatar URI, signature, birthday, function name getUser is no problem.
5. Ambiguous class names, file names, and directory names
Be careful whenever you use common, util, functions, class, object, and basic as file names, because these words are too common and difficult to develop. As you go down, there may be more and more stuff inside, turning it into a trash can. Give these an accurate name. For example, a class that does string processing can be called StringLib.php and placed in the lib directory.
6. The difference between lib, plugin and addon
Some classes and functions are counted as lib, plugin or addon. To be discussed.
Class name:
Start with a capital letter and use camel case. Generally use nouns, such as configuration parsing class ConfigParser instead of ParseConfig.
Same as Java and C++.
For example: class UserModel
The file name of the class:
is the same as the class name. This is related to php autoload. For autoload, the class name must always be very long, to be discussed.
Consistent with Java.
For example: the file name of class UserModel is UserModel.php
Non-class file name:
All lowercase, separated by underscores, no spaces allowed. For example get_user.php.
Directory name:
All lowercase, separated by underscores, no spaces allowed. Such as model, www.
Function name:
Start with a lowercase letter and be named in camel case, for example: function addBlog().
Same as Java and C++.
Function represents a function, that is, an action, so the verb takes precedence. For example, use editBlog instead of blogEdit.
Due to historical reasons, PHP built-in functions have many styles, such as do_something, something_do, dosomething. The newer functions use doSomething to be consistent with the current mainstream languages.
For example: paser_str, json_encode, substr, fetchAll.
Historical reasons may not be changed, but we can ensure that the new code is rigorous and do not let ourselves become historical reasons.
Function in class:
There is a blank line between the two functions. If you have time, sort the functions alphabetically to avoid too much confusion.
For example:
class BlogModel
{
public function addBlog()
{
}
public function updateBlog()
{
}
}
File comments: The
comment immediately follows the next line of The format follows the requirements of PHPdoc: http://manual.phpdoc.org/HTMLframesConverter/default/phpDocumentor/tutorial_tags.author.pkg.html
/**
* Various businesses of blog: adding, updating
* @author sink
*
*/
class BlogModel
{
}
?>
API note:
Be sure to write the input parameters and output format. Write clearly what is output when it is correct and what is output when it is wrong.
Otherwise, others cannot use it.
Function comments:
Be sure to write the output format. Write clearly what is output when it is correct and what is output when it is wrong.
If the input parameters are complex and contain arrays, and the parameters cannot be clearly understood at a glance, you must write comments on the input parameters.
There can be no blank lines between documentation comments and functions.
If the internal steps of the function are complex, you need to write "inline comments".
For example:
/**
* Update blog
* @param int $id blog_id
* @param array $data array(
"content" => "", //Content
"tags" => ; "", //Tag
"update_time" => "", //Update time
)
* @return bool
*/
public function updateBlog($id,$data)
{
step1 //The first step: asdf
step2 // Step 2: qwer
}
URI:
According to the rfc1034 international standard, underscores "_" are prohibited in domain names, and domain names are not case-sensitive.
For example, http://dl_dir.qq.com/ is an incorrect domain name.
http://bkjia.com is the same as http://VERYHUO.COM.
Therefore, it is preferred to use all lowercase letters in the URI, and the name of GET is lowercase, except for the value of GET.
For example
http://www.google.com/?hl=zh-CN
http://www.google.com/?hl=zh-cn
Non-parameters in URI Whether to use lower case for the abbreviation of proper nouns is controversial and inconclusive.
For example
http://fedoraproject.org/zh_CN/
http://zh.wikipedia.org/zh-cn/
http://code.google.com/intl/zh -CN/
http://www.microsoft.com/en-us/
The language code is a proper noun. ISO stipulates that it must be a minus sign, and it is recommended to use capital letters for regions.
The usage of fedora is very strange. It uses its own zh_CN instead of zh-CN. And it is not recommended to use underscores in URIs.
Wiki uses lowercase letters, Google uses uppercase letters, and Microsoft uses lowercase letters.
Prefer to use the minus sign "-" in the URI instead of underscores, except for the name of GET.
For example
http://example.com/1-2-2
http://example.com/?user_id=123
If you want the user to enter the URI manually, don’t be case sensitive , and lowercase is preferred because it is more convenient for users to input.
The actual situation is: users generally manually enter the domain name instead of the URI because the URI is very long. In this case, does it make sense to lowercase the URI? If you use http://example.com/?userId=123, the variable name can use camel case $userId = $_GET['userId'], which can be compared with Java, C++ To be consistent, the database should also be named in camelCase. To be discussed.
Variables:
All lowercase, separated by underscores, for example: $user_id.
Inconsistent with Java and C++. To be discussed.
The member variables of a class, the formal parameters of a function, and the instantiation of a class into an object all abide by the naming rules of variables.
Reason: URI and database have lowercase convention. The parameters are obtained from $_GET and $_POST and stored in the database, so use lowercase.
PHP built-in variables $_GET and $_POST start with an underscore and are all capitalized. No matter how important a custom variable is, do not start it with an underscore to avoid conflicts with built-in variables in the future.
For example: don’t use $_PUT, $_DELETE.
Constant:
All uppercase, separated by underscores. For example: const MEMCACHE_TTL = 600;
PHP short tag:
Use , do not use the short tag . Because it conflicts with xml and is not conducive to deployment.
Braces-like line breaks:
Braces can be used to occupy a line alone, or braces can be placed on a line with others. This is controversial and inconclusive, and remains to be discussed.
class UserModel
{
}
Support line wrappers:
http://www.php.net/manual/zh/language.oop5.basic.php
http://pear.php.net/manual/en/standards.classdef.php
Excellent content, please click the next page!
- Total 2 pages:
- Previous page
- 1
- 2
- Next page