摘要:為什么需要編碼規范為了提高工作效率,保證開發的有效性和合理性。在文件編碼中,選擇推薦在換行符中,選擇推薦文件命名程序的文件名和目錄名都采用有意義的英文命名。最后最后說的是,本規范不是強制,也不是標準。回復編碼規范即可。
為什么需要編碼規范?
為了提高工作效率,保證開發的有效性和合理性。
為了提高代碼可讀性和可重復利用性,從而節約溝通成本。
本文主要參考了 PEAR 規范,并進行適當的簡化和調整。
主要介紹,命名規范、注釋規范、代碼風格。
文件標記
所有PHP文件,代碼標記均使用完整的PHP標簽,不建議使用短標簽。
//短標簽不推薦 echo "Hello world"; ?>
文件格式
文件編碼 為無 BOM 的 UTF-8。
?純PHP類文件,文件最后 ?> 要省略。
TextMate
在 "文件編碼" 中,選擇 "UTF-8(推薦)"
在 "換行符" 中,選擇 "LF(推薦)"
文件命名
程序的文件名和目錄名都采用有意義的英文命名。
不使用拼音或無意義的字母。
只允許出現字母、數字、下劃線、中劃線字符。
多個詞之間使用駝峰命名法。
//類統一采用
demoTest.class.php
//接口統一采用
demoTest.interface.php
//其他按照各自的方式
demoTest.{style}.php
//其他文件參照
demoTest.inc.php
demo.lib.php
文件目錄結構命名
因使用的框架不同,可根據實際情況考慮目錄結構。
全局變量命名
$_GLOBAL["_startTime_"] or $_GLOBAL["g_startTime_"]
兩邊都有“_”,中間使用駝峰命名。
普通變量命名
數據類型 | 命名規范 |
---|---|
字符串 | $strMyStr |
數組 | $arrMyArray |
對象 | $objMyObject |
布爾值 | $flagMyFlag |
采用駝峰命名,建議在變量前加上變量的類型作為前綴。
變量應該以名詞為準,盡量避免使用常用關鍵字或存在模糊意義的單詞。
私有變量,建議加上前綴"_"。
函數命名
函數名即要有意義,也要盡量縮寫,一看就知道干什么。
建議單用動詞或動詞加形容詞的格式命名。
私有方法,建議在加上前綴"_"。
//例如 private function _showMsg() { //方法體 }
不建議下面這樣的函數名:
public function getAdvertisementByCategoryIdAndPositionIdAndScheduleId() { //方法體 }
可修改為:
public function getAd($categoryid, $positionid, $scheduleid) { //方法體 }
習慣與約定
為了減少變量的長度,在不影響可讀性的前提下,習慣對變量進行縮寫。
全稱 | 縮寫 |
---|---|
image | img |
string | str |
database | db |
array | arr |
count | cnt |
message | msg |
password | passwd 或 pwd |
... | ... |
以上規范可用于,PHP代碼、JavaScript代碼、數據庫表字段命名等。
文件注釋
/** * 文件的簡述 * * PHP Version 6(PHP版本) * * @category 可以寫部門(英文) * @package 可以寫模塊(英文) * @author test* @time 2017/02/02 11:48 * @copyright 2017 公司名稱 * @license 公司網址 license * @link test@qq.com(作者聯系方式) */
類注釋
/** * 類的簡述 * * @category 可以寫部門(英文) * @package 可以寫模塊(英文) * @author test* @license 公司網址 license * @link test@qq.com(作者聯系方式) */
方法注釋
/** * 方法的簡述 * @param array $myArray 參數解釋 * @param string $myString 參數解釋 * @return array(返回數據類型) */
代碼注釋
注釋寫在被注釋代碼的前面,而不是后面,但對于單行語句,注釋可寫在語句末尾。
對于大段注釋,使用 / / 進行注釋。
注釋不宜太多,大家能看的懂得行不必注釋。
代碼注釋應該描述為什么,而不是做什么。
不要為了注釋而注釋。
標注的使用
IDE 支持一些特殊注釋,可以列出整個項目中的特殊注釋,方便后期維護和代碼檢查。
例如:
//@fixMe 表示需要修復項。
//@todo 表示需要完善的地方。
代碼風格
盡量保證程序語句一行就是一句。
盡量不要使一行的代碼過長,一般控制在80個字符之間。
如果一行代碼太長,請使用類似 “.=” 的方式斷行書寫。
類、方法的做大括號需要獨占一行。
其他控制語句等大括號和表達式同一行,并空格隔開。
class Demo { public function index() { for ($i = 1, $i < 10, $i++) { } } public function test() { if ($expr1) { //if body } elseif ($expr2) { //elseif body } else { //else body } foreach ($data as $key => $value) { //foreach body } switch ($expr1) { case 0: echo "零"; break; case 1: echo "一"; break; default: echo "null"; break; } //盡量同等意義的變量等號對其 $strName = $arrUserInfo["name"]; $strAge = $arrUserInfo["age"]; $strBirthday = $arrUserInfo["birthday"]; $strHobby = $arrUserInfo["hobby"]; } }
調試代碼
不要在你的提交的代碼中包含調試代碼,就算是注釋掉了也不行。
像 var_dump() 、 print_r() 、 die() 和 exit() 這樣的函數。
PHP錯誤
運行代碼時不應該出現任何錯誤信息,并不是把警告和提示信息關掉來滿足這一點。
例如,絕不要直接訪問一個你沒設置過的變量,你應該先使用 isset() 函數判斷下。
最后
最后說的是,本規范不是強制,也不是標準。
“約定大于規范”,如果有的規范太死板,不適應您的團隊,您可以不采用,按照您自己的規范即可。
推薦PHP開發IDE:PHPStorm 。
推薦閱讀:
Mac PHPStorm 使用心得
PHP團隊開發中遇到的那些坑,看我是如何解決的?
如果大家需要下載PDF,可以關注微信公眾號。
回復 “php編碼規范” 即可。
Thanks ~
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/22359.html
摘要:標準規范簡介是的簡寫,由組織制定的規范,是開發的實踐標準。具體標準有有了統一編碼風格規范,更有利于查看和學習各個框架或類庫,不不需要每次都適應新的編碼風格。同時在開發團隊內部使用統一的編碼規范更有利于代碼審查版本控制團隊內部交流。 PHP 標準規范 PSR PSR 簡介 PSR 是 PHP Standard Recommendations 的簡寫,由 PHP FIG 組織制定的 PHP...
摘要:注本文算是筆者對規范翻譯學習筆記,之后會陸續翻譯剩余的規范,可能翻譯的有錯誤的地方,希望讀者能夠指正,非常感謝什么是是標準建議的簡寫,是由組織框架交互操作組織提出。的工作是尋找項目之間的共性,以及讓開發者能更好協同工作的方式。 注:本文算是筆者對PSR規范翻譯/學習筆記,之后會陸續翻譯剩余的規范,可能翻譯的有錯誤的地方,希望讀者能夠指正,非常感謝. 什么是PSR? ? ??? PSR是...
摘要:被稱為的編程語言。然而,和其他語言一樣,需要遵循良好的代碼規范。編碼風格項目應當有統一的風格。安全開發者應該對常見的安全漏洞包括跨站腳本攻擊跨站請求偽造代碼注入漏洞和字符編碼漏洞有所了解。 PHP被稱為 quick and dirty 的編程語言。然而,PHP和其他語言一樣,需要遵循良好的代碼規范。以下是一些小建議。 showImg(http://segmentfault.com/i...
閱讀 817·2019-08-30 15:54
閱讀 445·2019-08-30 12:51
閱讀 2027·2019-08-29 16:28
閱讀 2847·2019-08-29 16:10
閱讀 2334·2019-08-29 14:21
閱讀 412·2019-08-29 14:09
閱讀 2135·2019-08-23 16:13
閱讀 1240·2019-08-23 13:59