極速賽車源碼搭建 PHP中的防御性編程

條件語句
這是最容易進行防御性編程的地方之一，也是最容易滿足的地方。在用PHP編程的許多情況下你不會需要“else”。


假設，極速賽車源碼搭建bbs.yasewl.com你在寫一個函數并且需要一個條件語句。在這里，你只需要為你特定的變量使用三個條件語句如下：


if($var == a){ }
else if($var == b){ }
else if($var == c){ }
沒有其他可能性了，你說，并且繼續碼代碼。但是，讓我們在這里停一下。我知道你知道這里沒有其他可能性了。并且我相信你。但有時候（不可預測的）情況會發生。我們忘掉了一些情況。我們檢查錯誤。我們最終重用了一些代碼，超出了原本的預定范圍。突然我們有了泄露錯誤或者有時候是靜默的錯誤狀態，因為我們沒有使用catch。使用else代碼塊。在使用switch時要使用default。用它們來返回或者記錄錯誤，這樣你才知道發生了什么（如果發生了的話）。雖然會多用兩行代碼，但當一些你無法預測的事情發生時，這是值得的。


絕不相信用戶輸入
你以前有沒有聽說過這個說法？大多數程序員聽過。這有一點含糊，通俗點講，理所當然。但它是真理。你絕不應該相信用戶輸入。這不是說你假設所有用戶是瘋狂的黑客，他們使用一些精心設計的命令來摧毀你的應用。沒有必要妄想。但是，你應該假設用戶不知道你的代碼，他們不知道你需要填寫什么參數，或者參數應該多長。他們不知道什么文件類型或者什么大小能上傳（即使應用告訴了他們）。偶爾他們會是機器或者黑客并且他們希望在他們的輸入中運行腳本，有時候甚至是在登陸后的輸入中。你怎么知道你能相信認證或者驗證碼能在用戶輸入之前提供一個安全的堡壘？


答案：絕不。


你絕不相信用戶輸入。如果你信任的用戶輸入，那么你永遠不會有一個突破。明白了嗎？所以總是要評估你的輸入，一定要保證你在處理數據尤其是要存入數據庫或者要把它展示出來時使用了合適的技術。因此 – 絕不相信輸入，即使來自不是用戶的輸入的地方 – 輸入驗證永遠是你的朋友。看看Survive the Deep End: PHP Security 并且使用 validation library.吧。


對你的代碼的假設
不要假設任何事情。如果前兩個主題教會我們一些事情的話,那就是我們不應該做任何假設。作為程序員，尤其是致力于一個項目太久后，我們開始做很多假設。我們假設用戶知道一些我們知道的事情。不一定是技術細節，也可以是程序的功能性細節。我們假設用戶知道文件能有多大因為。。。我們已經知道。或者他們知道為了讓郵件腳本。。。但事實不是，他們不知道以上任何東西。這好像更多的是前端的工作，但明顯的是你在后端仍然要處理用戶行為和用戶輸入，所以值得好好想想。


另一個許多程序員都會做的驚人的假設是我們在任何時候對于我們的函數，類或者其它代碼段的明顯的功能屬性。一個具有防御性的程序員會仔細考慮的不僅僅是用一般的文檔來描述函數是干什么的——他們也將寫下他們對輸入,參數,用例,或任何其他類似的東西做出的任何假設。因為我們都是人，我們過一段時間會忘掉一些事。我們最后也很可能會面臨其他人維護，擴展或者替換我們的代碼。如果沒有別的,回想一下,編程是發生在一個充滿技術變革的世界里。如果你的應用仍然能使用幾年，可能會升級PHP版本并且失去一些功能，或者一些你自己代碼里面具有交互的組件之間需要改變。預測這些是很困難的，所以好的注釋和文檔是非常重要的。


視野狹窄
另一件可以使我們忘記好的評論實踐以及標準的東西是視野狹窄。許多程序員都具有視野狹窄的毛病。你知道這種感覺 - 你解決問題,你處于最佳狀態。你覺得與你的音樂(或沒有)獨立于自己的小世界中，并且你就在編碼，突然兩小時過了，你意識到你已經寫了無數行沒有注釋的代碼。我們所有人偶爾都會遇到這種事情，但重要的是在某處發現這個情況并且補上應有的注釋。


語法和命名的一致性
一致性是一個灰色地帶 – 它更多的是關于編碼標準之類的，但它和防御性編程也有聯系。在PHP中，有標準規范你的代碼格式以便別人查看，或者你以后使用。但常常沒人讓你的代碼標準化。但是無論你是否按照標準編碼，你至少要保持一致性 – 這能讓你少犯錯誤。這對于需要大量時間返回并且修復的小的語法錯誤尤其適用。如果你總是使用相同的間隔，格式和語法，命名規格等等你就能更好的避免犯錯以至于誤讀你自己的代碼。你更可能快速瀏覽代碼并且找到你需要的東西。