為什麼「Data」可能是程式設計中最有問題的術語

資料命名挑戰簡介

在程式設計的世界中，命名規範對於創建可維護和易於理解的程式碼起著關鍵作用。如Martin Fowler的見解所強調，命名事物仍然是軟體開發中最困難的方面之一。糟糕的命名選擇可能會影響整個程式碼庫，造成混亂並顯著減慢開發進程。在這些命名挑戰中，「data」這個詞特別令人頭疼。

「data」一詞在程式設計環境中存在幾個關鍵問題。首先，它是一個極其模糊的術語，同時意味著一切又等於什麼都沒說。在計算機領域中，從簡單的整數到複雜的物件結構，所有內容都是資料。使用「data」作為變數名稱就像使用「thing」或「stuff」一樣，無法為變數的用途或內容提供任何有意義的背景。

此外，「data」是一個不變名詞，類似於「sheep」或「species」等詞。這種語法特徵會造成額外的混淆，因為它本身並不表明我們處理的是單個項目還是集合。雖然有人可能會說「datum」是單數形式，但在現代程式設計環境中很少使用，這使得模糊性更加問題化。

在檢查實際的Python程式碼時，我們經常遇到使用「data」作為參數名稱的函數。考慮這個例子：

def imgcat(data, lines=-1):

這個函數簽名引發了幾個問題：應該傳遞什麼類型的資料？是圖像資料？文本資料？二進制資料？這種模糊性迫使開發人員需要深入研究實現或文件來理解預期的輸入。

即使使用Python的型別提示（理論上應該可以釐清情況），問題仍然存在。考慮：

async def stream_offline(data: dict):

雖然這至少表明我們在使用字典，但缺乏具體的型別資訊（如dict[str, int]）仍然留下了許多解釋空間。字典可能包含任何鍵和值的組合，使程式碼更難理解和維護。

另一個說明性的例子來自計算z分數的函數：

def calc_zscore(data: np.ndarray) -> np.ndarray:

雖然這個例子使用了NumPy的ndarray型別，更具體一些，但它仍然沒有傳達關於數組預期維度或結構的重要資訊。對於z分數計算等統計操作，這些細節可能至關重要。

考慮這個更明確的例子：


@dataclass
class JohnsSpecialObject:
    bing: int
    bong: str

def do_something(johns_special_object: JohnsSpecialObject) -> None:
    pass

通過使用反映變數實際用途或內容的描述性名稱，我們可以使程式碼更易讀和維護。不要使用像「data」這樣的通用術語，而應使用描述變數在應用程式中代表什麼的具體名稱。

當想要使用「data」作為變數名稱時，請考慮這些替代方案：

使用更精確命名規範的努力可能看似微不足道，但對程式碼品質有重要影響：

廣泛使用「data」作為變數名稱代表了編寫更清晰、自文檔化程式碼的機會損失。雖然一開始可能需要更多思考，但選擇具體的、符合上下文的名稱在程式碼可維護性和理解性方面會帶來收益。隨著我們繼續發展軟體開發的最佳實踐，遠離像「data」這樣的通用術語代表著程式碼品質的簡單但重要的改進。