您好,登錄后才能下訂單哦!
本篇內容主要講解“ABAP里的Code Inspector怎么使用”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“ABAP里的Code Inspector怎么使用”吧!
我們可以在ABAP Code Inspector的檢查變體(Check Variant)里,根據自己的需要靈活地選擇對ABAP代碼進行哪種類型的掃描動作。
下圖是一個例子,意思是對ABAP代碼中所有對數據庫表產生了讀寫訪問之處,進行"Table Names from SELECT Statements"的掃描。該掃描的具體行為,可以點擊藍底白色的感嘆號圖片,以獲得幫助文檔。下圖這個例子里勾取的選項,意思是檢查被訪問的數據庫表,在SE11的ABAP字段里的Technical Settings是否正確被維護了,比如表的緩存類型是否設置正確。
Select-Statement can be transformed. X% of fields used - 檢查內表字段的使用率
假設我們使用SELECT * 從一張表里讀取數據到ABAP內表,然后在后續(xù)代碼中只使用到了A個字段,而讀取的表在SE11里總共有B個字段,那么A除以B的結果越小,說明讀出來的內表字段使用率越低。
也就是說,你或許該考慮只SELECT真正需要的字段來替代SELECT *? 只需要在上圖設置里維護一個最低閥值,當Code Inspector掃描代碼時,一旦檢測到使用率低于維護的閥值就會報錯。上圖的20意思是20%.
Jerry 2007年剛加入SAP開始學習ABAP編程時,前輩們就告誡過我,不要在LOOP里使用SELECT語句,這樣會極大影響代碼的性能。
上圖是通過Code Inspector掃描出來的一個例子,在雙重LOOP循環(huán)里使用SELECT讀取數據庫表CRMD_DPP_HI_BLCK.
盡管當應用代碼里嵌套循環(huán)的循環(huán)次數不大時,對代碼運行的絕對時間沒有太大影響——然而編寫具有至少指數級時間復雜度的代碼,在任何上下文里都不是一個好的編程習慣。
這個設置能夠幫助我們快速找到所有的嵌套循環(huán)。
找出所有LOOP AT ... INTO之處,理論上這些地方都可以用LOOP AT ... REFERENCE INTO或者ASSIGNING <fs>替換。當內表的行結構體字段很多時,使用后兩種方式可以獲得一些性能的提升。
Low-Perform. Parameter Transfers - 檢測所有參數傳遞使用"Pass by Value"之處
Jerry關注了很多技術公眾號,發(fā)現參數傳遞的"傳引用"和"傳值"這兩種方式的辨析,至今仍然是很多互聯網公司的面試題之一。
這個選項可以讓您指定針對何種類型的參數進行參數傳遞方式的掃描:
在ABAP里理論上采用引用傳遞的方式進行參數傳遞,性能上總是優(yōu)于值傳遞,具體性能會提高多少,依賴于具體傳遞的參數類型,無法一概而論。
符合下列范式的動態(tài)SQL會被掃描出來:
Dynamic table accesses: SELECT * FROM (dbtab) WHERE …
Dynamic WHERE conditions: SELECT * FROM dbtab WHERE (where_cond)
Accesses to certain tables: SELECT * FROM dbtab WHERE …
Client-specific accesses: SELECT * FROM dbtab FROM WA … CLIENT SPECIFIED …
這個選項并不是禁止您使用動態(tài)SQL語句——事實上SAP應用的持久層里有大量的動態(tài)SQL語句的使用例子——而是提醒您別忘記了進行SQL注入的預防措施:一旦掃描出來,如果有用戶輸入參與了這些動態(tài)SQL語句的拼接,那就別忘記看看上下文有沒有使用CL_ABAP_DYN_PRG對用戶輸入進行處理。
檢測所有在有序內表上施加了APPEND操作的地方。有了這個掃描選項,能夠幫助您避免下圖第13行這種類型的運行時錯誤。
Jerry至今仍清楚地記得,十多年前上研究生課程《UNIX環(huán)境高級編程》時,老師不斷地強調在進行系統調用之后一定要檢查返回值并進行相應的錯誤處理。在Jerry看來,錯誤檢測和處理是每一位編程人員都應該具備的基本素養(yǎng)。
對應到ABAP里,就意味著每次調用ABAP的關鍵字完成某項操作后,都必須檢查sy-subrc的值來確認這次操作是否成功。
當然也可以根據項目的實際情況,告訴Code Inspector只檢查某些類型的ABAP關鍵字調用。比如上圖意思就是只檢查READ TABLE關鍵字調用后是否進行了sy-subrc的檢查。
在使用FOR ALL ENTRIES IN <itab>之前,必須先檢查內表itab是否為空。這個選項能掃描出沒有按照這個規(guī)范來編寫的代碼。
在這個界面里為ABAP里不同類型的變量設置好您團隊里達成一致的命名規(guī)范,然后Code Inspector就能把代碼里所有違反了這些命名規(guī)范的地方掃描出來。
這個檢查類別下面的設置都是一些很有意思的統計信息。
還是舉例說明。下圖紅色區(qū)域的設置,意思是如果一個類的方法內的可執(zhí)行語句行數超過150行,Code Inspector就報一條警告消息。這是為了避免大家寫出一個過于冗長的方法。
而藍色區(qū)域的設置是如果每100行可執(zhí)行代碼的對應注釋量小于10行,就報一條警告消息。這些閥值可以根據實際情況自行修改或關閉。
FAN-OUT Structural Metrics - 統計一個方法的扇出值
方法的扇入值和扇出值在模塊化編程的上下文會經常被提及,這對概念不是編程界首創(chuàng)的,而是源自半導體行業(yè)里的邏輯電路設計:
邏輯門的扇出系數定義了該門能夠驅動的數字信號輸入的最大量,而一個代碼模塊的扇出值則代表了其直屬下層的模塊個數。
這個選項能夠統計您方法的扇出系數。扇出系數太小,意味著該方法基本沒有調用其他下層的函數,這有兩種可能:
該方法的邏輯本身非常簡單,只有兩三行代碼,比如類的setter/getter方法;
這個方法的模塊化沒有做好,存在優(yōu)化的空間,比如某些直接寫在方法內的語句,可以提煉成下層函數并在方法內調用。
這個選項可以統計代碼中出現的德文注釋的函數。
Jerry不太明白該選項有什么用處,給非德國ABAP開發(fā)人員吐槽用的么?
這個選項也是為了防止您不經意間就創(chuàng)造出怪獸級的類(monster class)而生的:一旦您關注的類的屬性超過設置的閥值,比如類的成員,類的公/私有方法等關注點超過選項里設置的值時,Code Inspector就會報警。
這又是一個能幫助您寫出Clean ABAP code的強大工具。
什么是代碼的環(huán)復雜度?
根據維基百科的定義,我們把一段代碼的執(zhí)行流畫成一張有向無環(huán)圖,然后環(huán)復雜度可以通過下面的公式計算出來:
https://en.wikipedia.org/wiki/Cyclomatic_complexity
環(huán)復雜度 = 圖的邊數 - 圖的節(jié)點數 + 2
這其實就是我們研究生專業(yè)課《圖論》里學的歐拉定理。
看下面這個例子:
上面這8行ABAP代碼,環(huán)復雜度為3,怎么計算出來的?
先把其對應的有向無環(huán)圖畫出來:
這張圖的邊數為3,即圖中黑色,紅色和綠色三條粗線。
這張圖的頂點數為2,如圖中兩個菱形的藍色圖例所示。
最后環(huán)復雜度為3 – 2 + 2 = 3.
統計表明,代碼的高環(huán)復雜度和高故障率之間存在很強的正相關性,這不難理解,代碼的環(huán)復雜度越高,意味著里面嵌套的IF-ELSE,SWITCH等邏輯越多,無論是代碼原來的開發(fā)人員,還是后來接手的維護人員,讀起來都會覺得頭昏腦脹。
因此大家可以多用ABAP Code Inspector的這個掃描選項,隨時監(jiān)控您代碼的環(huán)復雜度。
把您關注的在代碼中出現的SQL操作關鍵字全部羅列出來。
這個選項也很有用,能根據您指定的正則表達式掃描ABAP代碼。
例如,您希望找出代碼里所有出現了READ TABLE XXX WITH KEY X = X的地方,只需要在上圖的輸入框里填入對應的正則表達式,即用*代表任意字符串:
READ TABLE * WITH KEY * = *
然后ABAP Code Inspector就會按照我們期望的行為去掃描代碼:
到此,相信大家對“ABAP里的Code Inspector怎么使用”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續(xù)學習!
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。