क्या ELSE खराब प्रोग्रामिंग का उपयोग कर रहा है? [बन्द है]

Question

मैं अक्सर उन बग्स पर आता हूं जो ELSEनिर्माण का उपयोग करने के कारण हुए हैं । एक प्रमुख उदाहरण कुछ इस प्रकार है:

If (passwordCheck() == false){
    displayMessage();
}else{
    letThemIn();
}

मेरे लिए यह सुरक्षा समस्या चिल्लाती है। मुझे पता है कि पासवर्ड चेक एक बूलियन होने की संभावना है, लेकिन मैं इस पर अपने अनुप्रयोगों की सुरक्षा नहीं करूंगा। क्या होगा अगर इसकी एक स्ट्रिंग, इंट आदि।

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

निश्चित रूप से यह कीड़े / सुरक्षा मुद्दों को आपके ऐप में प्रवेश करने से रोकने का एक बेहतर तरीका है।

तुम लोग यह कैसे करते हो?

Comments

आपके लिए सुरक्षा समस्या क्या है? "पासवर्ड चेक" का क्या अर्थ है? पासवर्ड की जाँच थी? पासवर्ड चेक करने की आवश्यकता है? उपयोगकर्ता बीत चुका है? उपयोगकर्ता सही पासवर्ड दर्ज करने में विफल रहा है?

— LennyProgrammers

I know that passwordCheck is likely to be a boolean...क्या मतलब? किसी भी मजबूत-टाइप भाषा में। तुमpasswordCheck जो होना चाहोगे वह होगा।

— बॉबी

मुझे लगता है कि खराब इंडेंटेशन प्रथाएं elseबयानों का उपयोग करने की तुलना में अधिक त्रुटियों का कारण

— बनती हैं

यह अजीब लगता है। सबसे पहले, आप संभावित रिटर्न प्रकार के बारे में शिकायत करते हैं जो passwordCheck()संभवतः बूलियन नहीं है (जो एक उचित चिंता हो सकती है), और फिर आप इसे दोष देते हैं else? मैं यह नहीं देखता कि क्या elseकारण हैं।

— डेविड थॉर्नले

एमएमएम, मुझे लगता है कि यह पूछने पर कि क्या अन्य प्रोग्रामिंग खराब प्रोग्रामिंग है, खराब प्रोग्रामिंग है

— मुदा डिब

Answer 1

elseब्लॉक हमेशा क्या आप डिफ़ॉल्ट व्यवहार होना चाहता हूँ होनी चाहिए।

इनसे बचने की कोई आवश्यकता नहीं है, बस इनका उचित उपयोग करने में सावधानी बरतें।

आपके उदाहरण में, डिफ़ॉल्ट स्थिति तक पहुंच की अनुमति नहीं होनी चाहिए। एक छोटे से refactoring आप के साथ छोड़ देता है:

If (passwordCheck)
{
   letThemIn();
}
else
{
   displayMessage();
}

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

आप निश्चित else ifरूप से पूरी तरह से अलग ifबयानों के बजाय तर्क का अतिरिक्त चेक जोड़ सकते हैं ।

Comments

@ dave.b उदाहरण के संदर्भ में, मुझे लगता है कि यह एक सुरक्षा मुद्दा होगा, लेकिन अगर यह सब कोड आधार के उस स्थान पर है जिसे आप देख रहे हैं, तो यह अधिक संकेत है कि जिसने भी इसे लिखा है उसे इसकी थोड़ी और आवश्यकता है अभ्यास :)

— RYFN

क्या कोई इस के सुरक्षा पहलू पर विस्तार से बता सकता है? if (कुछ) {do a} और {do b} बनाम अगर (कुछ) {do b} और {do a} लॉगऑन समतुल्य नहीं है? मैं यह समझने की कोशिश कर रहा हूं कि इस की सुरक्षा के संदर्भ में क्या अंतर है?

— क्रिस

@ क्रिस: मुझे लगता है कि ओपी एक कमजोर टाइप की भाषा का उपयोग करता है। इसलिए passwordCheckकुछ भी, फ़े हो सकता है null, जो प्रस्तुत करना होगा passwordCheck == falseकरने के लिए falseऔर उपयोगकर्ता एक आंतरिक त्रुटि के कारण लॉगिन करने की अनुमति होगी।

— बॉबी

@ क्रिस, मेरी समझ यह थी कि डिफ़ॉल्ट स्थिति को एक्सेस करने की अनुमति थी, जो जरूरी नहीं कि उचित हो।

— RYFN

हां, यह बहुत भाषा पर निर्भर है। C # में, जहां ifएक की आवश्यकता होती है bool, चर निश्चित रूप से असाइन किए जाने चाहिए, सभी रास्तों को एक मूल्य वापस करना होगा, आदि, मैं किसी भी कारण के बारे में नहीं सोच सकता हूं ifऔर elseपठनीयता के अलावा मायने रखेगा। अर्थात्, के if(a){b();}{c();}बराबर होना चाहिए if(!a){c();{b();}। दूसरी ओर, जावास्क्रिप्ट में, आपको पता होना चाहिए कि passwordCheckक्या हो सकता है undefined, आदि

— टिम गुडमैन

Answer 2

नहीं, इसमें कुछ गलत नहीं है ELSE। ELSEनया नहीं है GOTO। वास्तव में, इसके IFबजाय दो एस का ELSEउपयोग करने से कई समस्याएं हो सकती हैं।

एक उदाहरण:

if (this(is(a(very())==complex(check())))) {
   doSomething();
}

if (!this(is(a(very())==complex(check())))) {
   doTheOtherThing();
}

आप कॉपी-पेस्ट देखते हैं? यह उस दिन की प्रतीक्षा करता है जब आप एक को बदलते हैं और दूसरे को भूल जाते हैं।

उदाहरण दो:

foreach(x in y) {
  if (first_time) {
    first_time = false;
    doSomething();
  }

  if (!first_time) {
    doTheOtherThing();
  }
}

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

Comments

मैं इससे सहमत हु। एक कॉपी-पेस्ट ifबयान और उसके बूलियन अभिव्यक्ति inverting बस से बचने के लिए एक else- अब है कि बुरा प्रोग्रामिंग है! न केवल आप कोड ( खराब प्रोग्रामिंग) की नकल कर रहे हैं, आप प्रदर्शन को धीमा कर रहे हैं (यदि चेक वास्तव में जटिल है, तो आप अब इसे दो बार कर रहे हैं - ba-- उह, ठीक है, आप जानते हैं कि वे समय से पहले अनुकूलन के बारे में क्या कहते हैं आजकल ... इतना अच्छा कार्यक्रम नहीं!)।

— गाब्लिन

ईमानदारी से कहा जाए कि अगर जाँच सही / गलत होने के लिए स्वयं की एक विधि में होनी चाहिए

— billy.bob

अच्छा उदाहरण है, अगर एक दूसरे के साथ जोड़ा जाता है तो चेक बनाम एक का उपयोग करने के प्रदर्शन को नहीं भूलना चाहिए। मैं अधिकांश भाषाओं में मान सकता हूँ कि यदि कोई शर्त का उपयोग नहीं कर रहा है तो एक के साथ कथन का उपयोग करने से बेहतर होगा।

— क्रिस

dave.b: यकीन है, लेकिन यह सरल शुरू कर सकता है और धीरे-धीरे बढ़ सकता है; मेरे उदाहरण में जटिल जाँच समस्या को और अधिक स्पष्ट करने के लिए यहाँ है।

— user281377

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

— डेविड थॉर्नले

Answer 3

हमेशा एक ELSE होता है। अगर आप लिखेंगे

if(foo)
  bar();

आप वास्तव में लिखते हैं

if(foo)
{
  bar();
}
else
{
   // do nothing
}

ईएलएसई-पथ में आप जो भी डालते हैं वह आपकी जिम्मेदारी है।

Comments

-1। यह जवाब बहुत हास्यास्पद है। मैं यह नहीं कह रहा हूं कि यह सच नहीं है। यह सिर्फ बात याद आती है। आपके कोड से जो कंपाइल उत्पन्न होता है उसका कोडिंग प्रैक्टिस और बग के साथ कोई लेना-देना नहीं है

सवाल था "क्या ईएलएसई खराब प्रोग्रामिंग का उपयोग कर रहा है?"। मेरा उत्तर है: आप दिखावा कर सकते हैं कि यह वहां नहीं है, लेकिन इसे टालें नहीं।

— लेनीप्रोग्रामर्स

क्या भाषा ? जावा में अन्य bytecode में नहीं है: P

— IAdapter

@ acidzombie24 - किसी भी प्रश्न से 'और' क्या है, इस पर विचार करना बहुत अच्छा अभ्यास है। कभी-कभी यह बस है - फ़्यूचियन में हर दूसरे को क्या करना है, लेकिन यह आपको दिखाता है कि आपने इसके बारे में सोचा है

— मार्टिन बेकेट

Answer 4

मैं व्यक्तिगत elseरूप से जितना हो सकता है, उससे बचता हूं, लेकिन यह किसी भी सुरक्षा समस्या के लिए नहीं है।

कोड पढ़ते समय, नेस्टेड स्टेटमेंट्स को तर्क का पालन करना कठिन हो जाता है, क्योंकि आपको यह याद रखने की आवश्यकता है कि कौन सी स्थितियों का सेट वहां ले जाएगा। इस कारण से, मैं जल्दी बाहर निकलने का बहुत बड़ा प्रशंसक हूं:

if (checkPassword != OK) { displayMessage(); return; }

letThemIn();

यह भी लागू होता है forऔर whileलूप में होता है , जिसमें मैं उपयोग करता हूं continueऔर breakजब भी यह इंडेंटेशन के स्तर से बचा जाता है।

क्रिस लॅटनर का कहना है कि एलएलवीएम कोडिंग मानकों में मैं इससे बेहतर हूं ।

Comments

मैं सहमत हूँ। "और" एक मानसिक "कांटा" बनाता है और हम इंसान अनुक्रमिक प्राणी हैं।

— user187291

Fyi, इसे गार्ड की स्थिति कहा जाता है

— CaffGeek

@Chad: आह धन्यवाद, हमेशा चीजों के लिए नाम पाने के लिए अच्छा है :)

— Matthieu M.

+1। यह एकमात्र उत्तर है जो मैं खड़ा कर सकता हूं जिसका स्कोर> 1 है। *writes an answer*

मैं इस तरह से बचने की कोशिश नहीं करता, लेकिन मुझे लगता है कि आप जो लिखते हैं, मैं उससे सहमत हूं। मुद्दा यह है कि आप जिस चीज का परीक्षण कर रहे हैं, वह अपवाद होनी चाहिए न कि सामान्य स्थिति ( stackoverflow.com/questions/114342-… )। यहां प्रमाणीकरण विफलता अपवाद है और (केवल) जिसे परीक्षण किया जाना चाहिए।

— २२:०

Answer 5

तो बस उन्हें बदलें,

If (passwordCheck == true)
{
     letThemIn();
}
else
{
     displayMessage();
}

Comments

कैसे के बारे में If ((passwordCheck == true) == true)? :-)

— हिप्पो

वैसे यह मेरी शैली है, पठनीयता में सुधार लाने के लिए। आप लिख सकते हैं अगर ((मूल्य) लेकिन मैं पसंद करता हूँ अगर (मान! = सच)

— अहमेत काकसी

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

— ak2

यदि चर नाम वर्णनात्मक है, तो कोई कारण नहीं है: यदि (someBooleanValue == true) आवश्यक होना चाहिए। यह बेहतर होगा: अगर (वैधपद) {...

— मार्क फ्रीडमैन

खैर मैं सिर्फ सवाल के भीतर कोड ब्लॉक की जगह। यदि आप मेरी पहली टिप्पणी पढ़ते हैं तो मैंने कहा कि मैं अगर (मान! = सही) का उपयोग करना पसंद करता हूं तो इसके बजाय (मान)। मुझे उम्मीद है कि आप (मान) और अगर (मूल्य) के बीच अंतर देख सकते हैं। मेरा मतलब था कि मैं पूरक ऑपरेटर का उपयोग नहीं करता हूं। अन्यथा आप सही हैं, सही का मतलब सच है।

— अहमत काकसी

Answer 6

मैथ्यू एम की तरह, मैं गहराई से नेस्टेड ब्लॉक से जल्दी बाहर निकलने को प्राथमिकता देता हूं ... यह अच्छी तरह से रक्षात्मक प्रोग्रामिंग दिखाता है (यदि खराब स्थिति, जारी रखने का कोई मतलब नहीं है)। बहुत से लोग हमारे साथ असहमत होंगे, एक अनोखा निकास बिंदु पसंद करते हुए; यह बहस का मुद्दा नहीं है (मुझे लगता है)।

अब, मैं निश्चित रूप से उपयोग करता हूं elseजब यह समझ में आता है, विशेष रूप से सरल, छोटे विकल्पों के लिए। जैसा कि कहा गया है, परीक्षण की नकल करना समय की बर्बादी है (प्रोग्रामर और सीपीयू की), भ्रम का स्रोत और, बाद में, बग का (जब एक को बदला जाता है, दूसरे को नहीं)।
कभी-कभी, मैं इस elseभाग पर एक टिप्पणी जोड़ता हूं , यह याद दिलाता है कि क्या स्थिति थी (विशेषकर यदि ifभाग लंबा है, उदाहरण के लिए, विरासत कोड में) या विकल्प क्या है।

ध्यान दें कि कार्यात्मक प्रोग्रामिंग के कुछ चरम प्रस्तावक पूरी तरह से छुटकारा पाने का प्रस्ताव करते हैं if, पैटर्न मिलान के पक्ष में ... मेरे स्वाद के लिए थोड़ा बहुत चरम। :-)

Comments

एक साइड नोट के रूप में: यदि आपके पास अपनी शुद्ध कार्यात्मक भाषा में निर्माण है, तो आपको वास्तव में एक और होना चाहिए। हर अभिव्यक्ति को कुछ लौटाना होगा!

— टोकलैंड

Answer 7

ELSE का उपयोग करने में कुछ भी गलत नहीं है। हालांकि यह अत्यधिक जटिल कोड को जन्म दे सकता है जो पढ़ने और समझने में कठिन है। यह खराब डिज़ाइन का संकेत हो सकता है। यह निश्चित रूप से अतिरिक्त उपयोग के मामलों को इंगित करता है जिन्हें परीक्षण करने की आवश्यकता होगी।

यदि आप कर सकते हैं तो ELSE को हटाने का प्रयास करें - लेकिन इसके बारे में पागल मत बनो। स्टीव मैककोनेल इस सीधी रेखा कोड को कोड कंप्लीट में कहते हैं। यानी आपके कोड के माध्यम से एक सरल स्पष्ट रास्ता है।

आपकी विशेष समस्या के लिए प्रयास करने के लिए दृष्टिकोण:

• बहुरूपता का उपयोग करें। अपने सिस्टम की सीमा पर उपयोगकर्ता की सुरक्षा साख को मान्य करें। यदि वे वैध हैं तो एक सत्र वस्तु लौटाएं - सिस्टम के संबंधित भागों तक पहुंच के साथ या अपवाद फेंकें। हालाँकि यह आपको अधिक जटिल बना सकता है। तो आप तय करें कि समझने और बनाए रखने में क्या आसान है।

सामान्य तौर पर - निम्नलिखित आपके कोड में ईएलएसई को कम करने में मदद कर सकता है:

• अच्छी आवश्यकताएं कोड में ऐसे निर्णयों की आवश्यकता को कम कर सकती हैं। आपको उपयोग मामले (और) को लागू करने की आवश्यकता नहीं हो सकती है।
• स्पष्ट डिजाइन। अधिकतम सामंजस्य और कम से कम युग्मन। यह सुनिश्चित करता है कि घटक अन्य घटकों में किए गए निर्णयों की नकल नहीं कर रहे हैं।
• त्रुटि मामलों को प्रबंधित करने के लिए अपवाद हैंडलिंग।
• बहुरूपता (ऊपर उदाहरण देखें)।
• स्विच स्टेटमेंट - ये ईएलएसई का महिमामंडन करते हैं लेकिन कुछ स्थितियों में बेहतर होते हैं।

Comments

मैं "एक अलग फ़ंक्शन में जटिल बूलियन चेक ले जाना" भी शामिल करूंगा।

— गाब्लिन

Answer 8

सुरक्षा रिसाव होने वाले कोड के बारे में आपका तर्क आपके द्वारा उपयोग की जा रही भाषा के आधार पर सही हो सकता है या नहीं भी हो सकता है । सी कोड में यह एक समस्या हो सकती है (विशेष रूप से क्योंकि सी में एक बूलियन सिर्फ एक ऐसा उदाहरण है जो गैर-शून्य या शून्य है) - लेकिन सबसे दृढ़ता से टाइप की गई भाषाओं में (यानी रनटाइम प्रकार की जाँच) यदि passwordCheckचर बूलियन के रूप में घोषित किया गया था, इसके लिए कुछ और असाइन करने का कोई तरीका नहीं है। वास्तव में, एक ifविधेय में सब कुछ एक बूलियन को हल करना चाहिए, चाहे आप बूलियन ऑपरेटरों का उपयोग करें या बस मूल्य का उपयोग करें। यदि आप passwordCheckरनटाइम से बंधी हुई किसी अन्य प्रकार की ऑब्जेक्ट को प्रबंधित करने में कामयाब होते हैं तो कुछ प्रकार के अवैध कास्ट अपवाद को फेंक देंगे।

अगर कोई निर्माण करता है, तो सरल / अगर अन्य निर्माणों को पढ़ने में बहुत आसान है, अगर / अगर निर्माण करता है - और कम अनजाने समस्याओं का खतरा है। चलो एक दूसरे के लिए एक ही उदाहरण लेते हैं:

if(passwordCheck == false) {
    denyAccess();
}

if(passwordCheck) {
    letThemIn();
}

परस्पर अनन्य उपवाक्य का अर्थ जिसे आप ऊपर निष्पादित करना चाहते हैं वह खो गया है। यह है कि क्या / अन्यथा निर्माण बता देते हैं। निष्पादन की दो परस्पर अनन्य शाखाएँ, जहाँ उनमें से एक हमेशा चलेगी। यह सुरक्षा का एक महत्वपूर्ण हिस्सा है - यह सुनिश्चित करना कि letThemInआपके बुलाए जाने के बाद कोई रास्ता नहीं है denyAccess।

कोड स्पष्टता के उद्देश्य के लिए, और यह सुनिश्चित करने के लिए कि महत्वपूर्ण खंड सबसे अधिक संरक्षित हैं, उन्हें प्राथमिक खंड ( ifभाग) के अंदर होना चाहिए । डिफ़ॉल्ट गैर-अनुरूप व्यवहार वैकल्पिक खंड ( elseभाग) में होना चाहिए । उदाहरण के लिए:

if(passwordCheck) {
    letThemIn();
} else {
    denyAccess();
}

नोट: विभिन्न भाषाओं के साथ काम करने में, मैंने एक कोडिंग हब विकसित किया है जो "अगर यह एक स्ट्रिंग है तो" के सवाल से बचने में मदद करता है? अनिवार्य रूप से, यह निरंतर पहले बूलियन अभिव्यक्ति में रखना है। उदाहरण के लिए, जाँच के बजाय passwordCheck == falseमैं जाँच कर रहा हूँ false == passwordCheck। यह C ++ में आकस्मिक असाइनमेंट समस्या से भी बचता है। इस दृष्टिकोण का उपयोग करते हुए, कंपाइलर शिकायत करेगा यदि मैं =इसके बजाय टाइप करता हूं ==। जावा और C # जैसी भाषाओं में, कंपाइलर असाइनमेंट को क्लॉज में त्रुटि मान लेगा, लेकिन C ++ इसे खुशी-खुशी स्वीकार कर लेगा। यही कारण है कि मैं भी nullपहले के साथ शून्य जाँच करने के लिए करते हैं ।

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

Answer 9

यह कहना कि elseप्रोग्रामिंग का उपयोग करना बुरा है, यह कहने जैसा है कि otherwiseबोलने के समय का उपयोग करना बुरा है।

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

Answer 10

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

Else अपने आप में बुरा नहीं है, लेकिन यदि आप इसे खराब तरीके से उपयोग करते हैं, तो आप अवांछित प्रभाव देख सकते हैं।

इसके अलावा, अपने बयान के बारे में

"मुझे पता है कि पासवर्ड चेक एक बूलियन होने की संभावना है, लेकिन मैं इस पर अपने अनुप्रयोगों की सुरक्षा नहीं करूंगा।"

आपके द्वारा विकसित की जाने वाली विधियों के लिए, ALWAYS एक डेटा प्रकार लौटाता है। यद्यपि PHP Core कोड के साथ दो या अधिक डेटाटिप्स देता है, लेकिन यह एक बुरा अभ्यास है क्योंकि यह फ़ंक्शन कॉल का अनुमान लगाता है। यदि आपको एक से अधिक डेटा टाइप वापस करना है, तो एक अपवाद को फेंकने पर विचार करें (मुझे लगता है कि यह अक्सर यही कारण है कि मैं एक और डेटा प्रकार वापस करना चाहता हूं - कुछ बुरी तरह से, बुरी तरह से गलत हो गया), या अपने कोड को फिर से संरचित करने पर विचार करें ताकि आप केवल एक डेटा-प्रकार वापस करें।

Comments

मुझे नहीं पता था कि ऐसी भाषाएँ थीं जो एक से अधिक डेटाटाइप लौटाती थीं! क्या आप बहुरूपी कार्यों का उल्लेख कर रहे हैं? मेरा मानना ​​है कि जब भी मैं किसी फ़ंक्शन को अधिभारित करता हूं तो वह हमेशा उसी डेटाटाइप को लौटाता है, हालांकि इसमें अलग-अलग तर्क हो सकते हैं।

— माइकल के

शिथिल टाइप की भाषाओं में, और विशेष रूप से PHP में, फ़ंक्शन एक से अधिक डेटा-प्रकार वापस कर सकते हैं। उदाहरण के लिए: stristr- "रिटर्नेड द मैचिंग सब्स्ट्रिंग। यदि सुई नहीं मिली है, तो FALSE लौटाता है"

— Craige

@Michael, एक PHP फ़ंक्शन जो कुछ भी आप चाहते हैं उसे वापस कर सकते हैं। डेटाटाइप पर कोई प्रतिबंध नहीं है। मेरा सबसे जटिल फ़ंक्शन सही / गलत / अशक्त देता है, लेकिन कुछ भी नहीं है (सामान्य ज्ञान को छोड़कर) आपको एक फ़ंक्शन लिखने से रोकता है जो सच / पूर्णांक / अशक्त / स्ट्रिंग / फ्लोट / सरणी देता है।

— टीआरआईजी

दिलचस्प। मैंने PHP के साथ कभी काम नहीं किया है। हालांकि स्पष्टीकरण के लिए धन्यवाद - शायद भविष्य में मेरी मदद करो! जावास्क्रिप्ट की तरह तो?

— माइकल के

@ माइकल - वास्तव में जावास्क्रिप्ट के समान है।

— क्रेगे

Answer 11

सबसे पहले। जबरदस्त हंसी! Theres नहीं REASON से बचने के लिए, बिल्कुल भी। किसी भी तरह से इसका बुरा अभ्यास, आकार या रूप नहीं।

अगर कुछ भी कोड होना चाहिए

if(!IsLoggedIn) { ShowBadLoginOrNoAccessPage(); return }

Theres कोई दो ifs वहाँ और यह कोई और है। यह वही है जो मैं अपने सभी ऐप में करता हूं सिवाय एक जिसमें मैं एक अपवाद फेंकता हूं। अपवाद मेरे फ़ंक्शन में पकड़ा गया है जो उचित पृष्ठ दिखाने के लिए url की जांच करता है (या वैकल्पिक रूप से मैं asp.net त्रुटि फ़ंक्शन में कैच / चेक डाल सकता हूं)। यह एक सामान्य पृष्ठ प्रिंट करता है जो कहता है कि अधिकृत या जो भी संदेश मैं अपवाद में उपयोग नहीं करता हूं (मैं हमेशा अपवाद के प्रकार की जांच करता हूं और http स्थिति कोड सेट करता हूं)।

-Edit- जैसा कि बारूद के उदाहरण में दिखाया गया है दो इफ्स हास्यास्पद है। वास्तव में दूसरा उतना ही अच्छा या बेहतर है जितना कि यदि। अगर कुछ भी हो तो इससे बचा जा सकता है (हालाँकि मैं व्यक्तिगत रूप से नहीं हूँ। लेकिन मैं रिटर्न का उपयोग करता हूँ और बहुत कुछ तोड़ता हूँ) क्योंकि इसके बारे में कहा गया है कि अधिक कोड पथ कीड़े की संभावना को बढ़ाते हैं। साइक्लोमैटिक जटिलता देखें

-Edit 2- यदि आप इसके बारे में चिंतित हैं तो / और उपयोग करें। मैं यह भी ध्यान दूंगा कि मेरी प्राथमिकता सबसे छोटे कोड ब्लॉक को सबसे ऊपर रखना है

if(cond == false) {
    a()
    b()
    c()
    onetwothree()
}
else
{
    a()
    b()
    c()
    more()
    onetwothree()
    code()
    longer()
}

इसके इलावा

if(cond) 
{
    a()
    b()
    c()
    more()
    onetwothree()
    code()
    longer()
}
else
{
    a()
    b()
    c()
    onetwothree()
}

Answer 12

मैं सशर्त से पहले डिफ़ॉल्ट सेट करना पसंद करता हूं जब मैं कर सकता हूं। मुझे लगता है कि यह पढ़ना थोड़ा आसान है और थोड़ा अधिक स्पष्ट है, लेकिन यह सिर्फ एक प्राथमिकता है। मेरे पास अपने कोड में नकारात्मक स्थितियों से बचने की कोशिश करने की प्रवृत्ति है। मैं foo या झूठे == फू के लिए जाँच का एक बड़ा प्रशंसक नहीं हूं और मुझे लगता है कि एक नकारात्मक के बराबर सशर्त है।

foo = bar;

if ('fubar' == baz) {
    foo = baz;
}

के बजाय ...

if ('fubar' == baz) {
    foo = baz;
} else {
    foo = bar;
}

पिछले कोड ब्लॉक को पढ़ना मेरे लिए थोड़ा आसान लगता है। मुझे अपने कोड के बारे में एक प्रकार का संदेह होना स्वाभाविक है। किसी भी हालत की परवाह किए बिना एक डिफ़ॉल्ट सेट करना मुझे आरामदायक महसूस कराता है: पी

Answer 13

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

एक उदाहरण के रूप में, टर्नरी ऑपरेटर भी आमतौर पर अच्छे उम्मीदवार होते हैं:

If VIP Then 
  Discount = .25
Else
  Discount = 0
End If
Total = (1 - Discount) * Total

एक टर्नरी दृष्टिकोण का उपयोग करना:

Discount = VIP ? .25 : 0
Total = (1 - Discount) * Total

टर्नरी ऑपरेटर ब्रांचिंग को सही तरीके से शिफ्ट करते हैं।