About PHP development coding standards_PHP tutorial-PHP Tutorial-php.cn

This is a previous article, I feel it is good to reorganize it and publish it again. I hope everyone can gain something.

1. Introduction

1.1. The importance of standardization**

Standardization issues give everyone a headache in some ways, making everyone feel that everyone is in the same situation. This helped the recommendations evolve over many projects, with many companies spending many weeks arguing word for word. Standardization is not a particular personal style; it is completely open to local modification.

1.2. Advantages

When a project attempts to adhere to a public standard, it will have the following benefits:

· Programmers can understand any code and understand the status of the program

· Newcomers can adapt to the environment quickly

· Prevent people who are new to PHP from creating their own style and forming lifelong habits out of the need to save time

· Prevent newbies from making the same mistakes again and again

· In a consistent environment, people can reduce the chance of making mistakes

· Programmers have a common enemy

1.3. Disadvantages

· Because standards are set by people who don’t know PHP, standards often look silly

· Standards usually look silly because they are different from what I do

· Standards reduce creativity

· Standards are not necessary among people who cooperate with each other for a long time

· Standards force too many formats

1.4. Discussion

The experience of many projects can lead to the conclusion that adopting programming standards can make the project complete more smoothly. Are standards 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 arguments over a detail standard stem primarily from egotism. The few decisions on a reasonable standard that can be said to lack technical integrity are simply a matter of taste. So be flexible and keep your ego in check, and remember that any project depends on a team effort.

1.5. Explanation

1.5.1. Standard implementation

The first step is to identify all the most important elements within the development team. Maybe the standards are not appropriate enough for your situation. It may have summarized important issues, and there may have been strong objections to some of them. In any case, if things go well in the end, people will mature enough to realize that the standard is reasonable, and then other programmers will find it reasonable and feel comfortable following it with some reservations. Worth it. If there is no voluntary cooperation, requirements can be formulated: standards must be tested with code. Without examination, this solution is just a bunch of laughable stuff based on imprecision.

1.5.2. Agree with the point of view

1. This won’t work;

2. Maybe it works, but it’s impractical and boring;

3. This is true, and I told you too;

4. This is what I thought of first;

5. This is how it should be.

If you come to look at things with negative prejudices, please keep an open mind. You can still conclude that it's bullshit, but the way to do that is that you have to be open to 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. Appropriate naming

Naming is the core of program planning. The ancients believed that knowing a person's true name would grant them incredible power over that person. As long as you think of the right names for things, it will give you and those who come after you more power than code. Don't laugh!

The name is a long-term and far-reaching result of something in the ecological environment in which it is located. In general, only programmers who understand the system can come up with the most appropriate name for the system. If all names are naturally appropriate, the relationship is clear, the meaning can be deduced, and ordinary people's inferences can be expected.

If you find that only a few of your names match their corresponding objects, it’s best to take a good look at your design again.

2.2. Class Naming

· Before naming a class, you must first know what it is. If you still can't remember what the class is based on the clues provided by the class name, then your design is not good enough.

· Mixed names consisting of more than three words can easily cause confusion between various entities in the system. Take a look at your design and try to use (CRC Session card) to see if the entity corresponding to the name has so many functions. .

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

· Sometimes suffixes are useful. For example: if your system uses an agent, then name a component "DownloadAgent" to actually transmit information.

2.3. Method and function naming

· Usually each method and function performs an action, so their naming should clearly indicate what they do: use CheckForErrors() instead of ErrorCheck(), use DumpDataToFile() instead of DataFile(). Doing so also makes functions and data more distinguishable objects.

· Sometimes the suffix is useful:

o Max - means the maximum value that can be assigned to an entity.

o Cnt - The current value of a running count variable.

o Key - Key value.

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

· Sometimes a prefix is useful:

o Is - means to ask a question about something. Whenever people see Is they know it's a problem.

o Get - means to get a value.

o Set - means setting a value

Example: IsHitRetryLimit.

2.4. Do not use all capital letters for abbreviations

· In any case, when encountering the following situations, you can use the first letter to capitalize the remaining letters instead of using all capital letters to represent an abbreviation.

Use: GetHtmlStatistic.

Do not use: GetHTMLStatistic.

Reasons

· People seem to have very different intuitions when names contain abbreviations. It is best to have unified regulations, so that the meaning of the naming is completely predictable.

Take the example of NetworkABCKey. Note whether C should be the C in ABC or the C in key. This is very confusing. Some people don't care, others hate it. So you will see different rules in different codes, so you don't know what to call it.

For example

class FluidOz // Do not write FluidOZ

class GetHtmlStatistic // Do not write GetHTMLStatistic

2.5. Class Naming

·Use uppercase letters as word separators and all other letters in lowercase

· Capitalize the first letter of your name

· Do not use underscore (_)

Reasons

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

For example

class NameOneTwo

class Name

2.6. Class library naming

· Namespaces are currently being used more and more widely to avoid class name conflicts between class libraries from different vendors and groups.

· When namespaces have not yet been adopted, in order to avoid class name conflicts, the general approach is to add a unique prefix before the class name. Two characters is enough. Of course, it would be better to use more.

For example

John Johnson’s data structure class library can be prefixed with Jj, as follows:

class JjLinkList

{

}

Another compromise is to create a directory containing class libraries (in fact, Java does this as well), and use different directories to represent different namespaces.

For example

Microsoft’s database related class library can be found at:

/classes/com/Microsoft/ Database/DbConn.php

Apache’s database related class library can be found at:

/classes/org/apache/Database/DbConn.php

2.7. Method Naming

· Adopt the same rules as class naming

Reasons

· Most people using all the different rules find this to be the best compromise.

For example

class NameOneTwo

{

function DoIt() {};

function HandleError() {};

}

2.8. Generic** Naming

· Attribute names should be prefixed with the character ‘m’.

· The prefix ‘m’ follows the consistent rules for class naming.

· ‘m’ always modifies the beginning of a name, just like ‘r’ indicates a reference.

Reasons

· The m prefix prevents any conflict between class** and method names. Your method names and property names will often be very similar, especially when accessing elements.

For example

class NameOneTwo

{

function VarAbc() {};

function ErrorNumber() {};

var $mVarAbc;

var $mErrorNumber;

var $mrName;

}

2.9. Naming parameters in methods

· Use lowercase letters for the first character.

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