एक परियोजना में 'assert' का उपयोग क्यों कर रहे हैं? (और क्यों यह तो कई बार उपयोग करते हुए)

Question

मैं नमूना कोड ListAdder के माध्यम से पढ़ रहा था, और कई देखते हैं सही चर के बाद इस बात पर ज़ोर, या लगभग हर विधि में इस्तेमाल किया, उदाहरण के लिए:

self.formatter = [[[NSNumberFormatter alloc] init] autorelease]; assert(self.formatter != nil);

या :

- (UITableViewCell *)tableView:(UITableView *)tv cellForRowAtIndexPath:(NSIndexPath *)indexPath 
{ 
    #pragma unused(tv) 
    #pragma unused(indexPath) 
    UITableViewCell * cell; 

    assert(tv == self.tableView); 
    assert(indexPath != NULL); 
    assert(indexPath.section < kListAdderSectionIndexCount); 
    assert(indexPath.row < ((indexPath.section == kListAdderSectionIndexNumbers) ? [self.numbers count] : 1)); 

मैं सोच रहा था, ऐसा करने का क्या मतलब है?

धन्यवाद

Answer 1

यह Design by Contract, या DbC का कार्यान्वयन है।

उद्देश्य सी के पास DbC की पूर्व-स्थितियों, पोस्ट-स्थितियों और इनवेरिएंट के लिए कोई मूल समर्थन नहीं है, लेकिन विशेष रूप से पोस्ट- और पूर्व शर्त मैक्रोज़ के साथ बहुत अच्छी तरह से लागू की जा सकती है।

यहाँ उद्देश्य सी में DbC लागू करने के लिए कुछ अन्य तरीके हैं:

• http://www.roard.com/contracts/
• http://lists.apple.com/archives/objc-language/2006/Sep/msg00000.html
• D programming languageDbC है, और यहाँ DbC की उसी शैली में मिशेल Fortins प्रयास है, लेकिन के लिए उद्देश्य सी: http://michelf.com/weblog/2010/dobjc-preliminary-design/

Answer 2

दावे की बात यह सुनिश्चित करें कि कीड़े तुरंत दिखाई, और आसानी से निदान तरीकों से बनाने के लिए, के रूप में सूक्ष्म दुर्व्यवहार के बजाय बाद में है। इस मामले में, उस कोड का डेवलपर यह गारंटी देना चाहता है कि उनके कोड चलाने के बाद 4 स्थितियां हों।

Answer 3

आवेदक प्रोग्रामर की धारणाओं को जांचते हैं कि कोड कैसे लागू किया जाएगा। यदि धारणाएं गलत हैं, तो जोर विफल हो जाएगा और अपवाद फेंक देगा। इससे कोड जितनी जल्दी हो सके विफल हो जाता है।

यह करना है या नहीं, बहस का मुद्दा है। इसे बहुत दूर ले जाया जा सकता है।