Develop your own php coding specifications

To improve work efficiency, ensure development effectiveness and rationality, and maximize the readability and reusability of program code, and improve communication efficiency, You need to edit a code specification.

To improve work efficiency, ensure development effectiveness and rationality, and maximize the readability and reusability of program code, and improve communication efficiency, You need to edit a code specification.

Why do we need to develop our own coding standards?

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.
But there are differences in object-oriented systems. When the public, protected, private, protected, or private attributes are used, _ is added as the 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 = 'Welcome ';

3. for global variables, use a big camper and prefix with _. 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 also be written into if ($ age> 60) {echo 'I am very old';} switch ($ status) {case 'forbiden ': echo 'login forbidden'; break; case 'normal': echo 'login '; 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.

The following are some php programming specifications for your reference.

I. File Tag:

1. All php files use complete php labels for code marking. Short labels are not recommended (short labels are easy to be confused with xml, and php does not support short tags by default from 5.4 ).

2. For php-only code files, we recommend that you omit '?> '. This is to prevent unnecessary spaces or other characters from affecting the code.

Ii. file and directory naming

1. the program file name and directory name are named in meaningful English. If you do not use Pinyin or meaningless letters, only letters, numbers, underscores, and hyphens are allowed '. the end of php' (except for template files). Multiple words use the hump naming method.

For example, DemoTest. class. php

// Use DemoTest. interface. php

// Other methods: demoTest. {style}. php

Iii. File directory structure

The standardized directory structure helps teams collaborate in development and post-maintenance.

-- App // Independent Application

-- Class // a single class file, a shared class file

-- Conf/inc // configuration file or directory

-- Data // data file or directory

-- Doc // program documentation

-- Htdocs // document_root

-- Images // path for storing all image files

-- Css // css File

-- Js // js File

-- Lib // shared class library

-- Template // template File

-- Tmp // temporary file directory

-- Cache // cache file

-- Session // SESSION file

-- Template_c // compiled Template File

-- Other

-- Upload // upload a file

-- Manage // manage the file directory in the background

Iv. Naming rules

1. variable name: variables in php are case-sensitive. A valid variable name starts with a number, letter, or underline, followed by any number of letters, numbers, and underscores.

A) the program name should start with lowercase letters and be meaningful. (Function displayName ())

B) PHP global variable key values have '_' on both sides and are named in the middle using the hump naming method. ($ _ GLOBAL ['_ beginTime _'])

C) Common variables use the hump naming method as a whole. We recommend that you add a prefix of the type before the variable. The uncertain type must start with an uppercase or lowercase character.

D) The function name should be meaningful and abbreviated as much as possible.

2. Class and interface naming:

A) It must start with an uppercase letter.

B) variable names composed of multiple words. There is no interval between words. Each word is capitalized.

C) the class name must be consistent with the class file name.

D) All the class names in the program are unique.

E) the Abstract class should start with Abstract.

Interface naming rules:

I) use the same naming rules as the class, but add the 'I' character before the naming to indicate the interface.

Ii) Try to keep the class name consistent with the class name that implements it.

3. Database naming: All Database naming Rules do not contain uppercase letters.

A) table names all Use lowercase letters.

B) The table name uses the same prefix and the prefix cannot be blank.

C) use '_' to separate table names composed of multiple words.

D) Table field naming rules.

I) Use lowercase letters.

Ii) Multiple words are separated by underscores.

Iii) Prefix A common field with the first letter of the table name.

Iv) Avoid using keywords and reserved words.

5. annotation specifications