2009-11-07 59 views
10

這個問題是關於Objective C和Cocoa中的變量命名風格。我只想強調,我不是在尋找「正確」的答案,只是好的想法。Cocoa中的實例變量命名約定

我已經閱讀了Apple和Google的客觀c風格指南,我對他們兩個都不滿意。 Apple的指南沒有關於實例變量與局部變量的任何真實風格建議。事實上,Cocoa庫本身看起來非常高興,它的函數參數與實例變量完全相同。這讓我感到害怕。

Google搜索指南指定實例變量應該以尾部下劃線表示。好吧,一切都很好,但它表明我們然後用@synthesize property = property_合成每個公共屬性。我不知道其他任何人,但是如果我要爲我的項目中的每個實例變量都這樣做,我會被詛咒的。我認爲這是一個浪費和混亂的解決方案。

我很想用myX(例如「myInstanceVariable」)命名對象屬性的樣式,但我很少在目標c中看到過這種樣式。

所以是的,你用什麼?任何風格的約定,我不知道你發現有用嗎?你認爲與實例變量名稱相同的函數參數是否危險,特別是在多個開發人員環境中?感謝傢伙和女孩!

注 - 正如很多人指出的,我的術語在OP中是關閉的。如果原來的措辭損害了清晰度,我表示道歉,但我認爲這一點仍然清楚。

回答

10

我傾向於使用非前綴實例變量名稱(注意,「成員變量」是一個C++主義,因爲它是暗示結構和類爲主要可互換的,這是不在Objective-C的情況下) ,並在出現歧義的情況下,我用它的類型與「一」或「一」,例如命名參數的Smalltalk的約定:

- (void)setFoo:(SOFoo *)aFoo; 
{ 
    foo = aFoo; 
} 

(當然,在現代ObjC你會使用此屬性。)

使用theFoo而不是aFoo也有點常見;請參閱this question的答案。

如果您真的擔心衝突,那麼Google約定是有意義的。如果您使用Xcode text macroCompletion DictionaryAccessorizer等工具來生成您的指令,那麼採用它非常簡單。請注意,Cocoa key-value coding guidelines幾乎假設(a)您不爲前綴/後綴實例變量名稱,或(b)您爲它們實現(或合成)非前綴/後綴的訪問器。正如別人提到的,不要使用_前綴;它保留給Apple在其框架中使用。

+0

很好的答案。我同意前綴參數比嘗試將常規變成客觀的c實例變量更清晰。蘋果文檔在常見NSObject類型的情況下描述了這種約定,因此將它擴展爲您自己的類型非常有意義。 我將此標記爲答案,因爲它最好地回答了我的問題的主要觀點 - 避免類函數中含糊不清的名稱間距 - 並且不會添加任何奇怪的約定或變通方法。 – DougW 2009-11-09 18:39:56

-1

m_variableName對於成員變量也很常見。 個人而言,大部分時間,我只是用兩個變量的名字來區分this.varnamevarname

+0

是的,我見過m_X偶然,但在客觀二傳手約定c那麼它看起來凌亂。 setM_variableName?我想如果你堅持使用點符號,你可以避免這種情況。 – DougW 2009-11-07 03:43:37

+1

「m_」前綴是一個壞習慣。除非你在Apple編寫內部使用的代碼,否則單個主要的下劃線也是如此。不幸的是,蘋果公司一直在讓許多示例代碼項目在沒有適當清理的情況下襲擊街道。 – NSResponder 2009-11-07 03:51:30

+1

_foo爲什麼是壞習慣? Apple無法將Obj-C 1.0代碼添加到ivars中,因此它們不能破壞你的代碼。據我瞭解,編譯器在Obj-C 2.0中調整它們,以便儘管Apple可以中斷代碼的編譯(易於修復),但已編譯的程序將繼續工作。 – 2009-11-07 12:46:23

4

在Cocoa中,風格是讓pascalCased(或者是camelCased?我永遠不會記得)名字;並使成員變量的名稱與訪問器方法相同。 (如NSInteger anInteger,- anInteger- setAnInteger:)。

它可能不是最好的風格,但如果你要用Cocoa做任何工作,那麼適應它可能是一個好主意,因爲許多機制都假定這種特定的命名約定。

+0

當然,我知道getter/setter授權的約定,我不會偏離駱駝的情況。我的問題更多的是用於表示實例和成員變量之間區別的符號。 事實上,你可以用任何變量的名稱來合成訪問器方法,就像谷歌風格一樣,但這可能會讓IMO很混亂。 – DougW 2009-11-07 03:41:05

6

第一:Objective-C中沒有「成員變量」,有「Instance Variables」或「ivars」。 Google對於Objective-C編碼或Mac開發沒有任何權限。谷歌地球是一個Qt應用程序:'nuff說。

我似乎記得從蘋果的Objective-C看到官方編碼風格指南,目前我還沒有找到它。這篇文章是一個很好的總結,雖然:

http://cocoadevcentral.com/articles/000082.php

找到了!以下是蘋果官方的編碼準則可可:

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html

+0

感謝您鏈接蘋果指南。不過,我認爲其餘部分都是脫離主題的。每個人似乎都熱衷於利用他們對c術語分類的知識,但沒有回答這個問題。另外,谷歌可能沒有發明目標c,但它在編碼約定方面肯定是有效的來源。在這種情況下,我認爲蘋果公司的文檔並沒有明確說明這一點,谷歌也是如此。我只是不喜歡他們的答案。 – DougW 2009-11-09 18:53:41