來源:http://www.cnblogs.com/janas/archive/2013/08/20/3271408.html

Discuz中的編碼規范很值得PHP開發人員借鑒。里面既介紹了編碼時代碼標記，注釋，書寫規則，命名原則等方面基礎的內容，對代碼的安全性，性能，兼容性，代碼重用，數據庫設計，數據庫性能及優化作了闡述，這個是開發人員必須掌握的技巧。同時也對模板的規范進行了介紹。

?

以下是對其編碼規范的引用，編碼規范地址：http://open.discuz.net/?ac=document&page=dev_coderule

?

Discuz! 的編碼規范

目錄 1?前言 2?適用范圍 3?標準化的重要性和好處 4?PHP編碼規范與原則 4.1?代碼標記 4.2?注釋 4.3?書寫規則 4.3.1?縮進 4.3.2?大括號{}、if和switch 4.3.3?運算符、小括號、空格、關鍵詞和函數 4.3.4?函數定義 4.3.5?引號 4.3.6?Discuz!語言問題 4.4?命名原則 4.4.1?變量、對象、函數名 4.4.2?常量 4.5?變量的初始化與邏輯檢查 4.6?安全性 4.7?兼容性 4.8?代碼重用 4.9?其他細節問題 4.9.1?包含調用 4.9.2?錯誤報告級別 5?數據庫設計 5.1?字段 5.1.1?表和字段命名 5.1.2?字段結構 5.2?SQL語句 5.3?性能與效率 5.3.1?定長與變長表 5.3.2?運算與檢索 5.3.3?結構優化與索引優化 5.3.4?查詢優化 5.3.5?兼容性問題 6?模板設計 6.1?代碼標記 6.2?書寫規則 6.2.1?HTML 6.2.2?變量 6.2.3?語言元素 6.2.4?縮進 7?文件與目錄 7.1?文件命名 7.2?目錄命名 7.3?空目錄索引

前言

本規范由編程原則組成，融合并提煉了開發人員長時間積累下來的成熟經驗，意在幫助形成良好一致的編程風格。

適用范圍

如無特殊說明，以下規則要求完全適用于Discuz!項目，同時也可大部分適用于COMSENZ旗下其他PHP項目。

標準化的重要性和好處

當一個軟件項目嘗試著遵守公共一致的標準時，可以使參與項目的開發人員更容易了解項目中的代碼、弄清程序的狀況。使新的參與者可以很快的適應環境，防止部分參與者出于節省時間的需要，自創一套風格并養成終生的習慣，導致其它人在閱讀時浪費過多的時間和精力。而且在一致的環境下，也可以減少編碼出錯的機會。缺陷是由于每個人的標準不同，所以需要一段時間來適應和改變自己的編碼風格，暫時性的降底了工作效率。從使項目長遠健康的發展以及后期更高的團隊工作效率來考慮暫時的工作效率降低是值得的，也是必須要經過的一個過程。標準不是項目成功的關鍵，但可以幫助我們在團隊協作中有更高的效率并且更加順利的完成既定的任務。

• 程序員可以了解任何代碼，弄清程序的狀況
• 新人可以很快的適應環境
• 防止新接觸PHP的人出于節省時間的需要，自創一套風格并養成終生的習慣
• 防止新接觸PHP的人一次次的犯同樣的錯誤
• 在一致的環境下，人們可以減少犯錯的機會
• 程序員們有了一致的敵人

PHP編碼規范與原則

代碼標記

PHP程序可以使用<?php??>來界定 PHP 代碼，在HTML頁面中嵌入純變量時，可以使用<?php echo $variablename;?>這樣的形式。

注意：為了使代碼進一步規范化和標準化，從Discuz! X2版本起開始禁用<???>和<?=$variablename?>這種速記形式。

注釋

注釋是對于那些容易忘記作用的代碼添加簡短的介紹性內容。請使用 C 樣式的注釋“/* */”和標準 C++ 注釋“//”。

在Discuz!每一個程序文件頭部中，應放入相應SVN控制字串，以方便SVN提交時自動更新：

• IdId

例如：

/*** [Discuz!] (C)2001-2099 Comsenz Inc.* This is NOT a freeware, use is subject to license terms** $Id$*/

程序開發中難免留下一些臨時代碼和調試代碼，此類代碼必須添加注釋，以免日后遺忘。所有臨時性、調試性、試驗性的代碼，必須添加統一的注釋標記“//debug”并后跟完整的注釋信息，這樣可以方便在程序發布和最終調試前批量檢查程序中是否還存在有疑問的代碼。例如：

$num = 1; $flag = TRUE; //debug 這里不能確定是否需要對$flag進行賦值 if(empty($flag)) {//Statements }

書寫規則

縮進

每個縮進的單位約定是一個TAB(4個空白字符寬度)，需每個參與項目的開發人員在編輯器(UltraEdit、EditPlus、Zend Studio等)中進行強制設定，以防在編寫代碼時遺忘而造成格式上的不規范。

本縮進規范適用于PHP、JavaScript中的函數、類、邏輯結構、循環等。

大括號{}、if和switch

• 首括號與關鍵詞同行，尾括號與關鍵字同列；
• if結構中，else和elseif與前后兩個大括號同行，左右各一個空格。另外，即便if后只有一行語句，仍然需要加入大括號，以保證結構清晰；
• switch結構中，通常當一個case塊處理后，將跳過之后的case塊處理，因此大多數情況下需要添加break。break的位置視程序邏輯，與case同在一行，或新起一行均可，但同一switch體中，break的位置格式應當保持一致。

以下是符合上述規范的例子：

if($condition) {switch($var) {case 1: echo ‘var is 1’; break;case 2: echo ‘var is 2’; break;default: echo ‘var is neither 1 or 2’; break;} } else {switch($str) {case ‘abc’:$result = ‘abc’;break;default:$result = ‘unknown’;break;} }

運算符、小括號、空格、關鍵詞和函數

• 每個運算符與兩邊參與運算的值或表達式中間要有一個空格，唯一的特例是字符連接運算符號兩邊不加空格；
• 左括號“(” 應和函數關鍵詞緊貼在一起，除此以外應當使用空格將“(”同前面內容分開；
• 右括號“)”除后面是“)”或者“.”以外，其他一律用空格隔開它們；
• 除字符串中特意需要，一般情況下，在程序以及HTML中不出現兩個連續的空格；
• 任何情況下，PHP程序中不能出現空白的帶有TAB或空格的行，即：這類空白行應當不包含任何TAB或空格。同時，任何程序行尾也不能出現多余的TAB或空格。多數編輯器具有自動去除行尾空格的功能，如果習慣養成不好，可臨時使用它，避免多余空格產生；
• 每段較大的程序體，上、下應當加入空白行，兩個程序塊之間只使用1個空行，禁止使用多行。
• 程序塊劃分盡量合理，過大或者過小的分割都會影響他人對代碼的閱讀和理解。一般可以以較大函數定義、邏輯結構、功能結構來進行劃分。少于15行的程序塊，可不加上下空白行；
• 說明或顯示部分中，內容如含有中文、數字、英文單詞混雜，應當在數字或者英文單詞的前后加入空格。

根據上述原則，以下舉例說明正確的書寫格式：

$result = (($a + 1) * 3 / 2 + $num)).’Test’; $condition?? func1($var)?: func2($var); $condition?? $long_statement?: $another_long_statement; if($flag) {//Statements//More than 15 lines} showmessage(‘請使用 restore.php 工具恢復數據。’);

函數定義

• 參數的名字和變量的命名規范一致；
• 函數定義中的左小括號，與函數名緊挨，中間無需空格；
• 開始的左大括號與函數定義為同一行，中間加一個空格，不要另起一行；
• 具有默認值的參數應該位于參數列表的后面；
• 函數調用與定義的時候參數與參數之間加入一個空格；
• 必須仔細檢查并切實杜絕函數起始縮進位置與結束縮進位置不同的現象；

例如，符合標準的定義：

function authcode($string, $operation, $key = '') {if($flag) {//Statement}//函數體 }

不符合標準的定義：

function authcode($string,$operation,$key = '') {//函數體 }

引號

PHP中單引號和雙引號具有不同的含義，最大的幾項區別如下：

• 單引號中，任何變量($var)、特殊轉義字符(如“\t \r \n”等)不會被解析，因此PHP的解析速度更快，轉義字符僅僅支持“\’”和“\\”這樣對單引號和反斜杠本身的轉義；
• 雙引號中，變量(var)值會代入字符串中，特殊轉義字符也會被解析成特定的單個字符，還有一些專門針對上述兩項特性的特殊功能性轉義，例如“\$”和“{var)值會代入字符串中，特殊轉義字符也會被解析成特定的單個字符，還有一些專門針對上述兩項特性的特殊功能性轉義，例如“\$”和“{array[‘key’]}。這樣雖然程序編寫更加方便，但同時PHP的解析也很慢；
• 數組中，如果下標不是整型，而是字符串類型，請務必用單引號將下標括起，正確的寫法為array[‘key′]，而不是array[‘key′]，而不是array[key]，因為不正確的寫法會使PHP解析器認為key是一個常量，進而先判斷常量是否存在，不存在時才以“key”作為下標帶入表達式中，同時出發錯誤事件，產生一條Notice級錯誤。
• 因此，在絕大多數可以使用單引號的場合，禁止使用雙引號。依據上述分析，可以或必須使用單引號的情況包括但不限于下述：
  • 字符串為固定值，不包含“\t”等特殊轉義字符；
  • 數組的固定下標，例如$array[‘key’]；
  • 表達式中不需要帶入變量，例如string=‘test′;，而非string=‘test′;，而非string = “test$var”；
• 例外的，在正則表達式(用于preg_系列函數和ereg系列函數)中，Discuz!全部使用雙引號，這是為了人工分析和編寫的方便，并保持正則表達式的統一，減少不必要的分析混淆。
• 數據庫SQL語句中，所有數據必須加單引號，無論數值還是字串，以避免可能的注入漏洞和SQL錯誤。正確的寫法為：

UPDATE cdb_members SET adminid=’1’ WHERE username=’$admin’ AND adminid=’2’;

所有數據在插入數據庫之前，均需要進行addslashes()處理，以免特殊字符未經轉義在插入數據庫的時候出現錯誤。Discuz!中所有通過 GET, POST, FILE,取得的變量默認情況下已經使用了addslashes()進行了轉義，不必重復進行。如果數據處理必要(例如用于直接顯示)，可以使用 stripslashes() 恢復，但數據在插入數據庫之前必須再次進行轉義。緩存文件中，一般對緩存數據的值采用 addcslashes($string, '\'\\')進行轉義。

Discuz!語言問題

在功能設計階段，當需要使用中文或者給出用戶中文提示的時候可以直接在程序中插入簡體中文文字，待程序整理和測試階段由專人進行語言分離工作；

功能說明性語言、短語一般不使用“。”或者其他標點符號作為結束，文字中的標點符號，應使用全角。但注意：由于中英文模板與語言包問題，功能說明性的語言中，冒號使用半角”:”，而不使用全角；

提示信息(用showmessage()和cpmsg()顯示的)和使用技巧(如后臺管理界面中的tips)等大篇幅文字中，當中的標點符號應當遵循中文語法規則，以使用全角中文標點為主，結尾應當加入全角句號。

盡管程序語言包是在最后整理階段才進行提取，但程序中直接寫出的中文內容，也應充分保證書面語的特征：語言通順、簡潔、得體、無歧義。應徹底杜絕認為直接寫提示語言是臨時性操作的想法，反復推敲，并總結之前提示語言的特征規范，加以應用。良好的語言文字表達能力，是每個優秀程序員必須具備的基本素質之一。

命名原則

命名是程序規劃的核心。古人相信只要知道一個人真正的名字就會獲得凌駕于那個人之上的不可思議的力量。只要你給事物想到正確的名字，就會給你以及后來的人帶來比代碼更強的力量。

名字就是事物在它所處的生態環境中一個長久而深遠的結果。總的來說，只有了解系統的程序員才能為系統取出最合適的名字。如果所有的命名都與其自然相適合，則關系清晰，含義可以推導得出，一般人的推想也能在意料之中。

就一般約定而言，類、函數和變量的名字應該總是能夠描述讓代碼閱讀者能夠容易的知道這些代碼的作用。形式越簡單、越有規則，就越容易讓人感知和理解。應該避免使用模棱兩可，晦澀不標準的命名。

?

變量、對象、函數名

• 變量、對象、函數名一律為小寫格式，除非必要，單詞之間一般不使用下劃線“_”進行分割；
• 以標準計算機英文為藍本，杜絕一切拼音、或拼音英文混雜的命名方式；
• 變量命名只能使用項目中有據可查的英文縮寫方式，例如可以使用data而不可使用data而不可使用data1、data2這樣容易產生混淆的形式，應當使用data2這樣容易產生混淆的形式，應當使用threaddata、$postdata這樣一目了然容易理解的形式；
• 可以合理的對過長的命名進行縮寫，例如bio(bio(biography)，tpp(tpp(threadsPerPage)，前提是英文中有這樣既有的縮寫形式，或字母符合英文縮寫規范；
• 必須清楚所使用英文單詞的詞性，在權限相關的范圍內，大多使用allow???或allow???或is***的形式，前者后面接動詞，后者后面接形容詞。

常量

• 常量應該總是全部使用大寫字母命名，少數特別必要的情況下，可使用劃線來分隔單詞；
• PHP 的內建值 TRUE、FALSE 和NULL必須全部采用大寫字母書寫。

變量的初始化與邏輯檢查

任何變量在進行累加、直接顯示或存儲前必需進行初使化,例如：

$number = 0; //數值型初始化 $string = ‘’; //字符串初始化 $array = array(); //數組初始化

• 判斷一個無法確定（不知道是否已被賦值）的變量時，可用empty()或isset()，而不要直接使用if($switch)的形式，除非你確切的知道此變量一定已經被初始化并賦值。

empty()和isset()的區別為：

• bool empty(mixed var)

如果 var 是非空或非零的值，則 empty() 返回 FALSE。換句話說，""、0、"0"、NULL、FALSE、array()、var $var; 以及沒有任何屬性的對象都將被認為是空的，如果 var 為空，則返回 TRUE。

• bool isset(mixed var[, mixed var[, ...]])

• 如果 var 存在則返回 TRUE，否則返回 FALSE。

• 如果已經使用 unset() 釋放了一個變量之后，它將不再是 isset()。若使用 isset() 測試一個被設置成 NULL 的變量，將返回 FALSE。同時要注意的是一個 NULL 字節（"\0"）并不等同于 PHP 的 NULL 常數。

• 判斷一個變量是否為數組，請使用is_array()，這種判斷尤其適用于對數組進行遍歷的操作，例如foreach()，因為如果不事先判斷，foreach()會對非數組類型的變量報錯；
• 判斷一個數組元素是否存在，可使用isset($array[‘key’])，也可使用empty()，兩者異同見上。

安全性

PHP中的變量不并不像C語言那樣需要事先聲明，解釋器會在第一次使用時自動創建他們，同樣類型也不需要指定，解釋器會根據上下文環境自動確定。從開發人員的角度來看，這無疑是一種極其方便的處理方法。一個變量被創建了，就可以在程序中的任何地方使用。這導致的結果就是開發人員工經常不注意初始化變量。因此，為了提高程序的安全性，我們不能相信任何沒有明確定義的變量。所有的變量在定義使用前要初使化以防止惡意構造提交的變量覆蓋程序中使用的變量。

兼容性

• 代碼設計應當兼顧PHP 高低版本的特性，當前，應仍然以PHP 4.0.6作為最低通過平臺，盡量不使用高版本PHP 新增的函數、常數或者常量。如果使用只在高版本才具備的函數，必須對其進行二次封裝，自動判斷當前PHP版本，并自行編寫低版本下的兼容代碼；
• 對于個別函數，參數要求或者代碼要求應當以較為嚴格的PHP版本為準；
• 除非必要，不要使用PHP擴展模塊中的函數。使用時應當加入必要的判斷，當服務器環境不支持此函數的時候，進行必要的處理。文檔和程序中的功能說明中，也應加上兼容性說明。

代碼重用

代碼的有效重用可以減少效率的損失與資源的浪費。在開發軟件項目時為了避免重復勞動和浪費時間。開發人員應盡量提高現有代碼的重用率，同時將更多的精力用在新技術的應用和新功能的創新開發上面。

• 在需要多次使用代碼，并且對于您希望實現的任務沒有可用的內置 PHP 函數時，不吝嗇定義函數或類。開發者須根據功能、調用情況，將函數和類放置于相應的function或class中。超過3行，實現相同功能的程序切勿在不同程序中多次出現，這是無法容忍和回避的問題；
• 在任何時候都不要出現同一個程序中出現兩段或更多的相似代碼或相同代碼，即便在不同程序中，也應盡力避免。開發者應當總是有能力找到避免代碼大段(超過10行)重復或類似的情況。

需要強調的是，本部分雖然篇幅較短，但卻是十分需要經驗，并將花費開發者大量時間和精力去進行優化的部分，任何產品開發者必須時刻清楚和理解代碼重用的重要性和必要性，切實在增強產品效率、邏輯性和可讀性上下功夫，這是一名優秀軟件開發者所必須具備的基本素質。

其他細節問題

包含調用

• 包含調用程序文件，請全部使用require_once，以避免可能的重復包含問題；
• 包含調用緩存文件，由于緩存文件無法保證100%正確打開，請使用include_once或include。在必要時，可以使用@include_once或@include的方式，以忽略錯誤提示；
• 包含和調用代碼中，須以“./”或DISCUZ_ROOT.’./’開頭，應避免直接寫程序文件名(例如：require_once ‘x.php’;)的做法；
• 所有被包含和調用的程序文件，包括但不限于程序、緩存或模板，通常其不能被直接URL請求。Discuz!通過在./source/class/class_core.php中定義一個標記性常量IN_DISCUZ，來判斷程序是否被合法調用。因此，在除了./source/class/class_core.php以外的任何一個被包含和調用的程序文件中，需要包含以下內容，以使得訪問者無法直接通過URL請求該文件：

if(!defined('IN_DISCUZ')) {exit('Access Denied'); }

錯誤報告級別

• 在軟件開發和調試階段，請使用error_reporting(E_ALL);作為默認的錯誤報告級別，此級別最為嚴格，能夠報告程序中所有的錯誤、警告和提示信息，以幫助開發者檢查和核對代碼，避免大多數安全性問題和邏輯錯誤、拼寫錯誤。error_reporting()可以在config/config_global.php中添加一行$_config['debug'] = 1;debug值可以在0~2之前取值，數值越大報錯等級越高。
• 在軟件發布時，請使用error_reporting(E_ERROR | E_WARNING | E_PARSE);作為默認的錯誤報告級別，以利于用戶使用并將無謂錯誤提示信息降至最低。

數據庫設計

字段

表和字段命名

表和字段的命名以前面《4.4命名原則》的約定為基本準則。

所有數據表名稱，只要其名稱是可數名詞，則必須以復數方式命名，例如：cdb_members(用戶表)、cdb_posts(帖子表)；存儲多項內容的字段，或代表數量的字段，也應當以復數方式命名，例如：params(parameters，自定義Discuz!代碼的參數個數)、views(查看次數)、replies(回復次數)。

當幾個表間的字段有關連時，要注意表與表之間關聯字段命名的統一，如cdb_threads表中的tid與cdb_posts表中的tid。

代表id自增量的字段，通常用以下幾種形式：

• 最常用的核心id，或經常在URL中進行調用的，盡量用簡寫的形式，例如tid、pid、uid；
• 有功能性作用，URL中偶爾用到的id，使用全稱的形式，例如pluginid；
• 沒有功能性作用，只為管理和維護方便而設的id，可以使用全稱的形式，也可只將其命名為id。

所有與表、字段相關的命名，請務必大量參考Discuz!現有字段的命名方式，以保證命名的系統性和統一性。

字段結構

• 允許NULL值的字段，數據庫在進行比較操作時，會先判斷其是否為NULL，非NULL時才進行值的必對。因此基于效率的考慮，所有字段均不能為空，即全部NOT NULL；
• 預計不會存儲非負數的字段，例如各項id、發帖數等，必須設置為UNSIGNED類型。UNSIGNED類型比非UNSIGNED類型所能存儲的正整數范圍大一倍，因此能獲得更大的數值存儲空間；
• 存儲開關、選項數據的字段，通常使用tinyint(1)非UNSIGNED類型，少數情況也可能使用enum()結果集的方式。tinyint作為開關字段時，通常1為打開；0為關閉；-1為特殊數據，例如N/A(不可用)；高于1的為特殊結果或開關二進制數組合(詳見Discuz!中相關代碼)；
• MEMORY/HEAP類型的表中，要尤其注意規劃節約使用存儲空間，這將節約更多內存。例如cdb_sessions表中，就將IP地址的存儲拆分為4個tinyint(3) UNSIGNED類型的字段，而沒有采用char(15)的方式；
• 任何類型的數據表，字段空間應當本著足夠用，不浪費的原則，數值類型的字段取值范圍見下表：

字段類型	存儲空間(b)	UNSIGNED	取值范圍
tinyint	1	否	-128~127
		是	0~255
smallint	2	否	-32768~32767
		是	0~65535
mediumint	3	否	-8388608~8388607
		是	0~16777215
int	4	否	-2147483648~2147483647
		是	0~4294967295
bigint	8	否	-9223372036854775808~9223372036854775807
		是	0~18446744073709551615

SQL語句

• 所有SQL語句中，除了表名、字段名稱以外，全部語句和函數均需大寫，應當杜絕小寫方式或大小寫混雜的寫法。例如select * from cdb_members;是不符合規范的寫法。
• 很長的SQL語句應當有適當的斷行，依據JOIN、FROM、ORDER BY等關鍵字進行界定。
• 通常情況下，在對多表進行操作時，要根據不同表名稱，對每個表指定一個1~2個字母的縮寫，以利于語句簡潔和可讀性。

如下的語句范例，是符合規范的：

$query = $db->query("SELECT s.*, m.* FROM {$tablepre}sessions s, {$tablepre}members m WHERE m.uid=s.uid AND s.sid='$sid');

性能與效率

定長與變長表

包含任何varchar、text等變長字段的數據表，即為變長表，反之則為定長表。

• 對于變長表，由于記錄大小不同，在其上進行許多刪除和更改將會使表中的碎片更多。需要定期運行OPTIMIZE TABLE以保持性能。而定長表就沒有這個問題；
• 如果表中有可變長的字段，將它們轉換為定長字段能夠改進性能，因為定長記錄易于處理。但在試圖這樣做之前，應該考慮下列問題：
• 使用定長列涉及某種折衷。它們更快，但占用的空間更多。char(n) 類型列的每個值總要占用n 個字節(即使空串也是如此)，因為在表中存儲時，值的長度不夠將在右邊補空格；
• 而varchar(n)類型的列所占空間較少，因為只給它們分配存儲每個值所需要的空間，每個值再加一個字節用于記錄其長度。因此，如果在char和varchar類型之間進行選擇，需要對時間與空間作出折衷；
• 變長表到定長表的轉換，不能只轉換一個可變長字段，必須對它們全部進行轉換。而且必須使用一個ALTER TABLE語句同時全部轉換，否則轉換將不起作用；
• 有時不能使用定長類型，即使想這樣做也不行。例如對于比255字符更長的串，沒有定長類型；
• 在設計表結構時如果能夠使用定長數據類型盡量用定長的，因為定長表的查詢、檢索、更新速度都很快。必要時可以把部分關鍵的、承擔頻繁訪問的表拆分，例如定長數據一個表，非定長數據一個表。例如Discuz!的cdb_members和cdb_memberfields表、cdb_forums和cdb_forumfields表等。因此規劃數據結構時需要進行全局考慮；

進行表結構設計時，應當做到恰到好處，反復推敲，從而實現最優的數據存儲體系。

運算與檢索

• 數值運算一般比字符串運算更快。例如比較運算，可在單一運算中對數進行比較。而串運算涉及幾個逐字節的比較，如果串更長的話，這種比較還要多。
• 如果串列的值數目有限，應該利用普通整型或emum類型來獲得數值運算的優越性。
• 更小的字段類型永遠比更大的字段類型處理要快得多。對于字符串，其處理時間與串長度直接相關。一般情況下，較小的表處理更快。對于定長表，應該選擇最小的類型，只要能存儲所需范圍的值即可。例如，如果mediumint夠用，就不要選擇bigint。對于可變長類型，也仍然能夠節省空間。一個TEXT 類型的值用2 字節記錄值的長度，而一個LONGTEXT 則用4字節記錄其值的長度。如果存儲的值長度永遠不會超過64KB，使用TEXT 將使每個值節省2字節。

結構優化與索引優化

索引能加快查詢速度，而索引優化和查詢優化是相輔相成的，既可以依據查詢對索引進行優化，也可以依據現有索引對查詢進行優化，這取決于修改查詢或索引，哪個對現有產品架構和效率的影響最小。

索引優化與查詢優化是多年經驗積累的結晶，在此無法詳述，但仍然給出幾條最基本的準則。

首先，根據產品的實際運行和被訪問情況，找出哪些SQL語句是最常被執行的。最常被執行和最常出現在程序中是完全不同的概念。最常被執行的SQL語句，又可被劃分為對大表(數據條目多的)和對小表(數據條目少的)的操作。無論大表或小表，有可分為讀(SELECT)多、寫(UPDATE/INSERT)多或讀寫都多的操作。

對常被執行的SQL語句而言，對大表操作需要尤其注意：

• 寫操作多的，通常可使用寫入緩存的方法，先將需要寫或需要更新的數據緩存至文件或其他表，定期對大表進行批量寫操作，例如Discuz!中點擊數延遲更新機制，就是依據此原理實現。同時，應盡量使得常被讀寫的大表為定長類型，即便原本的結構中大表并非定長。大表定長化，可以通過改變數據存儲結構和數據讀取方式，將一個大表拆成一個讀寫多的定長表，和一個讀多寫少的變長表來實現；
• 讀操作多的，需要依據SQL查詢頻率設置專門針對高頻SQL語句的索引和聯合索引。

而小表就相對簡單，加入符合查詢要求的特定索引，通常效果比較明顯。同時，定長化小表也有益于效率和負載能力的提高。字段比較少的小定長表，甚至可以不需要索引。

其次，看SQL語句的條件和排序字段是否動態性很高(即根據不同功能開關或屬性，SQL查詢條件和排序字段的變化很大的情況)，動態性過高的SQL語句是無法通過索引進行優化的。惟一的辦法只有將數據緩存起來，定期更新，適用于結果對實效性要求不高的場合。

MySQL索引，常用的有PRIMARY KEY、INDEX、UNIQUE幾種，詳情請查閱MySQL文檔。通常，在單表數據值不重復的情況下，PRIMARY KEY和UNIQUE索引比INDEX更快，請酌情使用。

事實上，索引是將條件查詢、排序的讀操作資源消耗，分布到了寫操作中，索引越多，耗費磁盤空間越大，寫操作越慢。因此，索引決不能盲目添加。對字段索引與否，最根本的出發點，依次仍然是SQL語句執行的概率、表的大小和寫操作的頻繁程度。

查詢優化

MySQL中并沒有提供針對查詢條件的優化功能，因此需要開發者在程序中對查詢條件的先后順序人工進行優化。例如如下的SQL語句：

SELECT * FROM table WHERE a>’0’ AND b<’1’ ORDER BY c LIMIT 10;

事實上無論a>’0’還是b<’1’哪個條件在前，得到的結果都是一樣的，但查詢速度就大不相同，尤其在對大表進行操作時。

開發者需要牢記這個原則：最先出現的條件，一定是過濾和排除掉更多結果的條件；第二出現的次之；以此類推。因而，表中不同字段的值的分布，對查詢速度有著很大影響。而ORDER BY中的條件，只與索引有關，與條件順序無關。

除了條件順序優化以外，針對固定或相對固定的SQL查詢語句，還可以通過對索引結構進行優化，進而實現相當高的查詢速度。原則是：在大多數情況下，根據WHERE條件的先后順序和ORDER BY的排序字段的先后順序而建立的聯合索引，就是與這條SQL語句匹配的最優索引結構。盡管，事實的產品中不能只考慮一條SQL語句，也不能不考慮空間占用而建立太多的索引。

同樣以上面的SQL語句為例，最優的當table表的記錄達到百萬甚至千萬級后，可以明顯的看到索引優化帶來的速度提升。

依據上面條件優化和索引優化的兩個原則，當table表的值為如下方案時，可以得出最優的條件順序方案：

字段a	字段b	字段c
1	7	11
2	8	10
3	9	13
最優條件：b<’1’ AND a>’0’ 最優索引：INDEX abc (b, a, c) 原因：b<’1’作為第一條件可以先過濾掉75%的結果。如果以a>’0’作為第一條件，則只能先過濾掉25%的結果 注意： 字段c由于未出現于條件中，故條件順序優化與其無關 最優索引由最優條件順序得來，而非由例子中的SQL語句得來 索引并非修改數據存儲的物理順序，而是通過對應特定偏移量的物理數據而實現的虛擬指針

EXPLAIN語句是檢測索引和查詢能否良好匹配的簡便方法。在phpMyAdmin或其他MySQL客戶端中運行EXPLAIN+查詢語句，例如EXPLAIN SELECT * FROM table WHERE a>’0’ AND b<’1’ ORDER BY c;這種形式，即使得開發者無需模擬上百萬條數據，也可以驗證索引是否合理，相關細節請參考MySQL說明。

值得提出的是，Using filesort是最不應當出現的情況，如果EXPLAIN得出此結果，說明數據庫為這個查詢專門建立了一個用以緩存結果的臨時表文件，并在查詢結束后刪除。眾所周知，硬盤I/O速度始終是計算機存儲的瓶頸，因此，查詢中應當盡全力避免高執行頻率的SQL語句使用filesort。盡管，開發者永遠都不可能保證產品中的全部SQL語句都不會使用filesort。

限于篇幅，本文檔遠遠沒有涵蓋數據庫優化的方方面面，例如：聯合索引與普通索引的可重用性、JOIN連接的索引設計、MEMORY/HEAP表等。數據庫優化實際上就是在很多因素和利弊間不斷權衡、修改，惟有在成功與失敗經驗中反復推敲才能得出的經驗，這種經驗往往就是最難能可貴和價值連城的。

兼容性問題

• 由于MySQL 3.23至5.0的變化很大，因此程序中盡量不使用特殊的SQL語句，以免帶來兼容性問題，并給數據庫移植造成困難。
• 通常在MySQL 4.1以上版本，Discuz!應使用相當的字符集來存儲，例如GBK/BIG5/UTF-8。傳統的latin1編碼雖然有一定的兼容性，但仍然不是推薦的選擇。使用相應非默認字符集時，程序每次運行時需要使用SET NAMES ‘character_set’;來規定連接、傳輸和結果的字符集。
• Mysql 5.0以上新增了數種SQL_MODE，默認的SQL_MODE依服務器安裝設置不同而不同，因此程序每次運行時需要使用SET SQL_MODE=’’;來規定當前的SQL模式。

模板設計

代碼標記

HTML代碼標記一律采用小寫字母形式，杜絕任何使用大寫字母的方式

模板中所有的邏輯體，如{if}、{loop}等，必須前后使用HTML注釋()，即類似的形式。事實上，Discuz!模板編譯器是支持不加HTML注釋的邏輯體寫法的，但加入注釋可以使得模板可讀性更好，同時方便用戶使用DreamWeaver或FrontPage等對模板進行修改。

在HTML標記中使用的邏輯體無需使用HTML注釋()，即<input type=”text”{if xxx} value=”1”{/if} />

書寫規則

HTML

所有HTML標記參數賦值需使用雙引號包含，例如，應當使用<input type=”text” name=”test” value=”ok” />,而絕對不能使用<input type=text name=test value=ok />。

在任何情況下，產品中的模板文件必須采用手寫HTML代碼的方式，而絕對不能使用DreamWeaver、FrontPage等自動網頁制作工具進行撰寫或修改。

非成對標記必須以“/>”結尾，如
、<input …/>,<input /> 標記的屬性必須按照以下順序書寫：<input type="" name="" id="" class="" … />

變量

模板中使用的變量，依據作用和出現位置不同，分為幾種方式：

• 邏輯體中，即被包圍起來的部分，例如這種形式，其中的變量書寫規范與PHP程序中完全一致；
• 模板內容中，即未被包圍起來的部分，與PHP程序中最大的不同是，對數組字符串類型下標無需加入單引號，因為Discuz!模板編譯器會在對模板進行編譯時將這部分的單引號自動加入。

偶爾的，開發者需要使用{}將變量括起來，以免出現模板編譯錯誤，可能的情況如下：

• 變量前后含有中括號的或其他敏感字符的(包括但不限于“”、“’”等)，正確的寫法為descriptionnew[{”、“’”等)，正確的寫法為descriptionnew[{buddy[buddyid]}]；
• 數組的下標為變量的，正確的寫法為{extcredits[extcredits[creditstrans][title]}；
• 其他變量十分復雜的情況。

語言元素

Discuz!模板編譯器可以解析對應于./templates/default/templates.lang.php(以默認模板為例)的語言元素。在模板中調用相應語言元素的代碼為{lang item}，其中item為在templates.lang.php中定義的語言元素名。

縮進

在Discuz!的*.htm模板文件中，由于具備邏輯結構，故不考慮任何HTML本身的縮進，所有縮進均意為著邏輯上的縮進結構。縮進采用TAB方式，不使用空格作為縮進符號，僅需適當斷行即可。例如：

<!--{loop $threadlist $thread}--><table cellspacing=”0” cellspadding=”0” border=”0”><tr><td>$thread[message]</tr></td></table> <!--{/loop}-->

文件與目錄

文件命名

所有包含PHP代碼的程序文件或半程序文件，應以小寫.php作為擴展名，而不要使用.phtml、.php3、.inc、.class等作為擴展名。

普通程序

能夠被URL直接調用的程序，例如home.php、index.php、forum.php，直接使用程序名+.php的方式命名

函數庫和類庫程序

分別以小寫function_xxxx.php和class_xxxx.php的格式命名書寫。函數庫和類庫程序只能被其他程序引用，而不能獨立運行。其中不能包含任何流程性的、不屬于任何函數或類的程序代碼。

流程性程序

以小寫.inc.php作為擴展名。只能被其他程序引用，而不能獨立運行。其中不能包含任何函數或類代碼的程序代碼。

模板源文件

以小寫.htm作為擴展名。模板源文件按照Discuz!模板編碼規則進行編寫，不是可以執行的程序，而只能被Discuz!模板編譯器所解析，放置于./templates/default或./templates下的其他模板目錄下。

模板目標文件

模板文件被編譯后自動生成的目標程序，以小寫.tpl.php作為擴展名，存放于./data/template目錄下。

語言包文件

• 以小寫lang_xxxx.php格式命名，只能存放模板或程序使用的語言包信息。
• 模板語言包存放在對應模塊名下的lang_template.php，例如：家園的模板語言包source\language\home\lang_template.php

緩存文件

此類文件為系統自動生成，以cache_xxx.php、usergroup_xxx.php、style_xxx.php等類似形式命名，存放于./data/cache目錄下。

目錄命名

• Discuz!目錄命名以前面《4.4命名原則》的約定為基本準則。在可能的情況下，多以復數形式出現，如./templates、./images等。
• 由于目錄數量較少，因此目錄命名大多是一些習慣和約定俗成，開發人員如需新建目錄，應與項目組成員進行磋商，達成一致后方可實施。

空目錄索引

• 請在所有不包含普通程序(即能夠被URL直接調用的程序)的目錄中放置一個1字節的index.htm文件，內容為一個空格。幾乎除Discuz!根目錄以外，所有目錄都屬于這一類型，因此開發者需要在這些目錄全部放入空index.htm文件，以避免當http服務器的Directory Listing打開時，服務器文件被索引和列表。
• 附件目錄等敏感目錄，要在程序中實現相應功能，當新建下級目錄時，必須自動寫入一個空的index.htm文件，以避免新建目錄被索引的問題。

總結

以上是生活随笔為你收集整理的Discuz代码研究-编码规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。