一個函數(shù)有10個參數(shù)是什么體驗(yàn)？MiniScript開發(fā)者Joe Strout最近曬了段代碼：調(diào)用PixelDisplay.drawImage時，光是記住參數(shù)順序就得先查文檔。更離譜的是，哪怕只想改最后一個參數(shù)，前面9個占位符也得老老實(shí)實(shí)填上。

這種"參數(shù)地獄"在Mini Micro里真實(shí)存在——drawImage方法有10個參數(shù)，從位置、尺寸到裁剪區(qū)域、顏色疊加，全部擠在括號里。

Joe Strout在MiniScript社區(qū)文檔里寫得很直白：「我經(jīng)常在Mini Micro命令行敲@gfx.saveImage，不為別的，就為了確認(rèn)參數(shù)順序?！?/p>

為什么MiniScript故意不做"命名參數(shù)"

很多現(xiàn)代語言支持按名稱傳參，比如Python的drawImage(image=img, tint=color.aqua)。這看起來很方便，但Strout認(rèn)為這是代碼腐爛的溫床。

他舉了個親身經(jīng)歷：曾維護(hù)過一個25參數(shù)的怪物函數(shù)，「簡直是噩夢」。命名參數(shù)會讓開發(fā)者放松警惕，覺得「多加一個參數(shù)也沒事」，結(jié)果函數(shù)膨脹到只有特定參數(shù)組合才合法，內(nèi)部塞滿校驗(yàn)邏輯，文檔比代碼還長。

Strout的毒舌評價：「很少見到哪種語言特性能這么快催生爛代碼，GOTO在這方面可能都要甘拜下風(fēng)。」

MiniScript的設(shè)計(jì)哲學(xué)是：參數(shù)多了，說明抽象層級出了問題。與其在語法層面縱容，不如逼開發(fā)者直面重構(gòu)。

參數(shù)對象：把10個變量打包成1個字典

解決方案來自經(jīng)典重構(gòu)手法「引入?yún)?shù)對象」（Introduce Parameter Object）。核心操作：把散落的參數(shù)收進(jìn)一個對象，調(diào)用方按需填充，接收方自主解析。

以drawImage為例，原函數(shù)簽名長這樣：

FUNCTION(self, image, left=0, bottom=0, width=-1, height=-1, srcLeft=0, srcBottom=0, srcWidth=-1, srcHeight=-1, tint="#FFFFFF")

Strout寫了個包裝函數(shù)，只收一個params參數(shù)：

drawImage = function(params) g = params.get("gfx", gfx) g.drawImage params.image, params.get("left", 0), params.get("bottom", 0), params.get("width", -1), params.get("height", -1), params.get("srcLeft", 0), params.get("srcBottom", 0), params.get("srcWidth", -1), params.get("srcHeight", -1), params.get("tint", "#FFFFFF") end function

調(diào)用方式徹底變樣。原來要記位置：

gfx.drawImage img, 500, 200, -1, -1, 0, 0, -1, -1, color.aqua

現(xiàn)在寫成自描述的結(jié)構(gòu)：

drawImage { "image": img, "left": 500, "bottom": 200, "tint": color.aqua }

沒指定的字段自動走默認(rèn)值，新增參數(shù)也不會破壞舊代碼——這是字典結(jié)構(gòu)比位置參數(shù)更抗造的地方。

從"填表"到"造句"：代碼可讀性的質(zhì)變

參數(shù)對象的價值不只是省掉占位符。Strout在文檔里強(qiáng)調(diào)，當(dāng)同一組參數(shù)在多個函數(shù)間傳遞時（比如UI框架的繪制流水線），字典比位置參數(shù)更能表達(dá)「這些字段屬于同一語境」。

MiniScript的mapUtil模塊提供了params.get(key, default)語法，讓默認(rèn)值處理比原生函數(shù)參數(shù)更靈活——你可以根據(jù)運(yùn)行時條件動態(tài)決定缺省值，而不是寫死在函數(shù)簽名里。

這種模式和JavaScript的options對象、Python的**kwargs異曲同工，但MiniScript的實(shí)現(xiàn)更極簡：沒有專門的語法糖，純靠字典操作完成。Strout認(rèn)為這反而是優(yōu)勢——「顯式比隱式好」，調(diào)用方清楚看到自己在組裝一個配置包，而不是被編譯器偷偷轉(zhuǎn)換。

一個細(xì)節(jié)：Strout的示例代碼里，params.image沒有用.get()，而是直接點(diǎn)訪問。這是他刻意為之——image是必傳字段，缺了就該報錯，而不是靜默走默認(rèn)值。

這種「必填vs可選」的區(qū)分，用傳統(tǒng)參數(shù)列表很難表達(dá)，在字典結(jié)構(gòu)里卻一目了然。

小型語言的固執(zhí)：為什么MiniScript拒絕"便利"

MiniScript的定位是嵌入式腳本語言，主打「小到能裝進(jìn)任何游戲引擎」。Strout在設(shè)計(jì)文檔里多次提到，每增加一個語法特性，都要付出實(shí)現(xiàn)復(fù)雜度和學(xué)習(xí)成本的代價。

命名參數(shù)屬于「看起來簡單，做起來重」的特性：解析器要支持新語法，IDE要補(bǔ)全參數(shù)名，文檔工具要生成新格式。更隱蔽的成本是心理暗示——開發(fā)者會傾向于濫用，直到函數(shù)參數(shù)數(shù)突破認(rèn)知負(fù)荷上限。

參數(shù)對象沒有這些包袱。它不依賴語言特性，純是代碼組織技巧；從Python到Lua到JavaScript，任何支持字典/對象的語言都能用。Strout把這稱為「可移植的最佳實(shí)踐」。

他在文檔結(jié)尾留了個開放場景：如果你發(fā)現(xiàn)自己在多個函數(shù)里重復(fù)傳遞同一組參數(shù)（比如渲染上下文、坐標(biāo)變換矩陣），就該考慮把它們封裝成「上下文對象」。這比每個函數(shù)加參數(shù)更干凈，也比全局變量更可控。

Mini Micro的drawImage有10個參數(shù)，是歷史遺留而非設(shè)計(jì)目標(biāo)。Strout的示例代碼暗示：如果今天重寫，API可能會直接設(shè)計(jì)成接收單個options字典——就像現(xiàn)代Canvas 2D API的drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight)雖然參數(shù)多，但Web開發(fā)者更常用的是封裝后的庫，把參數(shù)收進(jìn)配置對象。

這種「底層保留靈活性，上層封裝易用性」的分層思路，在MiniScript社區(qū)文檔里反復(fù)出現(xiàn)。參數(shù)對象不是萬能藥，但在「不想改動原生API」的約束下，它提供了足夠優(yōu)雅的逃生通道。

Joe Strout在文檔最后沒給結(jié)論，只放了一段可運(yùn)行的代碼示例。有讀者在評論區(qū)問：「如果參數(shù)對象嵌套太深怎么辦？」Strout回復(fù)：「那就說明你需要不止一個對象?！?/p>