代碼行數最多的 Python 項目是？

作者：YUHAO

總是看到有人說，動態一時爽，重構火葬場。

然而這世界上有的是著名的開源項目，

也有像 Github、Instagram 這樣流量巨大的知名網站是基於動態語言開發的，經過了這麼多年重構，也未聽說哪個作者進了火葬場的，不明白這些人是真的不知道還是裝作看不見呢？不過他們說動態語言大到一定程度就無法維護，雖然這話也同樣不值一駁，不過也提醒了我，我也很好奇用動態語言開發的專案規模能大到什麼程度。

從我知道的資訊看，

用動態語言開發的最大規模的專案可能要算是 OpenStack，據說代碼總量已經達到數百萬行，並且還在持續增加中。這當然是一個說明動態語言能力的好例子。不過像這樣巨大的項目，要分析起來也並不容易（好吧，真正的原因是我懶得下載那麼龐大的代碼庫）。我選擇了 Python 社區中比較知名的一些專案來分析，主要是來自 Github ，也有個別來自其他倉庫。這個選擇可能包含了一定的主觀因素在內，不過我相信大多數項目還是非常有代表性的。

計算代碼數量的工具是 cloc。所有項目均選擇截止到 2018 年 1 月 3 日的主幹代碼，統計中僅包含 Python 檔，排除了其他檔案類型。值得說明的一點是， 通過 Ubuntu APT 默認安裝的 cloc 版本 1.60 在統計部分專案的時候存在問題，該問題在最新的版本中已經得到解決，因此本文中所有統計均使用從官網下載的 cloc v1.72。

上表已經按代碼行數排了序。有意思的一點是， 代碼規模最大的前4名中除了 CPython 之外其他三個全部是運維性質的項目，本來我猜測代碼應該比較多的項目比如 Odoo 排名反而很靠後。我對運維項目瞭解有限，不太清楚為什麼這些專案的代碼規模會名列前茅，或許是因為要支援的內容比較多而雜？

本次統計中純 Python 代碼量最大的 Sentry 幾乎達到了 70W 行，這是相當有規模的專案了。30W~50W 行代碼的專案有三個，包括基礎專案 CPython 在內。20W 和 10W 行代碼規模的分別有三個，剩下 7 個則在 10W 行以內。看過這個清單你應當相信，動態語言至少在幾十W行代碼的專案上是完全沒有問題的。

這也是絕大多數普通應用的上限了，如果代碼真的達到數百萬行規模的話，那麼無論用什麼語言，都勢必面臨著拆分專案的問題。

上表將代碼量指標按照代碼/空白/注釋進行了分類，也在一定程度上反應了專案的代碼風格。Sentry 是本次統計中代碼量最多的項目，然而從表中可以看到，項目中的注釋和其他項目相比，少得有點不成比例，說明 Sentry 的作者非常不注重注釋。

同學們一定發現了，我在列表中除了代碼行相關的指標之外還增加了幾個其他內容，這也是我個人比較感興趣的方面。

第一個指標是每個檔的平均代碼行數。按照模組化的觀點，單個檔中堆砌太多內容顯然是不合理的，這通常意味著耦合太多、難於理解和修改。然而到底多少算是合適，並沒有一個明確的標準。我希望通過這些項目的分析，瞭解一下開源作者們在實踐中做出的選擇。

統計的結果分佈比較平均，從 100~600行/文件的都存在，並不存在明顯的集中點。有趣的是，頭兩名（Pandas, NumPy）有著緊密的聯繫，都是和數學統計相關的。這可能是因為數學庫的特點比較純粹而單一，不像其他類庫那樣容易劃分。末尾的項目（Pillow, youtube-dl, Odoo, Scrapy）可以從側面印證這種猜想：它們都是面向特定領域的，所以更加容易模組化。

第二個指標是注釋和代碼的比例，這個問題也有著類似的情況。注釋並非越詳盡越好，但總是需要一定量的注釋來解釋 Why 的問題。注釋太少，說明專案的作者沒有給後來的維護人員留下足夠的線索，可能會造成維護上的問題。另一方面，我們考察的全部是開源專案，沒有公司考核或者 KPI 的約束，所以我們可以放心的相信不會存在作者故意多寫注釋的問題。前面提到的 Sentry 毫無爭議的因為注釋太少排到了最後，這未必說明這個項目很差，但至少是一個信號，說明該專案在維護方面可能是存在問題的。而對於那些作者願意投入精力來寫注釋的項目（Ansible, NumPy, Fabric, Salt 等），足以反映作者在項目上投入了相當大的心力，這是一個好的信號，說明這些專案是值得信賴的。

有一點是出乎我意料的，那就是作為所有項目之母的 CPython 排名比較靠後，按照道理這個基礎項目應該有更多的注釋才對。不過再想一想又覺得可以理解，因為 CPython 有單獨發佈的、非常詳盡的文檔，這是其他大多數專案都沒有的，那麼代碼中的注釋少一些也是情有可原的。

最後一項統計是關於檔案類型的。Python 項目中絕大多數應該是 Python 代碼，這點沒有什麼疑問，但同時我也想看看除了 Python 代碼之外，一個專案還包括哪些主要檔。C/HTML/Javascipt 的上榜是毫不意外的，但有一種檔我事先沒有想到，那就是 .PO（開源專案常用的語言資源檔）。對於 Django 和 Django-CMS 這兩個項目, PO 代碼數量甚至比 Python 代碼還要多。

大概看了一下，Django 支援 90 種以上的語言，這也無怪乎語言檔的數量如此之多了。這個結果也可以提醒我們，有些同學——不僅是程式師，也包括大多數經驗不足的老闆、客戶、產品經理等——會下意識的認為程式開發無非是寫代碼，對於代碼之外的其他工作，在估算的時候往往只拍腦袋式的定下一個極短的時間。但對於實際的專案來說，代碼僅僅是其中的一部分，"其他工作"有時候——應該說是經常——會佔用你大部分的的時間和精力。

這些工作往往並不有趣，但對於專案來說又是必不可少的組成部分，希望同學們予以足夠的重視。

題圖：pexels，CC0 授權。

同學們一定發現了，我在列表中除了代碼行相關的指標之外還增加了幾個其他內容，這也是我個人比較感興趣的方面。

第一個指標是每個檔的平均代碼行數。按照模組化的觀點，單個檔中堆砌太多內容顯然是不合理的，這通常意味著耦合太多、難於理解和修改。然而到底多少算是合適，並沒有一個明確的標準。我希望通過這些項目的分析，瞭解一下開源作者們在實踐中做出的選擇。

統計的結果分佈比較平均，從 100~600行/文件的都存在，並不存在明顯的集中點。有趣的是，頭兩名（Pandas, NumPy）有著緊密的聯繫，都是和數學統計相關的。這可能是因為數學庫的特點比較純粹而單一，不像其他類庫那樣容易劃分。末尾的項目（Pillow, youtube-dl, Odoo, Scrapy）可以從側面印證這種猜想：它們都是面向特定領域的，所以更加容易模組化。

第二個指標是注釋和代碼的比例，這個問題也有著類似的情況。注釋並非越詳盡越好，但總是需要一定量的注釋來解釋 Why 的問題。注釋太少，說明專案的作者沒有給後來的維護人員留下足夠的線索，可能會造成維護上的問題。另一方面，我們考察的全部是開源專案，沒有公司考核或者 KPI 的約束，所以我們可以放心的相信不會存在作者故意多寫注釋的問題。前面提到的 Sentry 毫無爭議的因為注釋太少排到了最後，這未必說明這個項目很差，但至少是一個信號，說明該專案在維護方面可能是存在問題的。而對於那些作者願意投入精力來寫注釋的項目（Ansible, NumPy, Fabric, Salt 等），足以反映作者在項目上投入了相當大的心力，這是一個好的信號，說明這些專案是值得信賴的。

有一點是出乎我意料的，那就是作為所有項目之母的 CPython 排名比較靠後，按照道理這個基礎項目應該有更多的注釋才對。不過再想一想又覺得可以理解，因為 CPython 有單獨發佈的、非常詳盡的文檔，這是其他大多數專案都沒有的，那麼代碼中的注釋少一些也是情有可原的。

最後一項統計是關於檔案類型的。Python 項目中絕大多數應該是 Python 代碼，這點沒有什麼疑問，但同時我也想看看除了 Python 代碼之外，一個專案還包括哪些主要檔。C/HTML/Javascipt 的上榜是毫不意外的，但有一種檔我事先沒有想到，那就是 .PO（開源專案常用的語言資源檔）。對於 Django 和 Django-CMS 這兩個項目, PO 代碼數量甚至比 Python 代碼還要多。

大概看了一下，Django 支援 90 種以上的語言，這也無怪乎語言檔的數量如此之多了。這個結果也可以提醒我們，有些同學——不僅是程式師，也包括大多數經驗不足的老闆、客戶、產品經理等——會下意識的認為程式開發無非是寫代碼，對於代碼之外的其他工作，在估算的時候往往只拍腦袋式的定下一個極短的時間。但對於實際的專案來說，代碼僅僅是其中的一部分，"其他工作"有時候——應該說是經常——會佔用你大部分的的時間和精力。

這些工作往往並不有趣，但對於專案來說又是必不可少的組成部分，希望同學們予以足夠的重視。

題圖：pexels，CC0 授權。