File Structure
|
|――images
|――include
|――parameter
|――config
|――function
|――index
Images store picture files, include in the system is to refer to the file, generally in the parameter storage parameters file, config file in the configuration, function in the storage method files, such as JavaScript methods, and according to the functional modules of the classification, Put the various functional classes into it
file name
Folder naming is generally in English, not more than 20 characters in length, named in lowercase letters. In addition to special circumstances, the use of Chinese pinyin, some common folder names such as: images (storage graphics file), Flash (store flash files), style (storage css file), scripts (storage JavaScript script), Inc. ( Store include files, link (store links), media (storage multimedia files), etc. File names are combined in lowercase letters, numbers, and underscores.
Block Comment
Block annotations are typically used to provide descriptions of files, methods, data structures, and algorithms. Block annotations are placed at the beginning of each file and before each method. They can also be used elsewhere, such as within the method. Block annotations within features and methods should have the same indentation format as the code they describe.
There should be a blank line at the top of the block annotation to separate the block annotation from the code, such as:
/*
* This is a block note
*/
A block annotation can begin with a/*-so that indent (1) can recognize it as the beginning of a block of code and not rearrange it.
/*-
* If you want to be ignored, use a special format block annotation
*
* One
* Two
* Three
*/
Note: If you do not use indent (1), you do not have to use/*-in your code, or make concessions for other people who may be running indent (1) on your code.
Single-line Comment
Short notes can be displayed on one line and have the same indentation level as the following code. If a comment cannot be written in one line, the block annotation should be used. There should be a blank line before a single-line comment. The following is an example of a single-line comment in a code:
if (condition) {
/* The following code operating conditions * *
...
}
End-end Comment
Very short annotations can be on the same line as the code they are describing, but there should be enough white space to separate the code and the comment. If you have multiple short annotations appearing in large code, they should have the same indentation.
The following is an example of a tail-end annotation in a code:
if ($a = = 2) {
return TRUE; /* Description of single condition * *
} else {
return IsPrime ($a); * * The rest of the conditions * *
}
End of line Comment
Annotation qualifier "//", you can comment out the whole line or a part of a line. It is generally not used for consecutive lines of comment text, however, it can be used to comment out a number of consecutive lines of code snippets. Here are a few examples of all three styles:
if ($foo > 1) {
The second usage.
...
}
else {
return false; Explain why the return value
}
if ($bar > 1) {
//
The third way to use
...
//}
else {
return false;
//}
Document comments
Document annotations Describe the classes, constructors, methods, and fields (field) of PHP. Each document comment is placed in the annotation delimiter/**...*/, and one annotation corresponds to a class or member. The comment should precede the declaration:
/**
* Description of some of this class ...
*/
Class Example {...
Note that the top-level (top-level) class is not indented and its members are indented. The first line of the document annotation that describes the class (/**) does not need to be indented, and subsequent document comments are indented to 1 cells per line (align the asterisk vertically). Members, including constructors, indent the first line of the document annotation by 4, followed by a indentation of 5 cells per line.
If you want to give information about a class, variable, or method that is not suitable for writing in a document, you can use the implementation block annotation (see 5.1.1) or a single-line comment immediately following the declaration (see 5.1.2). For example, details about a class implementation should be placed in the implementation block comment immediately following the class declaration, rather than in the document comment.
Document comments cannot be placed in the definition block of a method or constructor because the program will associate the first declaration that is located after the document comment.