代碼審查作為JBuilder
強大的新特性閃亮登場
直指編碼中的軟肋
力爭將編碼中的錯誤或隱患扼殺於萌芽態
強力提升開發人員的編碼質量
JBuilder
根據Sun的編碼規范及軟件開發界總結出的一套行之有效的編碼習慣
對Java開發中的編碼風格
聲明風格
Javadoc文檔注釋
EJB規范
命名風格
潛在錯誤
編碼中的畫蛇添足等諸多方面進行代碼審查並給出警示
以便開發人員發現這些不足和隱患予以及時更正
代碼審查和語法錯誤檢查是兩個不同層次的概念
語法錯誤是低層次
強制性的檢查
任何違反語法的程序都是無法通過編譯的
也就是說可運行的程序必須是語法正確的
而代碼審查是高級別
非強制性的檢查
它對語法正確的程序施加了更高更嚴格的要求
從而提升程序的可讀性
降低因變量命名
方法定義
程序邏輯的不完整性等問題而導致程序的潛在出錯機率
增加程序的可維護性和健壯性
林林總總的Java編程規范
編程范式以及編程經驗都致力於提升代碼質量
程序性能
軟件維護性等非語法方法的課題
JBuilder
代碼審查即是將各種行之有效的編程規范
范式
經驗施加於你的程序中
以使你的程序遵守這些業已被大量的實踐證明是成功的編程准則
JBuilder
在默認的情況下設置的代碼審查機制即是Sun的代碼編程規范
此外還提供了大量可供選擇的審查規則
你可以根據需要激活或關閉這些審查的規則
對於初學者來說
代碼審查無疑是學習和工作的良師益友
JBulder
通過即時的代碼審查達到了對開發人員
監督匡正
笃行扶弱
的作用
開發人員也可以通過代碼審查所反饋的問題
學習有關語法之外更多的編程要求和經驗
一使用代碼審查 在默認情況下
JBuilde
未激活代碼審查的功能
可以通過Project
>Project Properties
>Code Audits調用代碼審查的設置頁
二代碼風格審查 往往有些程序員熱衷於將Java的語法發揮到極致
以資其對Java語法精通的憑據
但在需要充分協作溝通的軟件項目中
簡潔明了
清晰易懂將會受到推崇
晦澀難懂的語句將會受到奚落
故大部分的軟件公司的規范都對語句的精簡明了提出了要求
JBuilder
代碼審查可以在一定程度上幫助公司落實和貫徹這一要求
三聲明審查 成員變量和局部變量的隱藏
常常會使開發人員張冠李戴
犯一些不經意的錯誤
而子類隱藏父類的成員和靜態變量常常是由於沒有注意到父類中已經具有相同的名字而引起的
由此而生產的程序Bug由於其隱身性強
是很難被發現
JBuilder
提供幾個對聲明進行審查的工具
四命名風格 良好的命名風格在遵守Java命名語法之上
對命名提出了更高的要求
良好的命名風格必須遵守Java的命名規則
五潛在錯誤審查 由於流程控制語句語法的特殊性
編寫程序時需要特別注意
否則將會埋下禍根
JBuilder從多個方面對這些語句進行審查
六規避各種畫蛇添足 JBuilder
代碼審查功能的強大還在於能夠判斷多余的import包引入
不必要的強制類型轉換
無用成員
多余的接口修飾符等
七其他 在程序中
由於種種原因存在無效表達式
或者程序永遠不能使用的程序段
對於這些無用的代碼
JBuilder
提供的代碼審查功能也能查出來
並提醒程序員
總結 JBuilder
提供了語法之上的代碼審查功能
使用好代碼審查功能不但可以增強程序代碼的簡潔性
可讀性
還可以盡早發現潛在的編碼錯誤
防患於未然
JBuilder
代碼審查功能無疑是一項開創性的工作
將對程序開發產生深遠的影響
也是智能開發工具的一個發展方向
使用Jbuilder
代碼審查
在默認情況下
JBuilde
未激活代碼審查的功能
可以通過Project
>Project Properties
>Code Audits調用代碼審查的設置頁
如圖
所示
educity
cn/img_
/
/
/
jpg>
圖代碼審查設置
勾選Code Audits設置頁中的
Enable Code Audits
激活當前工程的代碼審查功能
Code Audits設置頁的左邊是一棵代碼審查規則項的樹
分為兩級
第一級為審查規則項的歸類
點開第一級的節點
第二級的各節點為具體的一個規則項
可以根據需要勾選可取消這些審查的規則
點擊規則項
在Code Audits設置頁的右邊顯示出了該規則的詳細描述信息並提供了實例
方便開發人員學習和理解
在激活代碼審查規則後
JBuilder
實時地審查編輯器中當前編寫的程序文件
並在違反審查規則代碼附近的控制槽上標注
違反規則代碼的關鍵處將以一條粉紅色的下劃波浪線標識出來
此外在結構窗格的Warning文件夾下列出當前程序所有違反審查規則的代碼
如圖
所示
educity
cn/img_
/
/
/
jpg>
圖結構窗格中代碼審查結果匯總
審查結果項描述了代碼中存在的問題的簡要描述
通過這個提示和編譯器控制槽上的 標識
點選審查結果項時
編輯器中相應的代碼內容將以下劃虛線形式顯示
通過查看相應的代碼
開發人員將能夠快速發現問題所在
更正問題後
對應的審查警告將自動從Warning文件夾中清除
代碼風格審查
switch
必須帶一個default語句
根據Sun的編碼規范
每個switch流程控制語句都必須帶一個default分支
以保證邏輯分支的完整性
在默認情況下該審查項未激活
對應的設置項是
Coding Style
下的
switch
Statement Should Include a Default Case
代碼清單
所有switch必須帶default分支
switch (formatType)
{
case
:
formatStr =
yyyyMMddHHmmss
;
break;
case
:
formatStr =
yyyy
MM
dd HH:mm:ss
;
break;
case
:
formatStr =
yyyy
MM
dd HH:mm:ss
;
break;
case
:
formatStr =
yyyy
年
MM
月
dd HH:mm:ss
;
break;
default:
formatStr =
yyyy
MM
dd HH:mm:ss
;
}
如果沒有第
~
行的default代碼
代碼審查將給出警告
提示
可以通過Ctrl+J 調用switch代碼模板錄入的switch流程控制語句代碼塊將帶一個default分支
這樣
不但加速了編碼的錄入效率還保證了代碼塊的規范性
應通過類名引用靜態成員
類中所有的靜態方法或變量都應該通過類名來引用
如果通過類的實例來引用這些靜態的成員將影響到程序的可讀性
如果通過類名來引用靜態變量
將容易分辨出這些成員的靜態屬性
因為類靜態成員變量在JVM中僅存在一份
而非每個對象實例各自一份
因此靜態成員變量可以看成類的成員
代碼清單
關於靜態成員的引用
public class ASMO
{
void func()
{
ASMO
obj
= new ASMO
();
ASMO
obj
= new ASMO
();
obj
attr =
; //應更正為ASMO
attr
obj
attr =
; //應更正為ASMO
attr
obj
oper(); //應更正為ASMO
oper();
obj
oper(); //應更正為ASMO
oper();
this
attr++; //應更正為ASMO
attr++;
this
oper(); //應更正為ASMO
oper();
}
static int attr;
static void oper()
{}
}
class ASMO
{
static int attr;
static void oper()
{}
}
該審查規則對應的設置項是
Coding Style
下的
Accessing Static Members by the Descendant Class Name
避免復雜晦澀代碼
往往有些程序員熱衷於將Java的語法發揮到極致
以資其對Java語法精通的憑據
如果是為了練習語法
理解語法
無可厚非
但如果在需要充分協作溝通的軟件項目中
簡潔明了
清晰易懂將會受到推崇
晦澀難懂的語句將會受到奚落
故此
大部分的軟件公司的規范都對語句的精簡明了提出了要求
JBuilder
代碼審查可以在一定程度上幫助公司落實和貫徹這一要求
代碼清單
演示了晦澀的賦值語句及替代的寫法
代碼清單
復雜晦澀的賦值語句
int i =
;
int j =
;
int k =
;
int l =
;
i *= ++j;
//應更改為
//++j;
//i *= j;
k = j =
;
//應更改為
//k =
;
//j =
;
l = j +=
;
//應更改為
//j +=
;
//l = j;
i = j++ +
;
//應更改為
//i = j +
;
//j++;
i = (j =
) +
;
//應更改為
//j =
;
//i = j +
;
i = j++ +
;
//應更改為
//i = j +
;
//j++;
i = (j =
) +
;
//應更改為
//j =
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26373.html