我本人不太推薦制定過細的編碼規範。制定編碼規範是為了增強**的可讀性，畢竟**的結構才是主要關注問題，所以我的編碼規範還是比較簡短的。裡面只是對可能會破壞編碼風格的行為進行約束，而沒有細化到「空行」甚至「空格」的級別。
一 命名空間
《公司名稱》.(《產品名稱》|《相關技術》)[.《用途》] [.《子命名空間》]
二 **風格
三 命名規範
（一） 類、結構和介面的命名
基類派生類
system.attribute
要給自定義的特性新增「attribute」字尾
system.delegate
要給用於事件處理的委託新增「eventhandler」字尾 要給用於事件處理之外的那些委託新增「callback」字尾
不要給委託新增「delegate」字尾
system.eventargs
要新增「eventargs」字尾
system.exception
要新增「exception」字尾
idictionary，idictionary
要新增「dictionary」字尾
ienumerable，icollection，ilist， ienumerable，icollection，ilist
新增「collection」字尾
system.io.stream
新增「stream」字尾
codeaccesspermission，ipermission
新增「permission」字尾
（二） 成員的命名
成員大小寫
規範方法
pascal（公開）、camel（私有）
用動詞或動詞短語命名
屬性pascal
用名詞、名詞短語或形容詞來命名 集合屬性應該使用複數形式，而不是新增字尾
用「is」、「can」、「has」等表示布林屬性
可以用屬性的型別名來命名屬性
事件pascal
使用動詞或動詞短語來命名事件 用現在時和過去時來區分前置和後置事件
欄位camel（私有）
要用名詞、名詞短語或形容詞來命名 不要加任何字首
（三） 引數的命名
（四） 常量、變數的命名
（五） 列舉的命名
（六） 資源的命名
（七） 資料庫命名
（八） xml命名
節點名稱使用pascal風格，屬性名稱使用camel風格。
四 注釋
五 異常處理
vue參考 eslink編碼規範檢查
eslint 是乙個 規範檢查工具，它定義了很多特定的規則,一旦你的 違背了某一規則,eslint 會作出非常有用的提示直接仔細看控制台的報錯，如果沒看懂，可以去錯誤對應的鏈結頁面eslink中有非常多的規範，報錯位置會提示你錯誤規範的名稱，直接用鏈結開啟頁面可以檢視詳細的去.eslintrc.js...
php 編碼規範哪些 php編碼規範
1.php 必須以完整的形式來定界 即不要使用php 短標籤 且保證在關閉標籤後不要有任何空格。2.當乙個字串是純文字組成的時候 即不含有變數 則必須總是以單引號 作為定界符。例如 a example string 3.變數替換中的變數只允許用 變數名 的形式。例如 greeting hello n...
php 編碼規範哪些 PHP編碼規範
很多初學者對編碼規範不以為然，認為對程式開發沒有什麼幫助，甚至因為要遵循規範而影響了學習和開發的進度。或者因為經過一段時間的使用，已經形成了自己的一套風格，所以不願意去改變。這種想法是很危險的。如今的 web 開發，不再是乙個人就可以全部完成的，尤其是一些大型的專案，往往需要十幾人，甚至幾十人來共同...