C++ 編程中是否可以使用Objective C動輒幾十個字元的變數/函數命名方法？

01-04

Objective C中變數/函數的名稱常常包含好幾個單詞，占幾十個字元，代替了一部分注釋的功能，我的感受是加快了閱讀代碼的速度，因為省去了不少跳回函數聲明處去讀注釋甚至源碼的時間。
我試著在C++里使用了這種命名風格，代碼體積龐大了不少，for循環常常一行寫不下。。。但後期維護起來確實舒服了不少。
這種做法是否符合「規範」？或者說，大拿們是否接受這種風格？又或者說，假設在面試時這樣寫一段代碼，會不會被面試官吐槽？

其實呢，oc也是可以重載（overload）的啦，哈哈哈哈哈哈哈哈哈哈哈哈哈。。。。。

以趙百萬的例子為例

// class define User string name; double wages; string language;


// define

+ (User *)user:(id)query {

  if([[query class] isStringClass]) {

    // do what you wanna do

  } else if([[query class] isNumberClass]) {

    // with whatever type you wanna do it with

  }

}
+（User *)user:(id)query gender:(Gender)gender {

  // simple message sending

}
// call

User *u = [User user:@"jeffrey"];

display(u);

// name: "jeffrey zhao", wages: 1000000, language: "c?"
u = [User user:@1000000.];

display(u);

// name: "jeffrey zhao", wages: 1000000, language: "c?"

u = [User user:@1000000. gender:@F]; display(u); // nil

各位官人別急，先把刀放下把刀放下，有話聽我慢慢說，慢慢說。。。

我知道啦，這個方法並不是純正的overload，因為c語言的基礎類型不能用嘛，但確實是實現了overload的功能啦（在oc里），而且還不用顯式聲明，多方便。。。

大家要記住：Objective-C是純正的動態語言

呃。。。。我額外說一點，Objective-C不推薦GetXXX的命名方法，看

- (User)user; // ? 直接 - (User)getUser; // ? 沒必要

那個。。既然知道了oc能實現函數重載，那就說明名字長就和函數重載沒關係了嘛。。。

其實呢。。。之所以大家感覺oc的名字那麼長，是因為oc是蘋果一家倡導，且主要使用Cocoa框架，GUI框架名字取長點無可厚非的，重型框架嘛

下面分別是oc和c的調用形式

在看代碼的時候，oc可以一眼看清，c形式一排參數，不容易看明白，當然，這不那麼重要

下面兩圖，是cocoa里的枚舉長度，枚舉長一些有啥好處呢？

以圖上動畫參數和按鈕事件為例，輸入前綴可以自動彈出補全，不用看文檔了，算半個好用的文檔吧。不過，這也不重要，IDE應該能在參數處智能提示才對，但是20年前沒這麼先進的IDE，所以就用了這種約定而已。

而為一個20年歷史的庫添加功能，最好是依照庫的本身命名約定為好，反正有自動補全和智能提示嘛。

對於你的問題，我覺得奇怪的是為啥for循環會到寫不下的地步呢？

首先，取名字不能死板，不是說長名字就一定好一定清晰，局部變數用簡短名字也很好啊

其次，寫程序應該寫what而不是how，做好抽象，這樣你讀代碼的時候就不用關心細節了，所以你平常不應該讀到for這樣的東西，只應該讀到函數調用，就像讀書一樣流暢愉快

至於規範，沒有定式，大拿喜好也不盡相同，面試寫這種代碼會不會被鄙視。。。我只能說肯定比寫a b c x1 x2要來得好得多（面試那種演算法題你真的能寫很長的變數名嗎？）

我去leetcode上找了一道最簡單的題，你感受一下

def isPalindrome(s) valid_set = set(string.ascii_uppercase + string.digits) s = filter(lambda c: c in valid_set, s.upper()) return s == s[::-1]

這樣吧，貼代碼大家給你改改，這樣你一下就進步好多了

+++update

經@Milo Yip大神提點，我覺得還是總結一下我的意思吧。

取名字沒有定規，要點是服務於可讀性和團隊規範
oc因為只有蘋果在用，所以你只能看到蘋果的風格
cpp因為應用廣泛，所以有各種風格
只要你覺得能確保提升效率，用什麼風格都行
面試最好跟著社區標準風格來
。。。

沒必要，OC那種長的要死的方法名，那是因為沒有重載（overload）。比如我們要兩個方法，都用來獲取對象，一個通過下標，一個通過名稱。在支持重載的語言裡面，就是類似於：

// C# Item Get(int index); Item Get(string name);

OC不支持，於是只能類似於：

// OC-like C# Item GetByIndex(int index); Item GetByName(string name); Item GetByNameAndGender(string name, Gender gender);

既然C++支持重載，就不要自己折騰自己了。

命名力求信達雅。生僻的縮寫應該通通槍斃。

本質上你可以用任何編程風格來寫你的代碼，但是語言可以怎麼寫和語言背後的文化提倡怎麼寫，是兩個完全不同的問題。

拿Objective-C來說，百分百兼容C語言，C語言怎麼寫當然怎麼寫都可以了，但是Objective-C開發者很忌諱在代碼裡面用C語言的風格寫代碼。

Objective-C的長得要死的代碼風格，來自於兩個設計目標：

1. 希望代碼看起來像英文句子一樣，好處很明顯，壞處也很明顯吧？

2. 希望函數的調用方法一望即可知，寫java寫得多的會有感受吧，你在編輯器上寫一個對象，然後打一個點，彈出一推提示，但是某個方法的提示，往往是xxxx(xx,x,xxx,xxx,xx)，第一每個參數什麼類型不知道，第二每個參數是做什麼不知道。Objective-C的方式很啰嗦，但是，對於大多數程序員來說，根本不需要看文檔去查參數意義和類型了。

為了實現第一條，Objective-C還提倡了方法的遞歸調用，節省臨時變數增加可讀性。

為了做到這些，Xcode必須做相應的代碼提示和自動完成功能，如果沒有Xcode的代碼提示，我幾乎無法寫代碼，代碼提示和自動完成對我的價值，相當於同時提供了縮寫工具和文檔。

好，回到你的問題。

首先，C++一般的編輯器，是不適合這樣的代碼風格的，至少我當年寫C++的時候感覺如此，不知道現在如何了。其次，你調用的大量的庫都不是這種風格的話，你寫Objective-C風格的代碼的話，你會覺得很不協調的。

C++應該大量使用auto，又好看、又好寫、讓編譯器推導又可靠。所以實際上你只需要在new或者聲明函數的時候寫類型。這個時候有Visual Studio 2014強大的智能提示作為後盾，簡直毫無難度。

譬如說的你類是

class HeIsAFuckingIdiot { };

當你需要new它出來的時候實際上只需要寫

auto fuck = new hiafi // 這裡會提示你HeIsAFuckingIdiot是可以用的一個類型。

看起來也爽，寫起來也爽，簡直沒有理由要跟以前一樣到處用那些看不懂的縮寫，偷吃幾個字母的單詞什麼的（譬如creat）。

可以使用，提倡使用。

準確，清晰，無歧義 的變數和方法的命名，即使動輒幾十個字元長，鍵入困難可以通過 IDE 解決。但你理解代碼所需要的心智能量起碼少一個數量級。

懶的寫注釋就自注釋嘛

C++的喜歡show用文本編輯器寫代碼,鄙視各種IDE,所以不行

函數名只是為了讓大家容易理解函數，容易閱讀代碼，能達到這個目的的都算，

一般c語言用類型名+變數名(匈牙利命名法):intNum

c# java等用駝峰命名法和帕斯卡命名法:getNum

當然可以。

早期語言因為性能還是其他限制(我忘記了)，命名不能太長。而C++是很老的語言，所以內部很多庫函數都使用了簡短的命名方式，C語言也是。

很多老程序員可能現在還保留這個習慣。

不過到如今，已經完全沒這個限制啦，你可以看到一些新出現的語言，java的API, 安卓的API(我學的不多，就了解這麼點)都是這種命名方式。所以，為了提高可讀性，儘管命名的長一點吧，但是也不要不加思索的成串的單詞寫上去，要好好思考，多多精鍊。

感覺適當的注釋類型命名還是不錯的，方便代碼閱讀，就是太長的話也蛋疼

從美學角度看，名稱越短越好，這樣顯得簡潔好看。

從工程角度看名稱越長越好，因為大型應用代碼都會上十萬行，看代碼會很累很艱苦，沒人願意看個名稱不知道什麼意思需要轉跳到注釋，只是增加無謂的時間和出錯率。

我現在是命名盡量的長，但也不宜太啰嗦。

能簡寫的幹嗎不簡寫，還有人嫌簡單了不行嗎？

一個函數加上參數，一大塊，直接影響可讀性。

能用命名描述清楚功能的當然好，描述不清楚，加上注釋能夠說得明明白白。

非得用一長串單詞來描述，我是受不了。

C語言是因為語言缺陷只把前面n個字元當做標識符，C++已經改掉了這個，縮寫和匈牙利命名法都是沒有必要的