क्या यह संदिग्ध है या यह बिल्कुल ठीक है?

Question

क्या यह कोड संदिग्ध है या यह पूरी तरह से ठीक है (मानकों द्वारा अनुमोदित/अस्तित्व में किसी भी कंपाइलर के लिए लगातार व्यवहार है)?

struct SCustomData { 
    int nCode; 
    int nSum; 
    int nIndex; 
    SCustomData(int nCode, int nSum, int nIndex) 
     : nCode(nCode) 
     , nSum(nSum) 
     , nIndex(nIndex) 
    {} 
}; 

संपादित करें:
हाँ, मैं तथ्य यह है कि सदस्य चर निर्माता की औपचारिक मानकों के साथ एक ही नाम है की चर्चा करते हुए कर रहा हूँ।

Answer 1

नहीं, इस मामले में कोई अस्पष्टता नहीं है, लेकिन निम्नलिखित पर विचार:

struct SCustomData { 
//... 
    void SetCode(int nCode) 
    { 
      //OOPS!!! Here we do nothing! 
      //nCode = nCode; 

      //This works but still error prone 
      this->nCode = nCode; 
    } 
}; 

आप मौजूदा कोडिंग शैलियों में से एक की ओर ध्यान आकर्षित करना चाहिए। उदाहरण के लिए General Naming Rule in Google C++ Coding Styles या हर्ब सटर और आंद्रेई अलेक्जेंड्रेसकू द्वारा उत्कृष्ट पुस्तक "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" पढ़ें।

Answer 2

आपका उदाहरण अस्पष्ट (मेरे लिए) है, लेकिन यह अच्छा अभ्यास नहीं है, क्योंकि यह जल्दी से नरक के रूप में संदिग्ध हो सकता है।

यह बहुत लंबा है क्योंकि मैंने क्रोध में कोई सी ++ लिखा है, इसलिए मैं अनुमान लगा रहा हूं कि निम्नलिखित क्या करेंगे।
क्या आप जानते हैं यह क्या करेगा? क्या आपको यकीन है?

class Noddy 
{ 
    int* i; 
    Noddy(int *i) 
    : i(i) 
    { 
     if(i == NULL) 
      i = new int; 
    } 
}; 

Answer 3

यदि आप सदस्यों और कन्स्ट्रक्टर तर्कों के लिए समान नाम का उपयोग करने का जिक्र कर रहे हैं, तो यह बिल्कुल ठीक है। हालांकि, आपको कुछ लोग मिल सकते हैं जो जोर देते हैं कि किसी कारण से यह खराब अभ्यास है।

यदि आपको कन्स्ट्रक्टर बॉडी में सदस्यों तक पहुंचने की आवश्यकता है, तो आपको सावधान रहना होगा - या तो तर्क अलग-अलग नाम दें, या सदस्यों तक पहुंचने के लिए this-> का उपयोग करें।

यदि आप छद्म हंगेरियाई मौसा का उपयोग करने के लिए लोगों को याद दिलाने के लिए जिक्र कर रहे हैं कि पूर्णांक पूर्णांक हैं, तो तकनीकी रूप से अनुमति है, लेकिन इसका कोई लाभ नहीं है और कोड को पढ़ने के लिए बहुत कठिन बनाता है। कृपया यह मत करो।

Answer 4

सामान्य रूप से, मैंने बिना किसी उपसर्ग के कन्स्ट्रक्टर में अंडरस्कोर और नामित पैरामीटर के साथ आवृत्ति चर का चयन किया है। कम से कम, यह आपके पैरामीटर को आपके आवृत्ति चर से अलग कर देगा। यह कन्स्ट्रक्टर के शरीर के भीतर शुरू होने पर जीवन को कम व्यस्त बनाता है।

struct SCustomData { 
    int _nCode; 
    int _nSum; 
    int _nIndex; 
    SCustomData(int nCode, int nSum, int nIndex) 
     : _nCode(nCode), _nSum(nSum), _nIndex(nIndex) 
    {} 
}; 

// Alternatively 
struct SCustomData { 
    int _nCode; 
    SCustomData(int nCode) 
    { 
     this->_nCode = nCode; 
    } 
}; 

मैं चर जिस तरह से यह प्रश्न में लिखा गया था स्टैकिंग पसंद नहीं है। मुझे लंबवत स्थान को सहेजना पसंद है, और मेरे लिए बाएं से दाएं पढ़ने के लिए भी आसान है। (यह मेरा, नहीं एक अनिवार्य नियम या ऐसा कुछ के एक निजी पसंद है।)

Answer 5

यह पूरी तरह से मानक के अनुरूप है, लेकिन वहाँ compilers वहाँ बाहर है कि सदस्य चर निर्माता पैरामीटर के रूप में एक ही नाम होने स्वीकार नहीं करेगा कर रहे हैं । वास्तव में, मुझे उस कारण से अपनी ओपन सोर्स लाइब्रेरी बदलनी पड़ी। this patch

Answer 6

मैं कहूंगा कि यह बिल्कुल ठीक है।

यह उन रचनाकारों के लिए मेरी पसंदीदा शैली है जो प्रारंभिक सूची का उपयोग करते हैं और उनके पास कोई कोड नहीं है। मुझे लगता है कि यह भ्रम को कम करता है क्योंकि यह स्पष्ट है कि कौन सा सदस्य कन्स्ट्रक्टर पैरामीटर जाता है।