以下這些tips，是我在實際工作中慢慢形成的，有些可能是不正確的，有些出於個人習慣，所以，千萬不要把以下這些條當成什麼標准，其中可能隱藏著天大的bug，代碼可能正在病態的運行中，SO!請一定仔細的看過後想想，這麼做的好處是什麼？會產生怎樣的負面影響？
開發習慣和PHP代碼
- 准確的理解各種概念。現在的新東西層出不窮，望文生義和一知半解對開發工作有害無益；
- 代碼美觀，適當的空行、縮進，空格，這樣能更容易理解代碼段的意思；
- 一定要寫注釋，而且要恰當的注釋，要不然後面的維護工作或者接手代碼的人會痛哭不已；
- 靜態方法、類訪問權限、接口、抽象類應該綜合起來使用，發揮各自特點；
- 不要復制粘貼，即使是要用到現成的代碼，也要一行一行的審閱後，再加入到新項目，因為經驗告訴我們，這太容易出錯了，對於使用開源類這種大段代碼更需要；
- 變量都要初始化；
- 不要只處理error，而忽略warning和notice，這可能會導致日後的莫名其妙的問題，項目在開發狀態下應該是error_reporting( E_ALL ^ E_NOTICE )，等到發布的外網生產環境時，應關閉所有錯誤報告display_errors=Off,error_reporting(0)網友 pAUL gAO分享了他們更合理的方案，error_reporting(E_ALL | E_STRICT)，並且在生產環境中記錄錯誤日志。
- 記錄一些必要的錯誤日志，比如寫文件失敗、寫memcache失敗，socket連接失敗、讀寫數據庫失敗，日志能夠幫助出現問題時的快速定位，外部生產環境我個人是強烈建議關閉所有錯誤報告的；
- 用try、catch捕獲異常，對代碼的健壯有幫助，常常在API接口中碰到，這樣子顯得友好多了；
- 雙引號中出現的變量建議加上大括號，至於是"${nider}at gmail.com"還是"{$tom}at zendstudio.net"看個人習慣，我更喜歡後面一種；
- 盡量少的if else嵌套層數，也許你要表達一個非常復雜的邏輯算法，但這樣做至少能讓代碼邏輯更清晰
- 多閱讀網上開源項目的優秀代碼（不是優秀項目的開源代碼），吸取其中值得借鑒的地方
- 語言包用sprintf的格式化來做是多麼惬意的一件事啊！
- 寫緩存並不總是要先serialize一次的
- AJAX傳數據的時候，不要將數據庫查出的數組直接json_encode後傳給客戶端，這樣做不僅有一定的安全風險（字段名暴露），而且一些不需要的數據被傳出浪費帶寬，這條同樣適用於API接口
- 要記得處理魔術變量，我的方法是直接關閉，當然也可以獲取開關狀態來避免傳輸數據被處理兩次的問題
- 用$GLOBALS['var']代替global $var
- 不能輕易的die掉程序，尤其是在方法內部
- require、require_once、include、include_once有著略微不同的應用場景
- 為了最大限度的使得寫入緩存成功，可以結合重試次數+usleep，我一般重試3次，還不行那就記下一條log了
- PHP的常量是個非常好的東西，很多開源項目中用一整個文件來定義要用到的常量
- 盡可能的使用絕對路徑尋找文件
- autoload是個很靈活的東西
- 最好用上set_error_handler和set_exception_handler，那顯得你的項目更完美
- PHP的引用類型是很高效的，在進行復雜運算時建議使用
- @符號抑制錯誤是很耗性能的，因此盡可能的找到替代方案
MySQL部分
- SQL語句用雙引號，其中的值都用單引號，例如"INSERT INTO gril SET money='{$iMaxMoney}',age='18′"
- 用mysqli擴展代替mysql擴展
- 用mysqli_real_escape_string和mysqli_escape_string處理傳出sql語句中的變量
- 用mysqli_set_charset(mysqli->set_charset)代替 query "SET NAMES"
- 聯合查詢(JOIN)之前，考慮下各個表的數據量，不合適的話應該分開查，尤其是有緩存可用的時候
- 很多地方需要記錄發生時間，但不是每一個表都需要，同樣，不是每一個表都需要一個自增量作主鍵
- 很多時候為integer類型加上unsigned是很好的
- INERT DELEYED、INSERT IGNORE、SELECT DISTINCT…這種語句通常有意想不到的好效果
- varchar類型並不是不能超過255長度，而是超過了255，這個字段就不能建立索引了，所以，看你的實際需要了
暫時就想到這麼多，等再想到的繼續update吧。想到什麼寫什麼，沒有什麼條理性，多多包涵了，如果這些對你有點滴幫助，那我就感到非常開心了。
