代碼當量

代碼當量也即是開發當量（英文名為ELOC，Equivalent Line of Code，），由思碼逸原創，是一種對開發者代碼工作量進行合理量化和度量的指標，於2018年上線。

基本介紹

• 中文名：代碼當量
• 外文名：Equivalent Line of Code
• 別名：開發當量
• 提出人：思碼逸 
• 上線時間：2018年 

簡介

與代碼行數、提交數等淺層工作量指標相比，代碼當量（開發當量）的優勢體現在兩個方面：不易受到編程習慣或特定代碼行為的干擾（如換行、空行、注釋、括弧等），且能更好地反映代碼開發所涉及的邏輯量。

CTO殷和政與任晶磊合撰的技術原型論文《關於量化代碼貢獻的開發價值》針對程式分析和機器學習的模組進行研究，在國際軟體工程會議FSE (International Symposium on the Foundations of Software Engineering) 2018上發表

2018年12月，思碼逸CTO在伯克利發表《Quantifying the Development Value of CodeContribution》

功能特點

代碼行數是簡單且常用的衡量代碼工作量的指標。但是它的缺點很明顯，例如：容易受到代碼風格、換行習慣、注釋、格式化操作等的干擾；無法識別出對代碼的實際修改，簡單的複製貼上、移動代碼塊等會產生大量的行數增刪變化。

代碼當量很好地解決了這些問題。它將原始碼解析成抽象語法樹這種更能體現代碼語法結構、代碼本質的形式，通過比較代碼修改前後抽象語法樹之間的變化，來計算一次修改行為的工作量。

首先，代碼被解析為抽象語法樹後，消除了代碼書寫風格、注釋格式等與代碼邏輯無關因素的干擾。其次，基於樹結構的比較，能很好地識別移動代碼（Move）、更新代碼（Update）等操作，為它們賦予更合理的工作量。同時，在抽象語法樹的基礎上，代碼當量能通過簡單的語義分析，區分代碼中的“數據”和“邏輯”，弱化非關鍵的“數據”修改，強化“邏輯”修改。更進一步地，代碼當量還有很多智慧型調節機制來處理實際開發中常見的場景，例如對重複代碼的調節、排除由開發工具自動生成的代碼、排除第三方庫的代碼、平衡不同程式語言之間的差異等。

產品服務

計算過程

代碼當量的基礎計算過程如下：

1.分別將修改前的代碼和修改後的代碼解析為抽象語法樹（AST）。

•使用tree diff算法計算將修改前的AST轉換成修改後的AST的編輯腳本（Edit Script）。編輯腳本里包括四種對樹的編輯操作：插入、刪除、移動、更新。

•對於被編輯的抽象語法樹節點，根據它的節點類型和編輯操作類型，分別進行加權計算。

•最後，對所有被編輯的節點的加權結果進行求和，即為這次修改的代碼當量。

算法圖示

從代碼的修改計算出代碼當量的數值：

如何計算代碼當量

實例對比

例1

代碼行數很容易因為簡單的修改而顯著增加。比如下面的代碼變動，儘管代碼修改後本質並沒有發生變化，這個修改仍會產生1行添加和4行刪除。

而單純的格式變化對AST沒有影響，此段代碼修改前後AST是相同的，因此其代碼當量為0。

例1

例2

代碼行數不擅長檢測代碼塊的移動。比如下面的代碼變動，簡單地交換類中函式的順序會產生4行添加和4行刪除。

但是從抽象語法樹的角度，這次修改只是改變了myMethod( )函式對應節點在其父節點下的順序，該節點本身未發生任何修改。因此修改myMethod( )的代碼當量為0。

例2

例3

代碼行數無法區分不同性質的代碼的工作量。考察以下Python代碼，它的功能是在給定的字典中找到對稱對。測試數據test_dict和實際功能函式find_sym_pairs( )貢獻了相等數量的行數（7行），這當然不能反映編寫這兩段代碼所付出的不同的工作量。

但是通過為每個AST節點類型分配不同的權重，可以對不同類型AST節點的編輯操作進行更合理的評估，更合理的量化開發過程中的工作量。

例3