天天看點

開源工具abaplint的介紹

長期以來,SAP提供的标準ABAP開發工具是我們對代碼進行檢查的唯一方式。這意味着我們隻能對ABAP伺服器上的ABAP代碼做出分析,而離線代碼則成為了純粹的文本,開發者無法對其進行檢查。abaplint的出現改變了這一點,它可以在一定程度上“了解”代碼,幫助我們解決一些問題,和SAP的标準工具形成有效的互補。本文會介紹ABAP開發相關的工具abaplint以及它在開發過程中的應用。

本文連結:https://www.cnblogs.com/hhelibeb/p/12166288.html

原創内容,轉載請注明

基本介紹

lint或linter是一種靜态分析工具,可以分析并标記代碼中的錯誤、bug、可疑結構。 abaplint是ABAP語言的linter,它基于typescript,可以在多種平台工作,作者是Lars Hvam(同時也是abapGit的作者)。

項目位址:https://github.com/abaplint/abaplint

和Code Inspector等其它靜态分析工具類似,abaplint可以做到幫助我們找到有問題的代碼、確定統一的代碼風格等事情。

應用

在編輯器中的應用

以Visual Studio Code中的abaplint插件為例,它可以分析出代碼中的錯誤,如下圖,abaplint找出了短短一段代碼中的10個問題。

開源工具abaplint的介紹

滑鼠劃過報錯内容時,編輯器也會給出具體提示,如下圖,(上面的黑色主題的提示框邊界不是很明顯,為了讓讀者看清楚提示框,這裡主題顔色使用了Solarized Light)

開源工具abaplint的介紹

在持續內建(CI)中的應用

在編輯器中使用abaplint對代碼進行實時檢查是一種典型的應用方式,還有一種應用方式是通過abaplint對代碼進行自動檢查,它可以是持續內建中的一個場景。

比如,如果以Github作為代碼托管平台,可以安裝Github的abaplint應用(https://github.com/apps/abaplint),配置需要檢查的repo後,每當對相應的repo發起pr或push,都會有自動的代碼檢查,Github也會顯示檢查結果。(類似SAP系統中的傳輸前檢查CTS_REQUEST_CHECK)

下圖是我的配置,

開源工具abaplint的介紹

進行一次commit之後,可以看到abaplint給出了26處問題和問題所在的代碼位置。

開源工具abaplint的介紹

此外,也可以使用Travis CI或Gitlab的CI來執行abaplint的自動檢查。具體可以參考該文:《Automatic checking of your ABAP code in Github/Gitlab with CI and abaplint》

應用範圍

abaplint支援多種代碼編輯器和代碼托管平台,清單如下,

  • VS Code (source)
  • GitHub App
  • GitHub Actions
  • GitLab Pipelines
  • Bitbucket Pipelines
  • Azure Pipelines
  • Travis CI
  • Atom (待實作, source)
  • Code Climate Engine, 待實作
  • ABAP in Eclipse, (待實作, source)

配置

abaplint支援很多檢查規則(并且在持續地更新中),可以通過abaplint.json檔案來控制各個檢查規則的啟用與關閉、設定某些具體的檢查參數。

abaplint-clean-code項目中包含了這些規則的介紹,和配置檔案示例。第一次使用abaplint的使用者可以以該項目中的配置檔案示例作為模闆,按照自己的需要,結合規則介紹進行修改。

關于規則介紹部分,它不僅給出了規則的效果,也參考sap的style guides給出了規則存在的具體原因。

以其中一個設定為例,

"method_length": {
            "statements": 25,
            "ignoreTestClasses": false,
            "errorWhenEmpty": true,
            "reason": "https://github.com/SAP/styleguides/blob/master/clean-abap/CleanABAP.md#keep-methods-small"
        },      

method_length是方法長度的配置項;statements的數量決定了方法的最大行數;ignoreTestClasses,忽略測試類,

errorWhenEmpty,對不含代碼的空方法報錯;reason,該設定的原因。

(個人認為25有點小,有時候容易導緻淺子產品)

相關網站

abaplint項目下還有一些實用網站,這裡介紹幾個我了解的。

playground.abaplint.org

一個線上編輯器,包含一個可編輯的report程式和一個可編輯的配置檔案abaplint.json,可以通過它試驗abaplint的效果。

syntax.abaplint.org

一個ABAP的文法圖網站,如下,

開源工具abaplint的介紹

 如果你不了解文法圖,可以看這篇文章,或查找其它資料。

stats.abaplint.org

對一些開源項目的統計,包含項目的對象數量、檔案數量、語句數量、方法長度、語句相容性、對象類型、行數趨勢等資訊的統計。可以幫助開源開發者分析自己的項目。效果如下圖:

開源工具abaplint的介紹

abaplint的意義

abaplint目前的流行度似乎還不是很高(目前有62 star, 24 fork, 在abap标簽下分别排名第8和第10)。但我相信它是一個很有意義ABAP開源項目,未來可能會對ABAP的生态産生深遠影響。

ABAP開發者一直以來都在SAP ABAP伺服器上進行開發工作,代碼的分析、測試完全在ABAP伺服器上進行。複雜而笨重的SAP系統不是到處都有的,而且這些系統大多是孤立的。這意味着,開發内容的分享十分不友善。雖然理論上可以通過SAP系統工具對開發對象進行導入導出、代碼分析等工作,但在本質上,它們通常是為了一個組織内部的分享而存在的。當一個素不相識的人在github釋出了一個新的開源項目時,其它人無法得知這個項目曾經在ABAP伺服器上進行過怎樣的檢查,這會影響信任的建構。abaplint獨立實作了原本隻能在ABAP伺服器上進行的檢查,如果一個項目的每次commit包含abaplint的檢查結果,每個方法都有完整的單元測試,那麼人們對這個項目的信心将大大增加。信心的增加會促使人們将更多資源投入到開源項目中,進而促進社群的成長。

 參考:Running abaplint from SCI / ATC / ADT

繼續閱讀