PHP coding specifications

This is a previous article, and I feel very good at sorting it out again. We hope to make everyone better. 1. Introduction 1. importance of standardization ** the standardization problem has a headache for everyone in some aspects, making everyone feel in the same situation. This helps to make these recommendations evolve in many projects, and many companies spend weeks by word "> <LINKhref =" http://www.php100.c

This is a previous article, and I feel very good at sorting it out again. We hope to make everyone better.

1. Introduction

1.1. importance of standardization **

In some aspects, standardization makes everyone feel at the same position. This helps to make these suggestions evolve in many projects, and many companies have spent a lot of weeks arguing by word. Standardization is not a special personal style. it is completely open to local improvements.

 

1.2. Advantages

When a project tries to comply with public standards, it has the following benefits:

· Programmers can understand any code and find out the program status

· Newcomers can quickly adapt to the environment

· Prevent new php contacts from creating a new style and forming a lifelong habit out of time-saving needs

· Prevent new php contacts from making the same mistake again and again

· In a consistent environment, people can reduce their chances of making mistakes.

· Programmers have the same enemy

1.3. Disadvantages

· Standards are determined by people who do not know php, so they usually look silly.

· Because standards are different from what I do, they usually look silly.

· Standards reduce creativity

· Standards are not necessary for long-term mutual cooperation

· The standard forces too many formats

1.4. discussion

The experiences of many projects draw the conclusion that adopting programming standards can make the project more smooth. Is standard the key to success? Of course not. But they can help us, and we need all the help we can get! To be honest, most of the arguments about a standard of detail come from self-confidence. If a reasonable standard is rarely determined to be regarded as a lack of technology **, it is only the reason for taste. Therefore, you must be flexible in controlling your own ideas. remember that any project depends on the efforts of the team.

1.5. Explanation

1.5.1. standard implementation

First, you should find all the most important elements within the development team. maybe the standards are not appropriate for your situation. It may have summarized important issues, and some may have expressed strong opposition to some of them. No matter under what circumstances, as long as the final event goes smoothly, people will understand that this standard is reasonable, and other programmers will find it reasonable **, and I think it is worthwhile to follow this standard with some reservation. If there is no voluntary cooperation, you can set the requirements: standards must be tested by code. If it is not tested, this solution is just a group of ridiculous people built on an inaccurate Foundation.

1.5.2. agree with the opinion

1. This does not work;

2. it may be feasible, but it is neither practical nor boring;

3. this is true, and I have told you;

4. this is what I first thought;

5. This should have been the case.

If you look at things with negative ideas, please keep your mind open. You can still make a nonsense conclusion, but the method of making a conclusion is that you must be able to accept different ideas. Please give yourself some time to do it.

1.5.3. four phases of the project

1. database structure

2. design

3. Data Layer

4. HTML layer

 

2. naming rules

 

2.1. proper name

 

Naming is the core of program planning. The ancients believed that as long as they knew the real name of a person, they would gain incredible power over that person. As long as you give things a correct name, it will give you and people later more powerful than the code. Don't laugh!

The name is a long-term and profound result of a thing in its ecological environment. In general, only programmers who know the system can obtain the most appropriate name for the system. If all the names are suitable for their nature, the relationship is clear, and the meaning can be deduced. the assumption of the average person can also be expected.

If you find that only a few of your names can match their corresponding items, you 'd better look at your design again.

 

2.2. class name

 

· Before naming a class, you must first know what it is. If you still cannot remember what the class is, your design is not good enough.

· A hybrid name composed of more than three words is easy to cause confusion between various entities of the system. let's look at your design and try to use (CRC Session card) check whether the object corresponding to the name has so many functions.

· Naming a derived class should avoid the temptation to include its parent class name. The name of a class is only related to itself, and has nothing to do with its parent class name.

· Sometimes suffix names are useful. for example, if your system uses an agent, you can name a part as a "DownloadAgent" for real information transfer.

 

2.3. method and function naming

 

· Every method and function usually execute an action. Therefore, their names should clearly indicate what they do: replace ErrorCheck () with CheckForErrors () and DumpDataToFile () replace DataFile (). In this way, functions and data can also be differentiated.

· Sometimes suffix names are useful:

O Max-indicates the maximum value that an object can assign.

O Cnt-the current value of a running count variable.

O Key-Key value.

For example, RetryMax indicates the maximum number of retries, and RetryCnt indicates the current number of retries.

· Sometimes prefix names are useful:

O Is-it means to ask a question about something. At any time, people will know that this Is a problem.

O Get-indicates obtaining a value.

O Set-meaning to Set a value

For example, IsHitRetryLimit.

 

2.4. do not use uppercase letters for all acronyms

 

· In any of the following situations, you can use the upper-case letters and the lower-case letters in the first letter to represent the acronym.

Use: GetHtmlStatistic.

Not used: GetHTMLStatistic.

Reason

· When the name contains acronyms, people seem to have a very different intuition. Unified rules are the best, so that the meaning of the name can be completely pre-known.

Here is an example of NetworkABCKey. it is very confusing to note whether C in ABC or C in key. Some people don't care about this, but others hate it. So you will see different rules in different codes, so that you do not know how to call them.

For example

Class FluidOz // do not write it as FluidOZ

Class GetHtmlStatistic // do not write it as GetHTMLStatistic

 

2.5. class name

 

· Use uppercase letters as the separation of words, and use lowercase letters for other letters

· Use uppercase letters for the first letter of the name

· Do not use underscores (_)

Reason

· According to many naming methods, most people think this is the best way.

For example

Class NameOneTwo

Class Name

 

2.6. class library name

 

· Namespace is becoming more and more widely used to avoid class name conflicts between different vendors and group class libraries.

· When namespace is not used yet, to avoid class name conflicts, the general practice is to add a unique prefix before the class name so that two characters can be used. of course, it is better to use more.

For example

John Johnson's data structure class library can use Jj as the prefix, as shown below:

Class JjLinkList

{

}

Another compromise is to create a directory containing the class library (in fact, Java does the same). different directories represent different namespaces.

For example

Microsoft database-related class libraries can be found:

/Classes/com/Microsoft/Database/DbConn. php

Apache database-related class libraries can be found in:

/Classes/org/apache/Database/DbConn. php

 

2.7. method naming

 

· Adopt rules consistent with the class naming rules

Reason

· Most people who use all different rules find this the best compromise.

For example

Class NameOneTwo

{

Function DoIt (){};

Function HandleError (){};

}

 

2.8. Category ** name

 

· The name of the genus ** should be prefixed with the character'm.

· The prefix 'M' is followed by the same class naming rules.

· 'M' always acts as a modifier at the beginning of a name, just as if it was referenced at the beginning of 'R.

Reason

· The prefix m prevents any conflict between the class owner ** and the method name. Your method name and owner ** are often very similar, especially the access element.

For example

Class NameOneTwo

{

Function VarAbc (){};

Function ErrorNumber (){};

Var $ mVarAbc;

Var $ mErrorNumber;

Var $ mrName;

}

 

 

2.9. name parameters in the method

 

· The first character must contain lowercase letters.

· All words after the first character are capitalized according to the class naming rules.

Reason

· Differentiate General variables in a method.

· You can use a name that is similar to a class name without duplicate name conflicts.

For example

Class NameOneTwo

{

Function StartYourEngines (

& $ RSomeEngine,

& $ RAnotherEngine );

}

 

2.10. variable naming

 

· All letters must be in lower case.

· Use _ as the boundary of each word.

Reason

· In this way, the scope of variables in the code is clear.

· All variables look different in the code and are easy to identify.

For example

Function HandleError ($ errorNumber)

{

$ Error = OsErr ($ errorNumber );

$ Time_of_error = OsErr-> GetTimeOfError ();

$ Error_processor = OsErr-> GetErrorProcessor ();

}

 

2.11. reference variables and function return references

 

· The reference must be prefixed with 'R '.

Reason

· Makes variables of different types easy to recognize

· It can determine which method returns changeable objects and which method returns unchangeable objects.

For example

Class Test

{

Var mrStatus;

Function DoSomething (& $ rStatus ){};

Function & rStatus (){};

}

 

2.12. global variables

 

· Global variables should have the prefix 'G '.

Reason

· It is very important to know the scope of a variable.

For example

Global $ gLog;

Global & $ grLog;

 

2.13. define the name/global constant

 

· Global constants are separated.

Reason

This is the tradition of naming global constants. Do not conflict with other definitions.

For example

Define ("A_GLOBAL_CONSTANT", "Hello world! ");

 

2.14. static variables

 

· Static variables should have the prefix's '.

Reason

· It is very important to know the scope of a variable.

For example

Function test ()

{

Static $ msStatus = 0;

}

 

2.15. function name

 

· The function name adopts the c gnu convention. all letters use lowercase letters and use _ to separate words.

Reason

· This makes it easier to differentiate associated class names.

For example

Function some_bloody_function ()

{

}

 

2.16. Error return detection rules

 

· Check all system call errors unless you want to ignore them.

· Define the system error text for each system error message to include.

 

 

3. writing rules

 

 

3.1. braces {} rule

 

Two of the three main braces are acceptable, and the first is the best:

· Place braces in the same column below the keywords:

If ($ condition) while ($ condition)

{{

......

}}

· The Traditional brackets of UNIX are the same as the keywords. the ending brackets are the same as the keywords:

If ($ condition) {while ($ condition ){

......

}}

Reason

· Non-principled issues that have aroused heated debate can be solved through a compromise. either of the two methods is acceptable, but most people prefer the first one. The reason is the scope of psychological research.

There are more reasons to prefer the first one. If the character editor you are using supports the bracket matching function (for example, vi), the most important thing is to have a good style. Why? We say that when you have a large program and want to know where it ends. Move the brackets to the beginning, and press the button editor to find the ending brackets. for example:

If ($ very_long_condition & $ second_very_long_condition)

{

...

}

Else if (...)

{

...

}

To move from one block to another, you only need to use the cursor to match your brackets. no matching brackets are needed.

 

3.2. indent/Tab/space rules

 

· Use tab indentation.

· Use three to four spaces to indent each layer.

· No longer use the method of shrinking as long as there is a need. There is no fixed rule for the maximum number of indentation layers. if the number of indentation layers is greater than four or five layers, you can consider decomposing the code factor (factoring out code ).

Reason

· Many programmers support tabs.

· When people use tabs that are too different, it will make reading code very laborious.

· So many people are willing to limit the maximum number of indentation layers, which are generally never considered a job. We believe that programmers will choose the depth of nesting wisely.

For example

Function func ()

{

If (something bad)

{

If (another thing bad)

{

While (more input)

{

}

}

}

}

 

3.3. parentheses, keywords, and function rules

 

· Do not enclose parentheses and keywords together. separate them with spaces.

· Do not enclose parentheses with function names.

· Do not use parentheses in Return statements unless necessary.

Reason

· The keyword is not a function. If the parentheses closely match the function name and keyword, the two are easily regarded as one.

For example

If (condition)

{

}

 

While (condition)

{

}

 

Strcmp ($ s, $ s1 );

 

Return 1;

 

3.4. do not do practical work in object architecture functions

 

Do not do the actual work in the object architecture constructor. The constructor should include the initialization of variables and (or) will not fail.

Reason

· The constructor cannot return an error.

For example

Class Device

{

Function Device () {/* initialize and other stuff */}

Function Open () {return FAIL ;}

};

 

$ Dev = new Device;

If (FAIL = $ dev-> Open () exit (1 );

 

3.5. If Then Else format