About PHP Development Coding Specification _php Tutorial

This is a previous article that feels good to reorganize and send out. I hope we can get something out of you.

1. Introduction

1.1. Importance of Standardization * *

The problem of standardization in some ways gives everyone a headache and makes everyone feel that they are in the same position. This helps to keep these recommendations evolving across many projects, and many companies spend weeks arguing by word-by-phrase. Standardization is not a special personal style, it is completely open to local improvement.

1.2. Advantages

When a project tries to comply with common standards, there are the following benefits:

· Programmers can learn any code to understand the state of the program

· New people can quickly adapt to the environment

· Prevent new access to PHP from the time-saving needs, create a set of style and develop lifelong habits

· Prevent new people from contacting PHP making the same mistakes again and again

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

· The programmers have a consistent enemy.

1.3. Disadvantages

· Because standards are made by people who don't know PHP, standards usually look silly.

· Because the standard is not the same as I do, so the standard usually looks stupid.

· Standards Reduce creativity

· Standards are not necessary for long-term co-operation among people

· The standard forces too many formats

1.4. Discussion

The experience of many projects has led to the conclusion that the adoption of programming standards can make the project more smoothly accomplished. Is the 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, much of the controversy over a standard of detail stems mainly from conceited thinking. Few decisions about a reasonable standard can be said to be a lack of technology, which is just the reason for the taste. So, be flexible and take control of your ego, and remember that any project depends on team work.

1.5. Explanation

1.5.1. Standard implementation

You should first identify all the most important elements within the development team, perhaps the criteria are not appropriate for your situation. It may have summed up important issues, and there may be some strong objections to some of those issues. No matter under what circumstances, as long as the final success, people will mature understand that the standard is reasonable, and then other procedures will find its reasonable * *, and feel that with some reservations to follow this standard is worthwhile. If there is no voluntary cooperation, the requirements can be established: standards must be tested by the code. Without testing, the solution is just a bunch of ridiculous people based on an imprecise base.

1.5.2. Identity view

1. This is not feasible;

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

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

4. This is what I thought first;

5. That should have been the case.

If you look at things with negative stereotypes, keep your mind open. You can still make it a nonsense conclusion, but the way to make a conclusion is that you have to be able to accept different ideas. Please give yourself a little time to do it.

1.5.3. Four stages of a project

1. Database structure

2. Design

3. Data layer

4. HTML Layer

2. Naming rules

2.1. Proper naming

Naming is the core of program planning. The ancients believed that knowing a person's real name would gain an incredible power over that person. As long as you think of the right name for something, it will give you and later people a stronger power than the code. Don't laugh!

A name is a long and far-reaching result of things in the ecological environment in which they are located. In general, only the programmer who understands the system can get the most appropriate name for the system. If all the names are compatible with their nature, then the relationship is clear, meaning can be deduced, and the general presumption can be expected.

If you find that only a small amount of your name can match its counterpart, it's best to take a good look at your design again.

2.2. Class naming

· Before you name a class, you must first know what it is. If you still can't figure out what this class is, then you're not doing a good job with the kind of clues that the class name provides.

· A mix of more than three words is prone to confusion among entities of the system, and then look at your design and try to use the CRC Session card to see if the named entity has so many functions.

· The name of the derived class should avoid the temptation to take its parent class name, which is related only to itself and not to what its parent class is called.

· Sometimes the suffix is useful, for example: If your system uses a proxy (agent), then a part is named "Download Agent" (downloadagent) to actually transmit the information.

2.3. Methods and function naming

· Usually each method and function performs an action, so naming them should clearly explain what they do: Replace Errorcheck () with Checkforerrors () and Dumpdatatofile () instead of datafile (). Doing so can also make the function and data a more distinguishable object.

· Sometimes the suffix name is useful:

o max-meaning the maximum value that an entity can give.

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 retry attempts.

· Sometimes the prefix name is useful:

O is-meaning to ask a question about something. Whenever people see is, they know it's a problem.

o get-meaning to get a value.

o set-meaning to set a value

For example: Ishitretrylimit.

2.4. Do not use uppercase letters in all abbreviations

· In any case, you can use the first letter to capitalize the remaining lowercase letters to represent abbreviations in lieu of all uppercase letters.

Use: Gethtmlstatistic.

Not used: gethtmlstatistic.

Reason

· When names contain acronyms, people seem to have very different instincts. Uniform rules are the best, so that the meaning of naming can be fully predictable.

As an example of networkabckey, note that C is the C in the ABC or in the key, which is very confusing. Some people don't care about this, others hate it. So you'll see different rules in different code, so you don't know how 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 a separation of words, and all other letters in lowercase

· The first letter of the first name uses uppercase

· 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 naming

· Currently, namespaces are being used more and more extensively to avoid conflicting class names between different vendors and groups of libraries.

· When namespaces are not yet in place, in order to avoid class name collisions, it is common practice to prefix the class name with a unique, two-character, and certainly a better one.

For example

John Johnson's data structure class library can be prefixed with JJ, as follows:

Class Jjlinklist

{

}

Another way to compromise is to create a directory that contains the class library (which is actually what Java does), to represent different namespaces in a directory that doesn't work.

For example

Microsoft's database-related class libraries can be used in:

/classes/com/microsoft/database/dbconn.php

Apache database-related class libraries are available at:

/classes/org/apache/database/dbconn.php

2.7. Method naming

· Adopt rules that are consistent with class naming

Reason

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

For example

Class Nameonetwo

{

function DoIt () {};

function HandleError () {};

}

2.8. Generic * * naming

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

· The prefix ' m ' is followed by a rule with a consistent class naming.

· ' m ' always modifies at the beginning of the name, as if it were a reference to the beginning of ' R '.

Reason

· The prefix m prevents any conflicts between generic * and method names. Your method name and genus name are often very similar, especially for accessing elements.

For example

Class Nameonetwo

{

function Varabc () {};

function ErrorNumber () {};

var $mVarAbc;

var $mErrorNumber;

var $mrName;

}

2.9. Parameter naming in methods

· The first character uses a lowercase letter.

· All words after the first character are capitalized by the first character of the class naming convention.

Reason

· You can distinguish between generic variables in a method.

· You can use a name that is similar to the class name to avoid conflicting names.

For example

Class Nameonetwo

{

Fu

http://www.bkjia.com/PHPjc/486012.html www.bkjia.com true http://www.bkjia.com/PHPjc/486012.html techarticle This is a previous article that feels good to reorganize and send out. I hope we can get something out of you. 1. Introduction 1.1. Standardization of IMPORTANT * * standardization issues in some ways let each ...

