2012-06-11 11 views
9

मिसरा 14.5 का कहना है कि जारी बयान का उपयोग नहीं किया जाना चाहिए। क्या कोई कारण बता सकता है? धन्यवाद।मिसरा सी: 2004 में "जारी" क्यों सी उल्लंघन के रूप में माना जाता है?

+6

क्या आपने उनके कारण से * उनसे पूछा है? –

+5

सभी "हमेशा" और "कभी नहीं" नियमों के साथ, वे शायद अधिक ध्यान देने योग्य नहीं हैं। –

उत्तर

16

यह ancient debate about goto, बिना शर्त शाखा और स्पेगेटी कोड की वजह से है, जो कि 40 साल या उससे भी अधिक समय तक चल रहा है। goto, continue, break और एकाधिक return कथन सभी को कम या ज्यादा समान माना जाता है।

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

चूंकि मिसरा-सी महत्वपूर्ण प्रणालियों की ओर लक्षित है, मिसरा-सी: 2004 में इनमें से कई बिना शर्त शाखा सुविधाओं को प्रतिबंधित करने का दृष्टिकोण है। इसलिए, goto, continue और एकाधिक रिटर्न पर प्रतिबंध लगा दिया गया था। break केवल उसी लूप के अंदर एक ही ब्रेक होने पर ही अनुमति दी गई थी।

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

गोटो बहस आज भी मजबूत जा रहा है ...

5

सी प्रोग्रामिंग कई निष्पादन शाखाओं का ट्रैक रखने के लिए कुख्यात रूप से कठिन बनाता है। यदि आप कहीं भी संसाधन आवंटित करते हैं, तो आपको उन्हें कहीं और, स्थानीय रूप से जारी करना होगा। यदि आपकी कोड शाखाएं हैं, तो आपको सामान्य रूप से प्रत्येक शाखा या किसी दायरे से बाहर निकलने के तरीके के लिए अलग-अलग डेलोकेशन तर्क की आवश्यकता होगी।

continue बयान एक और तरीका एक for पाश के दायरे से बाहर निकलने के लिए कहते हैं, और इस तरह के बारे में कारण और सभी संभव तरीकों से नियंत्रित कर इसके माध्यम से प्रवाह कर सकते हैं, जो बदले में यह मुश्किल बना देता है को समझने के लिए इस तरह के एक पाश कठिन बना देता है यह सुनिश्चित करने के लिए कि आपका कोड सभी परिस्थितियों में सही तरीके से व्यवहार करता है।

यह सिर्फ मेरे हिस्से पर अटकलें है, लेकिन मुझे लगता है कि इस अतिरिक्त शाखा व्यवहार से आने वाली जटिलता को सीमित करने की कोशिश करना आपके द्वारा उल्लेख किए जाने वाले नियम के लिए ड्राइविंग कारण है।

+5

आईएमओ, यदि जारी रहता है तो लूप को समझने में कठिनाई होती है, तो लूप कोड बहुत लंबा होता है .... –

+0

@ मिच व्हाट: हाँ। आपको "कोई लंबा लूप" नियम जोड़ने के लिए मिसा को लॉबी करना चाहिए! (लेकिन व्यक्तिगत रूप से, सी ++ में, मुझे लगता है कि यह एक आसान 'जारी रखें' के साथ इनपुट पार्स करते समय टिप्पणी लाइनों को छोड़ने में सक्षम होने के लिए कहता है। फिर, सी ++ "प्रारंभिक निकास" मुहावरे के लिए एक और अधिक उपयुक्त भाषा है। –

+3

प्वाइंटलेस: अनुभव से, कोडिंग मानकों को उनके सबसे कम आम denominator के लिए अक्सर डूब दिया जाता है। मैं सी/सी ++/सी # में जारी रखने का उपयोग करता हूं यह एक बिल्कुल अच्छा निर्माण है। –

1

सभी मिश्रा नियमों के साथ के रूप में, यदि आप इसे सही साबित कर सकते हैं, तो आप नियम (खंड 4.3.2 मिश्रा सी: 2004) से विचलित कर सकते हैं

मिसा (और अन्य समान दिशानिर्देश) के पीछे बिंदु उन चीजों को फँसाना है जो आम तौर पर समस्याएं पैदा करते हैं ... हाँ, continue का उपयोग ठीक से किया जा सकता है, लेकिन सबूतों ने सुझाव दिया कि यह समस्या का एक आम कारण था।

इस तरह, मिसा ने अपने (एबी) उपयोग को रोकने के लिए एक नियम बनाया, और समीक्षा समुदाय ने नियम को मंजूरी दे दी। और उपयोगकर्ता समुदाय के विचार आम तौर पर नियम के सहायक होते हैं।

लेकिन अगर आप वास्तव में इसका उपयोग करना चाहते हैं, तो मैं दोहराता हूं, और आप इसे अपनी कंपनी पदानुक्रम में विचलित कर सकते हैं।

संबंधित मुद्दे