If Then Else 格式 布局 這由程序員決定。不同的花括號樣式會產生些微不同的樣觀。一個通用方式是： if (條件1) // 注釋 { } else if (條件2) // 注釋 { } else // 注釋 { } 如果你有用到else if 語句的話，通常最好有一個else塊以用於處理未處理到的其他情況。可以的話 放一個記錄信息注釋在else處，即使在else沒有任何的動作。 條件格式 總是將恆量放在等號/不等號的左邊，例如： if ( 6 == $errorNum ) ... 一個原因是假如你在等式中漏了一個等號，語法檢查器會為你報錯。第二個原因是你能立刻找到數值 而不是在你的表達式的末端找到它。需要一點時間來習慣這個格式，但是它確實很有用。 -------------------------------------------------------------------------------- switch 格式 Falling through a case statement into the next case statement shall be permitted as long as a comment is included. default case總應該存在，它應該不被到達，然而如果到達了就會觸發一個錯誤。 如果你要創立一個變量，那就把所有的代碼放在塊中。 例如 switch (...) { case 1: ... // FALL THROUGH case 2: { $v = get_week_number(); ... } break; default: } -------------------------------------------------------------------------------- continue,break 和 ? 的使用: Continue 和 Break Continue 和 break 其實是變相的隱蔽的 goto方法。 Continue 和 break 像 goto 一樣，它們在代碼中是有魔力的，所以要節儉（盡可能少）的使用它們。 使用了這一簡單的魔法，由於一些未公開的原因，讀者將會被定向到只有上帝才知道的地方去。 Continue有兩個主要的問題： 它可以繞過測試條件。 它可以繞過等/不等表達式。 看看下面的例子，考慮一下問題都在哪兒發生： while (TRUE) { ... // A lot of code ... if (/* some condition */) { continue; } ... // A lot of code ... if ( $i++ > STOP_VALUE) break; } 注意："A lot of code"是必須的，這是為了讓程序員們不能那麼容易的找出錯誤。 通過以上的例子，我們可以得出更進一步的規則：continue 和 break 混合使用是引起災難的正確方法。 ?: 麻煩在於人民往往試著在 ? 和 : 之間塞滿了許多的代碼。以下的是一些清晰的連接規則： 把條件放在括號內以使它和其他的代碼相分離。 如果可能的話，動作可以用簡單的函數。 把所做的動作，“?”，“:”放在不同的行，除非他們可以清楚的放在同一行。 例如 (condition) ? funct1() : func2(); or (condition) ? long statement : another long statement; -------------------------------------------------------------------------------- 聲明塊的定位 聲明代碼塊需要對齊。 理由Justification 清晰。 變量初始化的類似代碼塊應該列表。 The ??token should be adjacent to the type, not the name. 例如 var $mDate var& $mrDate var& $mrName var $mName $mDate = 0; $mrDate = NULL; $mrName = 0; $mName = NULL; -------------------------------------------------------------------------------- 每行一個語句 除非這些語句有很密切的聯系，否則每行只寫一個語句。 -------------------------------------------------------------------------------- 短方法 方法代碼要限制在一頁內。 理由 這個思想是，每一個方法代表著一個完成單獨目的的技術。 從長遠來說，過多的無效參數是錯誤的。 調用函數比不調用要慢，但是這需要詳細考慮做出決定（見premature optimization 未完善的優化）。 -------------------------------------------------------------------------------- 記錄所有的空語句 總是記錄下for或者是while的空塊語句，以便清楚的知道該段代碼是漏掉了，還是故意不寫的。 while ($dest++ = $src++) ; // VOID -------------------------------------------------------------------------------- 不要采用缺省方法測試非零值 不要采用缺省值測試非零值，也就是使用： if (FAIL != f()) 比下面的方法好： if (f()) 即使 FAIL 可以含有 0 值 ，也就是PHP認為false的表示。在某人決定用-1代替0作為失敗返回值的時候， 一個顯式的測試就可以幫助你了。就算是比較值不會變化也應該使用顯式的比較；例如：if (!($bufsize % strlen($str))) 應該寫成：if (($bufsize % strlen($str)) == 0)以表示測試的數值（不是布爾）型。一個經常出 問題的地方就是使用strcmp來測試一個字符等式，結果永遠也不會等於缺省值。 非零測試采用基於缺省值的做法，那麼其他函數或表達式就會受到以下的限制: 只能返回0表示失敗，不能為/有其他的值。 命名以便讓一個真(true)的返回值是絕對顯然的，調用函數IsValid()而不是Checkvalid()。 -------------------------------------------------------------------------------- 布爾邏輯類型 大部分函數在FALSE的時候返回0，但是發揮非0值就代表TRUE，因而不要用1（TRUE，YES，諸如此類）等式檢測一個布爾值，應該用0（FALSE，NO，諸如此類）的不等式來代替： if (TRUE == func()) { ... 應該寫成： if (FALSE != func()) { ... -------------------------------------------------------------------------------- 通常避免嵌入式的賦值 有時候在某些地方我們可以看到嵌入式賦值的語句，那些結構不是一個比較好的少冗余，可讀性強的方法。 while ($a != ($c = getchar())) { process the character } ++和--操作符類似於賦值語句。因此，出於許多的目的，在使用函數的時候會產生副作用。使用嵌入式賦值 提高運行時性能是可能的。無論怎樣，程序員在使用嵌入式賦值語句時需要考慮在增長的速度和減少的可維 護性兩者間加以權衡。例如： a = b + c; d = a + r; 不要寫成： d = (a = b + c) + r; 雖然後者可以節省一個周期。但在長遠來看，隨著程序的維護費用漸漸增長，程序的編寫者對代碼漸漸遺忘， 就會減少在成熟期的最優化所得。 -------------------------------------------------------------------------------- 重用您和其他人的艱苦工作 跨工程的重用在沒有一個通用結構的情況下幾乎是不可能的。對象符合他們現有的服務需求，不同的過程有著 不同的服務需求環境，這使對象重用變得很困難。 開發一個通用結構需要預先花費許多的努力來設計。當努力不成功的時候，無論出於什麼原因，有幾種辦法推 薦使用： 請教！給群組發Email求助 這個簡單的方法很少被使用。因為有些程序員們覺得如果他向其他人求助，會顯得自己水平低，這多傻啊!做新 的有趣的工作，不要一遍又一遍的做別人已經做過的東西。 如果你需要某些事項的源代碼，如果已經有某人做過的話，就向群組發email求助。結果會很驚喜哦！ 在許多大的群組中，個人往往不知道其他人在干什麼。你甚至可以發現某人在找一些東西做，並且自願為你寫代 碼，如果人們在一起工作，外面就總有一個金礦。 告訴！當你在做事的時候，把它告訴所有人 如果你做了什麼可重用的東西的話，讓其他人知道。別害羞，也不要為了保護自豪感而把你的工作成果藏起來。 一旦養成共享工作成果的習慣，每個人都會獲得更多。 Dont be Afraid of Small Libraries 對於代碼重用，一個常見的問題就是人們不從他們做過的代碼中做庫。一個可重用的類可能正隱蔽在一個程序目 錄並且決不會有被分享的激動，因為程序員不會把類分拆出來加入庫中。 這樣的其中一個原因就是人們不喜歡做一個小庫，對小庫有一些不正確感覺。把這樣的感覺克服掉吧，電腦才不 關心你有多少個庫呢。 如果你有一些代碼可以重用，而且不能放入一個已經存在的庫中，那麼就做一個新的庫吧。如果人們真的考慮重 用的話，庫不會在很長的一段時間裡保持那麼小的。 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
