क्या डेल्फी का एक्जिट स्टेटमेंट खतरनाक है?

Question

डेल्फी के Exit बयान के बारे में पढ़ना (उदाहरण के लिए here देखें), मैं नजरअंदाज नहीं कर सकते इसके बारे में हर लेखक लिख कर्तव्य का मानना ​​है कि सलाह का एक टुकड़ा देने के लिए, उदाहरण के लिए:

चेतावनी: सावधानी से उपयोग - कूद है संरचित कोडिंग के साथ बाधाओं पर एक अवधारणा - यह कोड रखरखाव को मुश्किल बनाता है।

अब, मैं यूनिक्स में C और C++ से आ रहा हूँ और मैं फिर से entrancy मुद्दों से परिचित हूँ, लेकिन ईमानदारी से मैं क्यों डेल्फी में एक समारोह से लौट रहे को समझ नहीं सकता से पहले यह अपनी प्राकृतिक अंत तक पहुंच होनी चाहिए बुराई।

जब तक डेल्फी में प्रत्येक कार्य और प्रक्रिया को पुन: प्रवेशकर्ता के रूप में नहीं माना जाता है।

मुझे क्या याद आ रही है?

Answer 1

विचार के दो स्कूल हैं।

विचारों का एक स्कूल कहता है कि कार्यों में एक ही निकास बिंदु होना चाहिए। कई कोडिंग मानकों को एक नियम के रूप में लागू करते हैं। इसके लिए प्रेरणा गेटोस, एकाधिक निकास आदि के साथ बड़े कार्यों से भरे स्पेगेटी कोड को बनाए रखने के कठिन अनुभव से आती है।

विचार के दूसरे स्कूल का कहना है कि स्पेगेटी कोड खराब है लेकिन किसी को व्यावहारिक और न्यायिक नियमों के बजाए अपनी योग्यता पर कोडिंग शैलियों का न्याय करना चाहिए। उदाहरण के लिए, कई प्रोग्रामर महसूस करते हैं कि जब आप exit का उपयोग करने से बचते हैं तो गहरा इंडेंट किए गए कार्यों के लिए गार्ड क्लॉज बहुत बेहतर होते हैं। एक उदाहरण के रूप में मार्टिन फाउलर के उत्कृष्ट रिफैक्टरिंग कैटलॉग से निम्नलिखित उदाहरण पर विचार करें: Replace Nested Conditional with Guard Clauses।

मूल रूप से यह सब व्यक्तिगत वरीयता के लिए नीचे आता है। मैं व्यक्तिगत रूप से गार्ड क्लॉज के उपयोग को प्रोत्साहित करता हूं, लेकिन लंबी प्रक्रियाओं में बाहर निकलने के जंगली उपयोग से बचता हूं।

Answer 2

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

if aLocalObject.CheckSomeValue(aParameter) <> RIGHT_VALUE then Exit; 

और हाँ, मैं वास्तव में उस तरह सामान देखा है से पहले, दुर्भाग्य से। :(

समस्याओं का एक बहुत अंगूठे के कुछ नियमों के साथ कम किया जा सकता है:

• हमेशा अपने स्वयं के लाइन पर Exit (और Break और Continue) बयान कर दिया यह उनके लिए कठिन याद करता है
।।
• बड़े पैमाने पर छोटे तरीकों का पक्ष लें, और जब उचित हो तो छोटे तरीकों को तोड़ दें। (जब उचित हो! यह एक पूर्ण नियम नहीं है, और इसे बहुत उत्साह से लागू करने से चीजों को बेहतर तरीके से बदतर बना दिया जा सकता है। आइंस्टीन के उद्धरण को ध्यान में रखें: "सब कुछ यथासंभव सरल बनाएं, लेकिन आसान नहीं।")
• try/finally ब्लॉक का उपयोग करना सीखें ताकि Exit किसी प्रक्रिया से बाहर निकलने के बिना लीक या भ्रष्टाचार के बिना सुरक्षित किया जा सके।

Answer 3

कई चीजों की तरह, कुछ मामलों में बाहर निकलना उपयोगी है, न कि दूसरों में।मुझे उन छोटे कार्यों में अमूल्य लगता है जो कुछ कंटेनर के माध्यम से खोजते हैं, एक ऑब्जेक्ट को कंटेनर से लूप के अंदर 'परिणाम' में लोड करते हैं और मिलान करने वाली संपत्ति की तलाश करते हैं। यदि पाया जाता है, तो फ़ंक्शन बस बाहर निकल सकता है, यदि नहीं, तो परिणाम 'सामान्य' रिटर्न से ठीक पहले लूप के बाद शून्य पर सेट किया जा सकता है।

इसके अलावा, निश्चित रूप से वहाँ कुछ डेवलपर्स जो है, जबकि डीबगिंग, एक प्रक्रिया के शीर्ष पर एक 'exit' में shoved नहीं किया है यह क्रियान्वित करने को रोकने के लिए हो सकता है ...

मैं केवल उठाया अंक के साथ सहमत कर सकते हैं अन्य पोस्टर फिर से। गार्ड क्लॉज, बड़े, जटिल प्रक्रियाओं आदि में दफन किए गए हैं

Answer 4

डेविड और मेसन के शानदार उत्तरों के अलावा, मैं अपना व्यक्तिगत Exit उपयोग पसंदीदा साझा करना चाहता हूं। आइए इसे "सुरक्षित गार्ड", "अंतिम रिज़ॉर्ट प्रदाता" के विपरीत, इसे कॉल करें। ;)

मूल विचार: this answer से

function Search(List: TList; Item: TObject): Integer; 
begin 
    for Result := 0 to List.Count - 1 do 
    if List[Result] = Item then 
     Exit; 
    Result := -1; 
end; 

अन्य अधिक यथार्थवादी उदाहरण (और this answer):

const 
    Order: array[0..6] of String = ('B', 'C', 'A', 'D', 'G', 'F', 'E'); 

function GetStringOrder(const S: String; CaseSensitive: Boolean): Integer; 
begin 
    for Result := 0 to Length(Order) - 1 do 
    if (CaseSensitive and (CompareStr(Order[Result], S) = 0)) or 
     (not CaseSensitive and (CompareText(Order[Result], S) = 0)) then 
     Exit; 
    Result := Length(Order); 
end; 

function FindControlAtPos(Window: TWinControl; const ScreenPos: TPoint): TControl; 
var 
    I: Integer; 
    C: TControl; 
begin 
    for I := Window.ControlCount - 1 downto 0 do 
    begin 
    C := Window.Controls[I]; 
    if C.Visible and PtInRect(C.ClientRect, C.ScreenToClient(ScreenPos)) then 
    begin 
     if C is TWinControl then 
     Result := FindControlAtPos(TWinControl(C), ScreenPos) 
     else 
     Result := C; 
     Exit; 
    end; 
    end; 
    Result := Window; 
end; 

और डेल्फी की मदद से एक उद्धरण के साथ समापन कंपाइलर त्रुटि संदेश फॉर-लूप वीए पर riable '< तत्व> "पाश के बाद अपरिभाषित जा सकता है:

आप केवल लूप नियंत्रण चर के लिए एक के अंतिम मूल्य पर भरोसा कर सकते अगर पाश एक गोटो या बाहर निकलने के बयान के साथ छोड़ दिया है।