Objective-C 方法命名藝術：從「冗長」到「自文檔化」的思維轉變

初見 - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 這樣「超長」簽名，C#/Java 開發者往往感到震驚。實則 Objective-C 採用 **Interleaved Keyword（交織關鍵字）** 風格，將參數名融入方法名，實現「代碼即文檔」。本文深度解析命名規約、調用語法、Xcode 提示機制，助你從抗拒轉為擁抱。

核心語法拆解

- (返回類型) 關鍵字1:(類型1)參數1 關鍵字2:(類型2)參數2 ...

• 選擇器：application:didFinishLaunchingWithOptions:（冒號數 = 參數數）
• 參數名：僅在實現內部可見，調用時不出現。
• 調用：[obj application:app didFinishLaunchingWithOptions:opts] —— 讀起來像英文句子。

對比：Java vs Objective-C

命名最佳實踐（蘋果官方指南精華）

1. 首關鍵字描述主要動作：initWithFrame:、stringByAppendingString:
2. 後續關鍵字描述參數角色：with、from、to、at 等介詞開頭。
3. 布爾屬性/查詢：isEditable、hasPrefix:、shouldAutorotate。
4. 避免縮寫：maximumValue 而非 maxVal；常見縮寫（URL、ID、RGB）除外。
5. 工廠方法：+ (instancetype)stringWithFormat: 以類名開頭。

Xcode 智能提示機制

輸入 [self addA: 時，Xcode 彈出 withB: 佔位符，參數類型、順序一目了然，無需跳轉定義。這正是「命名即文檔」的工程紅利。

常見誤區澄清

• 誤區：「參數名也是方法名一部分」→ 事實上選擇器僅含關鍵字+冒號，參數名可任意修改不影響二進制兼容。
• 誤區：「太長影響性能」→ 編譯後選擇器只是 C 字符串，調用經 objc_msgSend 查找，長度影響可忽略。

心法：Objective-C 命名不是為了「寫給編譯器看」，而是為了「寫給 6 個月後的自己和團隊看」。擁抱冗長，收獲清晰。