आप अपने इंस्टेंस/पैरा मानों का नाम कैसे देते हैं?

उद्देश्य-सी (लेकिन एक दीर्घकालिक सी/++) प्रोग्रामर के लिए नया होने के नाते मैं चर के लिए सम्मेलन नामकरण पर सलाह/सिफारिशों की तलाश में हूं।

मेरी व्यक्तिगत प्राथमिकता फ़ंक्शन के भीतर स्पष्टता और फ़ंक्शन पैरामीटर की छाया को रोकने के लिए आवृत्ति चर के लिए एक उपसर्ग का उपयोग करना होगा। हालांकि मैं गुणों का प्रशंसक हूं जो उपसर्गों का नियम बनाते हैं (जब तक कि आप अपनी संपत्ति के नामों को भी उपसर्ग नहीं करते हैं, जो बहुत अच्छी तरह से काम नहीं करते हैं और दांत दिखते हैं)। इसी प्रकार मैं "self.variable" सम्मेलन का उपयोग कर सकता था, लेकिन केवल अगर मैं संपत्ति को सब कुछ कर सकता हूं।

तो नीचे दिए गए कोड को उदाहरण/फ़ंक्शन चर के लिए आपकी पसंदीदा नामकरण शैली क्या है? और यदि आप परेशान नहीं हैं, तो आप फ़ंक्शन पैरा पर छाया से कैसे निपटते हैं?

@interface GridItem : NSObject
{
    CGRect _rect;
    ...  
}
@end

-(void) initFromRect:(CGRect)rect
{
    _rect = rect;
    ...
}

चीयर्स!

 0
जोड़ा संपादित
विचारों: 26
स्रोत

10 उत्तर

मुझे किसी भी पहचानकर्ता के लिए उपसर्ग के रूप में अंडरस्कोर का उपयोग करना पसंद नहीं है, क्योंकि सी और सी ++ कार्यान्वयन द्वारा उपयोग के लिए कुछ अंडरस्कोर उपसर्ग दोनों आरक्षित करते हैं।

मुझे लगता है कि "self.variable" का उपयोग बदसूरत है।

आम तौर पर, मैं उदाहरण चर के लिए unadorned पहचानकर्ता (यानी, कोई उपसर्ग और न ही प्रत्यय) का उपयोग करें। यदि आपकी कक्षा इतनी जटिल है कि आप आवृत्ति चर को याद नहीं कर सकते हैं, तो आप परेशानी में हैं। तो आपके उदाहरण के लिए, मैं पैरामीटर नाम के रूप में "रेक्ट" का उपयोग आवृत्ति चर और "newRect" या "aRect" के नाम के रूप में करता हूं।

0
जोड़ा
स्रोत

गुणों के परिचय के साथ मुझे क्लास इंस्टेंस चर के लिए "_" उपसर्ग करने की आवश्यकता नहीं है। आप एक साधारण नियम (अपनी हेडर फ़ाइल में वर्णित) सेट कर सकते हैं कि किसी भी चर को कक्षा के बाहर तक पहुंचाया जाना चाहिए, संपत्ति के माध्यम से या मूल्यों को प्रभावित करने के लिए कक्षा पर कस्टम विधियों का उपयोग करके। मेरे सामने यह उनके सामने फंस गए "_" नामों के मुकाबले ज्यादा साफ दिखता है। यह मूल्यों को सही ढंग से समाहित करता है ताकि आप नियंत्रित कर सकें कि वे कैसे बदलते हैं।

0
जोड़ा
स्रोत

अधिकांश कोको परियोजनाएं गैर- IBOutlet instance variable prefix के रूप में अंडरबार का उपयोग करती हैं, और IBOutlet instance variables के लिए कोई उपसर्ग का उपयोग नहीं करती हैं।

IBOutlet इंस्टेंस वेरिएबल्स के लिए अंडरबार का उपयोग नहीं करने का कारण यह है कि जब एक nib फ़ाइल लोड हो जाती है, यदि आपके पास कनेक्टेड आउटलेट के लिए एक सेटटर विधि है, तो उस सेटर को कॉल किया जाएगा। हालांकि यह तंत्र नहीं कुंजी-मूल्य कोडिंग का उपयोग करता है, इसलिए एक आईबीओटलेट जिसका नाम अंडरबार ( उदा। _myField ) नहीं सेट किया जाएगा जब तक कि सेटटर को आउटलेट की तरह बिल्कुल नामित नहीं किया जाता है ( उदा। set_my फ़ील्ड: ), जो गैर-मानक और सकल है ।

Also, be aware that using properties like self.myProp is not the same as accessing instance variables. You are sending a message when you use a property, just like if you used bracket notation like [self myProp]. All properties do is give you a concise syntax for specifying both the getter and setter in a single line, and allow you to synthesize their implementation; they do not actually short-circuit the message dispatch mechanism. If you want to access an instance variable directly but prefix it with self you need to treat self as a pointer, like self->myProp which really is a C-style field access.

अंत में, कोको कोड लिखते समय हंगेरियन नोटेशन का उपयोग न करें, और "एफ" और "एम_" जैसे अन्य उपसर्गों से दूर शर्मिंदा हो? जो कोड को किसी ऐसे व्यक्ति द्वारा लिखा जाएगा जो "इसे प्राप्त नहीं करता" है और इसे अन्य कोको डेवलपर्स द्वारा संदेह से देखा जाएगा।

सामान्य रूप से, Cocoa"> कोडिंग के लिए

आप देखेंगे कि मैं आवृत्ति चर का उपयोग कर रहा हूं जो मेरे -init और -dealloc विधि में सीधे कर्मचारी का संदर्भ देता है, जबकि मैं ' मैं अन्य तरीकों से संपत्ति का उपयोग कर रहा हूँ। यह आम तौर पर गुणों के साथ एक अच्छा पैटर्न है: प्रारंभिक में किसी संपत्ति के लिए अंतर्निहित आवृत्ति चर को कभी भी स्पर्श करें, -dealloc में, और संपत्ति के लिए गेटर और सेटर में।

0
जोड़ा Chris Hanson
स्रोत
...तथा? यह एक अच्छा विचार नहीं बनाता है। :)
जोड़ा लेखक Chris Hanson, स्रोत
ऐप्पल के UITextView उपसर्ग I_ के साथ Ivars।
जोड़ा लेखक Christopher Lloyd, स्रोत

एंड्रयू: वास्तव में बहुत सारे कोको डेवलपर्स हैं जो इंस्टेंस वैरिएबल उपसर्ग का उपयोग नहीं करते हैं। यह स्मॉलटॉक दुनिया में भी बेहद आम है (असल में, मैं कहूंगा कि यह स्मॉलटाक में उदाहरण के चर पर उपसर्ग का उपयोग करने के लिए लगभग अनसुना है)।

उदाहरण चर पर उपसर्ग ने मुझे हमेशा एक सी ++ - आईएसएम के रूप में मारा है जिसे जावा पर लाया गया था और फिर सी #। चूंकि उद्देश्य-सी दुनिया काफी हद तक सी ++ दुनिया के समानांतर थी, जहां जावा और सी # दुनिया इसके उत्तराधिकारी हैं, इससे डेवलपर्स के विभिन्न सेटों के बीच आप "सांस्कृतिक" अंतर को देख सकते हैं।

0
जोड़ा
स्रोत

यहां क्या कहा गया है, इसके साथ-साथ मुख्य मूल्य पर अनुपालन नामकरण कोको दस्तावेज को पढ़ना सुनिश्चित करें। इस पैटर्न का सख्ती से पालन करने से आपको लंबे समय तक बहुत मदद मिलेगी।

0
जोड़ा
स्रोत

मेरी शैली हाइब्रिड है और वास्तव में PowerPlant दिनों से एक होल्डओवर है:

मेरे द्वारा उपयोग किए जाने वाले सबसे उपयोगी उपसर्ग फ़ंक्शन/विधि पैरामीटर के लिए "इन" और "आउट" हैं। यह आपको यह जानने में मदद करता है कि पैरामीटर एक नज़र में क्या हैं और वास्तव में विधि पैरामीटर और आवृत्ति चर के बीच संघर्ष को रोकने में मदद करता है (आपने कितनी बार पैरामीटर "टेबल" विवाद को उसी नाम के इंस्टेंस वैरिएबल के साथ देखा है)। उदा .:

- (void)doSomethingWith:(id)inSomeObject error:(NSError **)outError;

फिर मैं उदाहरण चर और संपत्ति के नाम के लिए नंगे नाम का उपयोग करता हूं:

फिर मैं स्थानीय चर के लिए उपसर्ग के रूप में "the" का उपयोग करता हूं: TheTable, theURL, आदि। यह स्थानीय और आवृत्ति चर के बीच अंतर करने में मदद करता है।

फिर पावरप्लेंट स्टाइल के बाद मैं कुछ अन्य उपसर्गों का उपयोग करता हूं: स्थिरांक के लिए के, ई enums के लिए, ग्लोबल्स के लिए जी, और सांख्यिकी के लिए एस।

मैं इस शैली का उपयोग 12 साल की तरह कुछ के लिए कर रहा हूं।

0
जोड़ा
स्रोत
के, ई, जी और चीज पर आश्वस्त नहीं है, लेकिन मुझे अंदर और बाहर जोड़ने का विचार पसंद है।
जोड़ा लेखक Steven Fisher, स्रोत

मैं अंडरस्कोर इवर उपसर्ग के संबंध में क्रिस हैंनसन की सलाह का पालन करता हूं, हालांकि मैं स्वीकार करता हूं कि मैं आईबीओटलेट्स के लिए अंडरस्कोर का भी उपयोग करता हूं। हालांकि, मैंने हाल ही में @ mmalc का सुझाव । लाभ यह है कि मेरे सभी आईवरों में अब अंडरस्कोर और मानक केवीसी सेटर्स कहा जाता है (यानी setNameField: )। साथ ही, आउटलेट नामों में इंटरफेस बिल्डर में अंडरस्कोर नहीं है।

@interface EmployeeWindowController : NSWindowController {
@private
   //model object this window is presenting
    Employee *_employee;

   //outlets connected to views in the window
    NSTextField *_nameField;
    NSTextField *_titleField;
}

- (id)initWithEmployee:(Employee *)employee;

@property(readwrite, retain) Employee *employee;
@property(nonatomic, retain) IBOutlet NSTextField *nameField;
@property(nonatomic, retain) IBOutlet NSTextField *titleField;

@end
0
जोड़ा
स्रोत
यह वास्तव में मैं अब करता हूं, संपत्तियों पर आईबीओटलेट के लिए आईबी के समर्थन के लिए धन्यवाद। :)
जोड़ा लेखक Chris Hanson, स्रोत

While I love using the underscore prefix for ivars, I loathe writing @synthesize lines because of all the duplication (it's not very DRY). I created a macro to help do this and reduce code duplication. Thus, instead of:

@synthesize employee = _employee;

मैं यह लिखता हूं:

ddsynthesize(employee);

दाएं हाथ में अंडरस्कोर जोड़ने के लिए टोकन पेस्टिंग का उपयोग करके यह एक साधारण मैक्रो है:

#define ddsynthesize(_X_) @synthesize _X_ = _##_X_

केवल नकारात्मक पक्ष यह है कि यह एक्सकोड के रिफैक्टरिंग टूल को भ्रमित कर देगा, और यदि आप रिफैक्टरिंग द्वारा संपत्ति का नाम बदलते हैं तो इसका नाम बदल नहीं जाएगा।

0
जोड़ा
स्रोत

निजी तौर पर, मैं कोको नामकरण सम्मेलनों का पालन करता हूं, कार्यों और चर के लिए ऊंट-आवरण का उपयोग करता हूं, और ऑब्जेक्ट नामों के लिए पूंजीकृत ऊंट-आवरण (पाठ्यक्रम के अग्रणी एनएस के बिना)।

मुझे लगता है कि टाइप उपसर्गिंग कोड को किसी भी व्यक्ति को अधिक अपारदर्शी बनाता है जिसने इसे नहीं लिखा है (क्योंकि हर कोई हमेशा अलग-अलग उपसर्गों का उपयोग करता है), और एक आधुनिक आईडीई में किसी चीज़ के बारे में पता लगाना मुश्किल नहीं है।

0
जोड़ा
स्रोत

आप अपने इवर पर अंडरबार उपसर्ग का उपयोग कर सकते हैं और अभी भी अपनी गुणों के लिए गैर-अंडरबार नाम का उपयोग कर सकते हैं। संश्लेषित एक्सेसर्स के लिए, बस यह करें:

@synthesize foo = _foo;

यह comp_foo ivar का उपयोग कर foo प्रॉपर्टी को संश्लेषित करने के लिए संकलक को बताता है।

यदि आप अपने स्वयं के एक्सेसर्स लिखते हैं, तो आप अपने कार्यान्वयन में अंडरबार इवर का उपयोग करें और गैर-अंडरबार विधि नाम रखें।

0
जोड़ा
स्रोत