A comprehensive PHP coding Specification

A comprehensive php development code specification has been engaged in PHP and C-related development in Linux over the years, with many projects and teams. Below are the PHP coding specifications based on experience, it can be used as an example and reference for everyone and can be selected and modified as needed! (Some of the latest PhP5 specifications may be incomplete and will be updated in the future !) Directory 1 writing Objective 2 Overall requirements 3 security specifications 3.1 inclusion files 3.1.1 naming rules 3.1.2 storage rules 3.2 security rules 3.3 some PHP rules 3.4 other processing rules 3.4.1 escape input parameter values 3.4.2 large HTML text 4 coding specification 4.1 naming convention 4.1.1 variable naming 4.1.2 class 4.1.3 method or function 4.1.4 acronyms 4.1.5 database table name 4.1.6 database Field 4.2 writing rule 4.2.1 code indent 4.2.2 braces {} rule 4.2.3 parentheses () and function, keyword, etc. 4.2.4 = symbol writing 4.2.5 if else swith for while and so on write 4.2.6 class constructor 4.2.7 statement broken line, each line must be within 80 characters 4.2.8. Do not use incredible numbers 4.2.9 true/false and 0/1 to judge 4.2.10. Avoid embedded assignment. 4.2.11 error return detection rules 4.3 program comments 4.3.1 program header comments block 4.3.2 class comments 4.3.3 function and method comments 4.3.4 variables or statements comments 4.4 Other Specifications (recommended) 4.4.1 PHP code mark 4.4.2 program file name, directory name 4.4.3 PHP project's common file directory structure 4.4.4 separation of PHP and HTML code 4.4.5 PHP Project Development Program Logic Structure 5 PHP coding in a specific environment special specification 5.1 variable definition 5.2 Reference using 5.3 variable input/output 1 writing objective to better improve the efficiency of the technical department, this specification is specified to ensure the effectiveness and rationality of development and to maximize the readability and reusability of program code. The development team can supplement or reduce this specification based on their actual conditions. 2. Overall requirements the php development specifications of the technical department should follow the pear specifications and basically adopt the specifications specified by pear, and add, modify, or delete some of the specifications that are applicable to the specific development environment. This specification is only applicable to coding standards during php development. It will not focus on files, directories, and data libraries in PHP development projects. This specification includes naming rules, code indentation rules, control structures, function calls, function definitions, comments, comments containing code, PHP tags, file header comments, CVS tags, URL samples, and constant naming rules. 3. Security Specification 3.1 contains the file 3.1.1 the naming rule extracts the inclusion file with common functions. The file suffix is named as. Inc, indicating that this is an inclusion file. If there are multiple. the INC file must contain multiple pages. the INC file is encapsulated in a file. You only need to package one file on the page. inc file, for example: xxx_session.inc xxx_comm .. INC xxx_setting.inc mysql_db.inc encapsulate the above files in XXX. basic. require_once ("xxx_session.inc") in the inc file; require_once ("xxx_comm.inc"); require_once ("xxx_setting.inc"); require_once ("mysql_db.inc"); Note: whether to encapsulate it into a file, depending on the situation, if each Inc function is distributed to different pages for use, we will not discuss encapsulation. 3.1.2 storage rules generally include files that do not need to be directly exposed to users. Therefore, they should be placed in a directory inaccessible to the Web server to avoid leakage of configuration information due to configuration problems. 3.2 for security rules, see the product security checklist. Check whether HTML code is filtered for input and output: If malicious HTML code is entered, the cookie will be stolen and a malicious login form will be generated, whether or not escape may occur before the Website check variable is used for database operations: If a string variable to write a query statement contains some special characters, such as quotation marks (', ") or semicolon (;) may cause operations beyond expectation. Recommended method: Use mysql_escape_string () or implement functions similar to this function. Check the legality of the input value. An abnormal value may cause a problem. If you do not check the input values, illegal or incorrect data will be stored in UDB, other databases, or unexpected program operations will occur. For example, if the program uses the parameter value entered by the user as the file name, malicious input of the system file name will cause damage to the system. Verify the use of cookies and possible problems with processing user data: incorrect use of cookies may cause user data leakage, access control, and internal use of products or products for use by partners, consider adding access control logs to ensure that the user's confidential information is not recorded in the log (for example, the user's password) make sure that all user access records are saved for key user operations. For HTTPS transmission of sensitive data, Use https 3.3 to set register_globals = off (y! PHP has disabled register_globals. If you use y! PHP does not consider this setting.) set error_reporting = e_all (y! PHP default settings), and all errors and warnings must be corrected to put the actual operations in the referenced file. Place the referenced file in a directory that cannot be directly browsed. 3.4 other processing rules 3.4.1 escape the input parameter values. The parameter receiving page requires SQL operations. At this time, escape is required, pay special attention ";". For example, $ A = "Let's go"; $ SQL = "insert into TMP (COL) values ('$ A')"; errors may occur in this case. 3.4.2 When operating large HTML texts, you often need to store a large segment of HTML text for use on pages, such as custom page header and footer. Script flag should be removed to avoid malicious PHP code execution. Convert "<" ">" to ensure the code is complete. 4. coding specification 4.1 It is very important for project development to formulate a uniform naming convention, which not only helps programmers develop a good development habit, it also increases the readability, portability, and reusability of programs, and improves the efficiency of project development. 4.1.1 naming rules for variable names include common variables, static variables, local variables, global variables, and session variables. 4.1.1.1 naming of common variables follows the following rules: A. All letters are in lowercase; B. If a variable uses multiple words, '_' is used as the interval of each word. For example: 4.1.1.2 static variable names such as $ base_dir and $ red_rose_price follow the following rules:. static variables start with lowercase S _; B. all static variables use lower-case letters. C. variable names composed of multiple words use '_' as the interval of each word. Example: $ s_base_dir, $ s_red_rose_prise, etc. 4.1.1.3 naming of local variables follows the following rules:. all letters are in lower case; B. variable starts with '_'; C. the local variable name consisting of multiple words uses '_' as the interval between each word. Example: $ _ base_dir and $ _ red_rose_price. 4.1.1.4 The global variable must have the prefix 'G'. It is very important to know the scope of a variable. For example, global $ glog_level; global $ glog_path; 4.1.1.5 global constant global variable naming follows the rules below: A. All letters use uppercase B. global variables use '_' as the interval between multiple words. Example: $ base_dir, $ red_rose_price, etc. 4.1.1.6 the session variable name follows the following rules:. all letters are in uppercase; B. the session variable name starts with's _ '. C. use '_' to separate multiple words. Example: $ s_base_dir, $ s_red_rose_price, etc. 4.1.2 class names in PHP should follow the following rules: a. a. a variable name consisting of multiple words. There is no interval between words. The first letter of each word is capitalized. Example: Class myclass or class dboracle. 4.1.3 The method, function method, or function naming rules are as follows: A. lowercase letters; B. Multiple words do not use an interval. Except the first word, other words are capitalized. Example: function myfunction () or function mydboracle. 4.1.4 when a variable name or other names encounter a scale-in, refer to the specific naming rules, instead of all the original scale-in methods. Example: function mypear (not mypear) functio gethtmlsource (not gethtmlsource ). 4.1.5 database table name naming rules are as follows:. table names all use lower-case letters; B. for common data tables, end with _ t; C. for a view, end with _ v; D. the _ interval is used for table names composed of multiple words. For example, database Field Names of database fields such as user_info_t and book_store_v follow the following rules:. all use lower case; B. use _ interval between multiple words. Example: user_name, rose_price, etc. 4.2 writing rules refer to the code writing rules when writing PHP programs, including indentation, structure control, and other specifications: 4.2.1 code indentation when writing code, you must pay attention to the Code indent rules. The Code indent rules are as follows:. use four spaces as indentation without tab indentation (for ultraedit, you can set it in advance) Example: For ($ I = 0; $ I <$ count; $ I ++) {echo "test";} 4.2.2 braces {} writing rules write structure control code in the program, such as if, for, while, switch, etc, braces have two traditional writing habits:. {directly following the control statement, do not wrap, such as for ($ I = 0; $ I <$ count; $ I ++) {echo "test" ;} B. {In the next row of the control statement, for example, for ($ I = 0; $ I <$ count; $ I ++) {echo "test, A is the method recommended by pear, In actual writing, this does not affect program specifications and the use of phpdoc to implement documents. Therefore, you can use the above two methods according to your personal habits, but in the same program, use only one of them to avoid reading inconvenience. 4.2.3 parentheses (), function, keyword, and other parentheses, keywords, and functions follow the following rules:. do not enclose parentheses and keywords together. Use a space interval, for example, if ($ A <$ B); B. there is no space between the parentheses and the function name. For example, $ test = date ("ymdhis"); C. do not use parentheses in return statements unless necessary. For example, return $ A; 4.2.4 = symbol writing in the program = symbol writing follows the following rules:. leave a space on both sides of the = symbol, such as $ A = $ B, if ($ A = $ B), and B. in a declarative block or a block that implements the same function, the = sign is used up and down as much as possible. Multiple spaces can be used to maintain alignment on the left, and a space must be left on the right; for example, $ Testa = $ AAA; $ testaa = $ BBB; $ testaaa = $ CCC; 4.2.5 if else swith for while writes the control structure following the following rules:. in the if condition judgment, if the constant judgment condition is used, place the constant on the left of the equal or non-equal sign, for example, if (6 = $ errornum ), because if you miss an equal sign in the equation, the syntax examiner will report an error for you, and you can quickly find the wrong location. pay more attention to this writing method; B. the switch structure must have default blocks; C. in the fo In the loop use of R and wiile, be cautious with the use of continue and break to avoid problems similar to goto. If constructors of class 4.2.6 need to write constructor in class, the following rules must be observed:. there cannot be too many actual operations in the constructor, and at most some values and variables can be initialized; B. you cannot return false or error in the constructor because an object cannot be returned when an object is declared and instantiated. The statement 4.2.7 disconnects the line, each line is controlled to be less than 80 characters in code writing. Follow the following principles:. make sure that one line of a Program Statement is one, rather than a line of statement that is too long. B. do not make the code of a line too long. Generally, it must be within 80 characters. C. if a line of code is too long, use a line similar. =. for database SQL statement operations, do not write SQL statements in the function as much as possible. Instead, define SQL statements with variables and then call the Defined variables in the function that executes the row operation. For example: $ SQL = "select use Rname, password, address, age, postcode from test_t "; $ SQL. = "where username = 'aaa'"; $ res = mysql_query ($ SQL); 4.2.8 do not use incredible numbers. A naked number used in source code is an incredible number, because it includes the author, no one has its meaning within three months. Example: If (22 = $ Foo) {start_thermo_nuclear_war ();} else if (19 = $ Foo) {refund_lotso_money ();} else {cry_cause_im_lost ();} you should use define () to give you a real name for the value of something, rather than a naked number, for example: Define ("president_went_crazy", "22 "); define ("we_goofed", "19"); define ("they_didnt_pay", "16"); If (president_went_crazy = $ Foo) {start_thermo_nuclear_war ();} else if (we_goofed ==$ Foo) {refund_lotso_money ();} else If (they_didnt_pay = $ Foo) {infinite_loop ();} else {happy_days_ I _know_why_im_here ();} 4.2.9 true/false and 0/1 determine to follow the following rules:. 0/1 cannot be used to replace true/false. in PHP, This is not equal; B. do not use a non-zero expression, variable, or method to directly perform true/false judgment, but use a strict and complete true/false judgment. For example, if ($ A) is not used) or if (checka () and use if (false! = $ A) or if (false! = Check () 4.2.10 avoid embedded assignment in the program to avoid embedded assignment in the following example: Do not use this method: While ($! = ($ C = getchar () {process the character} 4.2.11 error return detection rules to check all system call error messages, unless you want to ignore the error. Define the system error text for each system error message and record the error log. 4.3 program comments each program must provide the necessary comments, write the annotation Requirements Specification, refer to the comments requirements provided by pear, to prepare for the future use of phpdoc to generate PHP documents. The program annotation principles are as follows:. note: Except for the comment block of the file header, the/comment is not used in other places, but the/**/comment is used. B. the comment content must be written before the commented object, not in one line or later. 4.3.1 The program header comment block each program header must have a unified comment block. The rules are as follows:. must contain the description of this program; B. must contain the author; C. must contain the writing date; D. must contain version information; E. the project name must be included; F. the file name must be included; G. important usage instructions, such as class call methods and precautions. The reference examples are as follows: /// + versions + // | PHP version 4.0 | // + --------------------------------------------------------------- + // | copyright (c) 1997-2001 the PHP Group | // + ------------------------------------------------------- + // | this source file is subject to of the PHP license, | // | that is bundled with this packafile license, and is | // | available at through the world-web at | // | http://www.php.net/license/2_02.txt. | // | if you did not receive a copy of the and are unable to | // | obtain it through the World-Wide-web, End a note to | // | license@php.net so we can mail you a immediately. | // + ------------------------------------------------------- + // | authors: Stig Bakken | // | Tomas v. v. cox | // + ----------------------------------------------------------- + // $ ID: Common. PHP, V 1.8.2.3 2001/11/13 01:26:48 SSB exp $4.3.2 class annotation uses the reference example method:/*** @ purpose: * class used to access the database, use ODBC as the universal access interface * @ package name: Database * @ Author: Forrest Gump gump@crtvu.edu.cn * @ modifications: * No20020523-100: * odbc_fetch_into () parameter location Second and Third location interchange * John Johnson John@crtvu.edu.cn * @ see: (reference) */class database {......} 4.3.3 comments of functions and methods are written before functions and methods. rules similar to the following example are used:/*** @ purpose: * execute a query * @ Method Name: Query () ** @ Param: String $ querystr SQL query string * @ Param: String $ username ** @ Author: michael Lee ** @ return: returned value of the mixed query (result set object) */function ($ querystr, $ username ){......} 4.3.4 annotations for variables or statements in the program follow the following principles:. written in the first line of a variable or statement, not in the same line or later; B. comments are in the/**/mode. C. each function must contain a comment block. The content includes the function description, input/output parameters, expected return values, and error code definition. D. Complete annotations. E. delete codes that have been commented out, or indicate the special reasons for the codes that have been commented out to be retained in the source code. F. example:/*** @ purpose: * database connection username * @ attribute/variable name: db_user_name * @ Type: string */var db_user_name; 4.4 Other Specifications (recommended) 4.4.1 PHP code marks all PHP program code block marks using 4.4.2 program file name, directory name, and directory name naming in meaningful English, do not use Pinyin or meaningless letters. At the same time, lowercase letters must be used. Separate multiple words. 4.4.3 it is recommended that the standard file directory structure be used when developing standard independent PHP projects. This helps improve the rationality of the project's logical structure, and expand and cooperate with each other, and team development. A complete and independent PHP project usually has the following file and directory structures: /Project root directory/manage background management file storage directory/CSS file storage directory/DOC Storage Project Document/images all image file storage path (in which subdirectories are set up according to the directory structure) /scripts client JS Script directory/TPL website all HTML template files directory/error. PHP error handling files (which can be defined in Apache error handling) the preceding directory structure is a common directory structure. Based on the specific situation of the application, you can consider not to fully follow this structure, but try to be standardized. 4.4.4 separation of PHP and HTML code does not require high performance projects and applications. We recommend that you do not directly mix PHP and HTML code to write code, the separation of PHP and HTML code, that is, the processing of templates, is beneficial to the clearer logic structure of the program and the division of labor in the development process, at the same time, it also provides more convenience to upgrade the version of the Japanese project page. In some special cases, such as applications with high performance requirements, templates are not recommended. 4.4.5 The Program Logic Structure in PHP project development should be developed with the idea of OOP as much as possible for PHP project development. Especially after PhP5, the object-oriented development function will be greatly improved. In the PHP project, we suggest writing independent functional modules as function calls as much as possible, corresponding to a whole business logic. We suggest encapsulating them into classes to improve code readability, it can also improve code reusability. For example, we usually encapsulate database interfaces into database classes, which facilitates the migration of platforms. Duplicate code should be made into a public library. (In addition to the situation we encounter on the plug-in product, this product series has many similar products, in order to minimize the installation package size, it is not suitable to make all functions shared by these products into a public library) 5. PHP code Special specification in a specific environment 5.1 variables define PHP code in the xxx environment. All variables must be affirmed before use. Otherwise, an error message is displayed. For arrays, when an uncertain key is used, for example, the isset () is first judged and then used. For example, the following code: $ array = array (); $ Var = isset ($ array [3])? $ Array [3]: ""; 5.2 references are often used in the program. To share the same memory, you do not need to copy it separately, when using a reference in the xxx environment, you must pay attention to the following situations. When using a reference in input parameters of a function, you cannot add & to reference before the input parameters during the call, you can directly use this variable. At the same time, you must specify that the input parameter is from reference when the function is defined. For example, the following code: $ A = 1; function AB (& $ var) {$ var ++; return $ var;} $ B = AB ($ A) // note that $ B = AB (& $ A) cannot be used here; echo $ B. "/N"; echo $. "/N"; at this time, both $ A and $ B are 2. The special requirements for reference in the xxx environment are derived from PHP. set the allow_call_time_pass_reference item in the INI file. The public version is on, so that you can add and reference the variable before calling the function. But this method has been protested and may not be supported in future PHP/Zend versions. It is encouraged to specify which parameters are passed by reference in the function declaration. You are encouraged to disable this option (with off, all runtime environments of XXX are off) and confirm that your script can still work normally, to ensure that they can still work in future versions. 5.3 When the input and output of variables are in the xxx environment, strict filtering and legality verification are required for parameters transmitted through the get or POST method on the web, we do not recommend that you use $ _ Get, $ _ post, or $ _ request to obtain the data. However, you can use the methods provided by the xxx_yiv module of XXX to obtain and filter the data.