0 वापस करना चाहिए; मुख्य() में से बचा जाना चाहिए?

Question

मुझे पता है कि मौजूदा सी ++ मानक विशेष मामले main ताकि अंत में गिरने से अवांछित व्यवहार के बजाय return 0; जैसा ही प्रभाव हो।

मैं हाल ही में an example at codereview जहां प्रतिक्रियाओं केवल बाहर नहीं बताया कि अंतिम return 0; सहित वैकल्पिक है देख कर हैरान था, लेकिन वास्तव में अब तक के रूप में यह मूल कोड से हटाने चला गया।

इस प्रकार मेरे प्रश्न — को संकेत देता है क्या इसे वास्तव में return 0; मुख्य के अंत में स्पष्ट बनाने के लिए बुरी शैली माना जाता है? इसके लिए या तर्क के लिए तर्क क्या है?

Answer 1

सी ++ से, 3.6.1 मुख्य समारोह

(3.6.1/5) एक कार्यान्वयन मुख्य कार्य पूर्वनिर्धारित नहीं होगी। यह फ़ंक्शन ओवरलोड नहीं किया जाएगा। इसमें वापसी प्रकार int होगा, लेकिन अन्यथा इसका प्रकार कार्यान्वयन-परिभाषित है। सभी कार्यान्वयन मुख्य की निम्नलिखित परिभाषा के दोनों के लिए अनुमति देने होंगे:

int main() { /* ... */ } और

int main(int argc, char* argv[]) { /* ... */ }

तो C++, main समारोह के लिए दो प्रमुख हस्ताक्षर हैं: int main() और int main(int argc, char** argv)

आगे सी ++ में, 3.6.1 मुख्य कार्य

(3.6.1/5) मुख्य में एक वापसी कथन मुख्य कार्य (स्वचालित भंडारण अवधि के साथ किसी भी वस्तुओं को नष्ट करने) छोड़ने और तर्क के रूप में वापसी मान के साथ बाहर निकलने को बुलाने की प्रभाव पड़ता है। यदि नियंत्रण रिटर्न स्टेटमेंट का सामना किए बिना मुख्य के अंत तक पहुंच जाता है, तो प्रभाव 0 निष्पादित करने का प्रभाव है;

तो, हालांकि हस्ताक्षर बताते हैं कि फ़ंक्शन को कुछ पूर्णांक वापस करना चाहिए, यह return 0 के लिए आवश्यक नहीं है। डिफ़ॉल्ट रूप से, सी ++ समझता है वापसी मान 0.

लाभ होने के लिए:
- सामान्य कार्य के रूप में main इलाज और इसी तरह सी निम्नलिखित ++ सम्मेलन
कोडिंग - return 0 स्पष्ट रूप से, सामान्य वापसी मान निर्दिष्ट अन्य मामलों में हम गैर लौट सकते हैं -जेरो मूल्य

हालांकि, ये सभी बिंदु कोडिंग सम्मेलन का विषय हैं। यह अभी भी प्रोग्रामर की पसंद है!

Answer 2

मैं अंधेरे यहाँ में एक जंगली चाकू ले लेंगे और कहते हैं कि लोगों को दो खेमों में आते हैं:

• जो लोग लाइन को दूर लगता है कि यह अनावश्यक है और ऐसे सभी कोड संक्षिप्तता के लिए हटा दिया जाना चाहिए

• जो लोग लाइन को जोड़ने लगता है कि यह वापसी मान स्पष्ट और कम कोडर को स्पष्ट करता है।

व्यक्तिगत रूप से, मैं हमेशा अपने उत्पादन कोड में main में एक सार्थक return बयान लिखने के लिए (यदि केवल क्योंकि मेरी उत्पादन main रों भी कोड रास्तों कि 0 के अलावा कुछ लौटने अंत को रोकने के लिए करते हैं जाते हैं, आमतौर पर अपवाद हैंडलर में), हालांकि मैं एक छोटे से main के लिए परेशान नहीं होगा जो कभी और कुछ नहीं लौटाता; उदाहरण के लिए, मुझे नहीं लगता कि मैं कभी तो में किया, कहते हैं, एक स्टैक ओवरफ़्लो प्रदर्शन के लिए एक Coliru पोस्ट किया है।

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

लेकिन मैं कहना चाहता हूँ यह लगभग पूरी तरह से निर्भर करता है कि आपके पर्यावरण की तरह है पर। यदि आप रिलीज चक्र के माध्यम से आधा रास्ते हैं, तो निश्चित रूप से आप कोड रखरखाव सुधार और शैली समायोजन करने जा रहे हैं: यह तकनीकी ऋण अर्जित करने से बचने का सबसे अच्छा समय है, और आप बिल्कुल ऐसा करना चाहते हैं। लेकिन यदि आप इस बदलाव को सीधे उत्पादन सर्वर पर या संस्करण नियंत्रण में उस बड़ी रिलीज से एक सप्ताह पहले बनाने की योजना बना रहे हैं, तो आप अपने दिमाग से बाहर हैं।

कह रही है कि अंतर्निहित विकल्प बहुत ही व्यक्तिपरक है बिना, (उम्मीद है कि अपनी नीतियों में इस तरह के पागलपन वैसे भी रोकने के लिए। कोड फ्रीज, हाँ? उत्पादन में कोई परिवर्तन नहीं, है ना?)

इसलिए, भले ही यह जाता है हम तथ्य के बाद ऐसी पसंद को लागू करने के जोखिम/लाभ को प्रमाणित कर सकते हैं।

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