1. 【**強制**】類、類屬性、類方法的注釋必須/\*\* 內容 \*/格式，不得使用// xxx 方式
說明：在各種IDE中，可以設置各種文件模板，類注釋模板，方法注釋模板，可以提前設置一下，在書寫類，方法，函數的時候，會懸浮提示，點擊后自動生成各種注釋
正例
~~~
/**
* 行為管理控制器
* @package app\admin\controller
*/
class Action extends Base
{
/**
* 首頁
* @author ChenDasheng
* @created 2019/10/23
*/
public function index()
{
...
}
}
~~~
2. 【強制】所有注釋必須包含中文介紹，也就是說這個類或者方法，是干什么的；
3. 【強制】如果方法傳遞了參數，則要把每個參數的類型，以及參數的中文介紹寫上；
4. 【強制】方法必須帶返回類型，和作者，如果是非作者本人修改完善的，也要寫上；
5. 【**強制**】單行注釋可以使用 //， // 與注釋內容之間有且僅有一個空格，如果 // 前面有非空字符，則 // 前面需要加一個空格，多行注釋使用/\* \*/注釋，注意與代碼對齊；
6. 【推薦】代碼修改的同時，注釋也要進行相應的修改，尤其是參數、返回值、異常、核心邏輯等的修改
說明：代碼與注釋更新不同步，就像路網與導航軟件更新不同步一樣，如果導航軟件嚴重滯后，就失去了導航的意義。
7. 【參考】謹慎注釋掉代碼。在上方詳細說明，而不是簡單地注釋掉。如果無用，則刪除
說明：代碼被注釋掉有兩種可能性：1）后續會恢復此段代碼邏輯。2）永久不用。前者如果沒有備注信息，難以知曉注釋動機。后者建議直接刪掉（代碼倉庫保存了歷史代碼）。
8. 【參考】對于注釋的要求：第一、能夠準確反應設計思想和代碼邏輯；第二、能夠描述業務含義，使別的程序員能夠迅速了解到代碼背后的信息。完全沒有注釋的大段代碼對于閱讀者形同天書，注釋是給自己看的，即使隔很長時間，也能清晰理解當時的思路；注釋也是給繼任者看的，使其能夠快速接替自己的工作；
9. 【**參考**】好的命名、代碼結構是自解釋的，注釋力求精簡準確、表達到位。避免出現注釋的一個極端：過多過濫的注釋，代碼的邏輯一旦修改，修改注釋是相當大的負擔；
## 本規范示例
~~~
/**
* 編輯行為
* @param int $id 行為id
* @author ChenDasheng
* @created 2019/10/23
* @editor 潘陽
* @updated 2019.03.30 18:00
* @return mixed
*/
public function edit($id = 0)
{
/*
先判斷id是否有效
再進行其他操作
*/
if ($id === 0) {
return $this->error('缺少參數');
}
// 保存數據
if ($this->request->isPost()) {
...
}
}
~~~
注：本規范示例可參照代碼格式范例
