Specification 2_PHP Tutorial-PHP Tutorial-php.cn

If Then Else Format Layout This is decided by the programmer. Different brace styles will produce slightly different looks. A common way is: if (condition 1) // comment { } else if (condition 2) // comment { } else // comment { } If you use an else if statement, it is usually best to have an else block to use it To handle other unhandled situations. If possible, put a record information comment in else, even if there is no action in else. Conditional formatting always puts the constant to the left of the equal/inequality sign, for example: if ( 6 == $errorNum ) ... One reason is that if you leave out an equal sign in the equation, the syntax checker will report an error for you . The second reason is that you can find the value immediately instead of finding it at the end of your expression. It takes a little time to get used to the format, but it works really well. -------------------------------------------------- ------------------------------- switch format Falling through a case statement into the next case statement shall be permitted as long as a comment is included. The default case should always exist, it should not be reached, but if it is reached it will trigger an error. If you are creating a variable, put all the code in a block. For example switch (...) { case 1: ... // FALL THROUGH case 2: { $v = get_week_number(); ... } break; default: } ------------ -------------------------------------------------- ------------------ Use of continue, break and ?: Continue and Break Continue and break are actually hidden goto methods in disguise. Continue and break are like goto, they work magic in your code, so use them sparingly (as little as possible). Using this simple magic, readers will be directed, for some undisclosed reason, to places only God knows. Continue has two main problems: It can bypass test conditions. It can bypass equality/inequality expressions. Look at the following example and consider where the problems occur: while (TRUE) { ... // A lot of code ... if (/* some condition */) { continue; } ... // A lot of code ... if ( $i++ > STOP_VALUE) break; } Note: "A lot of code" is required so that programmers cannot find errors so easily. From the above examples, we can draw a further rule: mixing continue and break is the right way to cause disaster. ?: The trouble is that people tend to try to cram a lot of code between ? and :. Here are some clear linking rules: Put the condition in parentheses to separate it from the rest of the code. If possible, actions can use simple functions. Put the actions, "?", and ":" on different lines, unless they can clearly be placed on the same line. For example (condition) ? funct1() : func2(); or (condition) ? long statement : another long statement; ----------------------- -------------------------------------------------- ----- Positioning of declaration blocks Declaration code blocks need to be aligned. Justification is clear. A similar block of code for variable initialization should be listed. The ??token should be adjacent to the type, not the name. For example var $mDate var& $mrDate var& $mrName var $mName $mDate = 0; $mrDate = NULL; $mrName = 0; $mName = NULL; -- -------------------------------------------------- ---------------------------- One statement per line Write only one statement per line unless the statements are closely related. -------------------------------------------------- ----------------------------- Short method code should be limited to one page. Rationale The idea is that each method represents a technique that accomplishes a separate purpose. Too many invalid arguments are a mistake in the long run. Calling a function is slower than not calling it at all, but this decision requires careful consideration (see premature optimization). -------------------------------------------------- -------------------------- Record all empty statements. Always record the empty block statements of for or while for clarity. I don’t know whether this piece of code was missed or was deliberately not written. while ($dest++ = $src++); // VOID ---------------------------------------------- ------------------------------------------ Do not use the default method to test for non-zero Do not use the default value to test non-zero values, that is, use: if (FAIL != f()) is better than the following method: if (f()) Even FAIL can contain a value of 0, which is what PHP considers false. . When someone decides to use -1 instead of 0 as a failure return value, an explicit test can help. Explicit comparison should be used even if the comparison value will not change; for example: if (!($bufsize % strlen($str))) should be written as: if (($bufsize % strlen($str)) == 0) A numeric (not Boolean) type representing the test. A common problem is using strcmp to test a character equation, and the result will never equal the default value. Non-zero tests are based on default values, so other functions or expressions will be subject to the following restrictions: they can only return 0 to indicate failure, and cannot have other values. Named so that a true return value is absolutely obvious, call the function IsValid() instead of Checkvalid().-------------------------------------------------- -------------------------- Most functions of the Boolean logic type return 0 when FALSE, but when a non-0 value is used, it means TRUE, so instead of testing a Boolean value with an equality of 1 (TRUE, YES, etc.), use an inequality of 0 (FALSE, NO, etc.) instead: if (TRUE == func()) { ... should be written as : if (FALSE != func()) { ... ---------------------------------------- ----------------------------------------------- Generally avoid embedded assignments Sometimes in some places we can see embedded assignment statements. Those structures are not a better method with less redundancy and strong readability. while ($a != ($c = getchar())) { process the character } The ++ and -- operators are similar to assignment statements. Therefore, for many purposes, side effects can occur when using functions. It is possible to improve runtime performance using embedded assignment. Regardless, programmers need to consider the tradeoff between increased speed and reduced maintainability when using embedded assignment statements. For example: a = b + c; d = a + r; Do not write: d = (a = b + c) + r; although the latter saves one cycle. But in the long run, as the maintenance costs of the program gradually increase and the program writers gradually forget about the code, the optimization gains in the mature period will be reduced. -------------------------------------------------- ----------------------------- Reuse yours and others' hard work Reuse across projects without a common structure Almost impossible. Objects conform to their existing service requirements. Different processes have different service requirements environments, which makes object reuse difficult. Developing a common structure requires a lot of design effort up front. When efforts are unsuccessful, no matter for whatever reason, there are several methods recommended: Ask for advice! Send an email to the group for help. This simple method is rarely used. Because some programmers feel that if they ask other people for help, they will look inferior. How stupid is this! Do new and interesting work, don't do what others have done over and over again. If you need source code for something, if someone has already done it, email the group for help. The results will be surprising! In many large groups, individuals often have no idea what others are doing. You might even find someone looking for something to do and volunteer to write code for you, and if people work together there's always a gold mine out there. Tell! When you do something, tell everyone about it. If you make something reusable, let others know. Don’t be shy, and don’t hide your work away to protect your pride. Once you get into the habit of sharing your work, everyone will gain more. Dont be Afraid of Small Libraries A common problem with code reuse is that people don't build libraries from the code they've worked on. A reusable class may be hiding in a program directory and will never be shared because the programmer won't split the class out and add it to the library. One of the reasons for this is that people don't like to make a small library and have some incorrect feelings about small libraries. Get over this feeling, the computer doesn't care how many libraries you have. If you have some code that can be reused and can't be put into an existing library, then make a new library. If people really thought about reuse, the library wouldn't stay that small for a long time.If you are afraid of having to update makefiles when libraries are recomposed or added then dont include libraries in your makefiles, include the idea of services. Base level makefiles define services that are each composed of a set of libraries. Higher level makefiles specify the services they want. When the libraries for a service change only the lower level makefiles will have to change. Keep a Repository Most companies have no idea what code they have. And most programmers still dont communicate what they have done or ask for what currently exists. The solution is to keep a repository of whats available. In an ideal world a programmer could go to a web page, browse or search a list of packaged libraries, taking what they need. If you can set up such a system where programmers voluntarily maintain such a system, great. If you have a librarian in charge of detecting reusability, even better. Another approach is to automatically generate a repository from the source code. This is done by using common class, method, library, and subsystem headers that can double as man pages and repository entries. -------------------------------------------------------------------------------- 评价注释注释应该是讲述一个故事 Consider your comments a story describing the system. Expect your comments to be extracted by a robot and formed into a man page. Class comments are one part of the story, method signature comments are another part of the story, method arguments another part, and method implementation yet another part. All these parts should weave together and inform someone else at another point of time just exactly what you did and why. Document Decisions Comments should document decisions. At every point where you had a choice of what