My php coding specifications

Why should we develop our own php coding specifications?

When we write code, a good coding specification can play a lot of undesirable effects for us. At least, it has the following benefits:
1. improve our coding efficiency. Uniform Code makes it easy for us to copy and paste it!
2. improve code readability.
3. show our major. When others see our code, they find that the entire code writing process is uniform, and the code is immediately pushed up!
4. facilitate team collaboration. Everyone uses the same specification, which eliminates the five-or eight-point writing mode and coordinates the same!

The code specification consists of two parts: code specification and Annotation specification.

In fact, the php script we wrote is actually composed of two major parts: writing code and commenting on the code! Different frameworks, or even different companies, may have different requirements for this. here we just make a summary of our writing specifications! Hope to inspire other friends

1. code writing specifications

Folder name:
The folder must contain lowercase letters. For example, to store the controller folder, name it controller.

File name:
If it is a class file, the names of the files should be the same and use the big hump. For example, Session. class. php, the corresponding class name is Session,
If it is a common tool script, it should be used in a uniform manner, such as common. php.

Class name:
Class names use the same big camper, Cookie class

Method name:
The function of this method is described in the form of verbs and rankings, such as sendMessage and SMS.
In object-oriented systems, the same rules are observed, but some rules are different:
Public getUserName ()
Protected _ getTotalAmount ()
Private _ setBlanceAmount ()

Variable naming rules:
We need to talk about the variables:
1. whether in object-oriented or non-object-oriented syntax, variables use a small hump, for example, $ workYears.
However, in object-oriented systems, public, protected, private, protected, or private attributes are different._As difference

public $startPosition = 1;protected $_salaryAmount =1000; private $_sex = 'formale';

2. if it is a constant, use uppercase letters and underscores in the middle to separate them.

define('CURRENT_SCRIPT', 'index.php');const TRANSACTION_TYPE = 'income';

3. use the big camper and prefix to add global variables._The first letter of all words is capitalized. Knowing the scope of a variable is very important, so local variables and global variables should be clearly separated!

$_System_Config;$_Root_Path;

Indent character
For the indentation of the encoding, we use the tab indentation! Some may ask why space indentation is not applicable?
The reason is very simple. most editors support the number of spaces equal to the number of tabs, and there is no need to adjust the space!

Operator Number
All two-element operator numbers should be preceded by spaces.
$ Name = 'zero ';
$ Age> 18? 'Adresult': 'Children ';

Common process statement planning
We agree that the curly braces of all flow statements occupy a single line. Reason: If you encounter complicated business logic, curly braces will be nested, so we will confuse the corresponding curly braces!
1. Branch statement

If ($ age >=18 & $ age <= 30) {echo 'Young man ';} else if ($ age> 30 & $ age <= 60) {echo 'midddle aged';} else {echo 'Old man ';} // the following code experts have a question: in the if statement, even if no curly braces are allowed, the curly braces should be written in if ($ age> 60) {echo 'I am very old ';}

switch($status){    case 'forbiden'：        echo 'login forbidden';        break;           case 'normal':        echo 'login in';        break;            default:        echo 'status is wrong' ：        break;}

2. loop statements

while($condition){    statesments......;}

foreach($arrayList as $arrayKey => $arrayItem){    states......;}

do{    statements......;    }while($condition)

for($start; condition; changenumber){    statements......;}

2. writing specifications of comments

Many people say that the code does not need to be commented out. In fact, I think this is a very bullshit sentence (or he may be right, unless the entire team is alone, he has done everything without looking at other people's code ).

My personal opinion is: Write more comments. it is very friendly to others in the team or yourself!

Based on personal experience, annotations have at least the following functions:
1. it is helpful to improve the readability of the code. after all, reading your comments is much easier than reading your code!
2. it is helpful to plan your own code layout! This is because it is related to the types of code annotations. "Conducive to the layout of Code", this kind of things seems a bit suspended, simply saying it is not clear, we need real examples for support!
3. because our annotation specifications comply with the requirements of phpdocumentor, this tool can also generate a general description of the code, which is equivalent to a user manual! G

Types of code comments
1. Block comment
Block annotations are mainly used in three places. Descriptions of php scripts, descriptions of a large functional module, and comments that cannot be written within a row should also be placed in block comments.

2. line comment
Line comment. I personally think it works with block comment! It is generally used to describe the details of a large functional module!

Case studies
I will not talk about the specific usage details of the phpjavasentor syntax here. I can't go over it again on the official website.

From the above example, we can see how the code layout is, but we still need to explore it in practice.