इस एंटीपैटर्न के लिए नाम? स्थानीय चर के रूप में फ़ील्ड [बंद]

68

कुछ कोड में मैं समीक्षा कर रहा हूं, मैं सामान देख रहा हूं जो निम्नलिखित के नैतिक समकक्ष है:

public class Foo
{
    private Bar bar;

    public MethodA()
    {
        bar = new Bar();
        bar.A();
        bar = null;
    }

    public MethodB()
    {
        bar = new Bar();
        bar.B();
        bar = null;
    }
}

क्षेत्र barयहाँ है तार्किक एक स्थानीय चर, के रूप में अपने मूल्य विधि कॉल में कायम रखना इरादा कभी नहीं किया गया है। हालाँकि, कई प्रकार के तरीकों के लिए Fooएक ऑब्जेक्ट की आवश्यकता होती है Bar, मूल कोड लेखक ने केवल एक प्रकार का क्षेत्र बनाया है Bar।

यह स्पष्ट रूप से बुरा है, है ना?
क्या इस एंटीपैटर्न का कोई नाम है?

object-oriented terminology anti-patterns

— JSB ձոգչ
स्रोत

60

खैर, यह एक नया है। आशा है कि इस वर्ग का उपयोग किसी बहु-संदर्भ में नहीं किया गया है, या आपके पास आगे दिलचस्प समय होगा!

— TMN

8

यह वास्तव में असामान्य है? मैंने अपने करियर में इसे कई बार देखा है।

— JSB JS

32

@TMN यह थ्रेड सुरक्षित नहीं है, लेकिन जो बदतर है, यह भी नहीं है। यदि कोई कोड MethodAया MethodBकारण MethodAया MethodBकिसी भी तरह से बुलाया जा सकता है (और barफिर से इस्तेमाल किया bar.{A,B}()जा रहा है, तो अपराधी होने के मामले में ) आपके पास समान मुद्दे भी बिना किसी संगति के हैं।

73

क्या हमारे पास हर उस गूंगी चीज़ का नाम होना चाहिए जो कोई कर सकता है? बस इसे एक बुरा विचार कहा जाता है।

— कालेब

74

मुश्किल यह नहीं कहते हैं कि झूलना विरोधी पैटर्न को निजीकृत करता है।

— psr

86

यह स्पष्ट रूप से बुरा है, है ना?

हाँ।

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

क्या इस एंटीपैटर्न का कोई नाम है?

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

रिकॉर्ड के लिए, यह लिखने का सही तरीका है:

public class Foo
{
    public methodA()
    {
        Bar bar = new Bar();  // Use a >>local<< variable!!
        bar.a();
    }

    // Or more concisely (in this case) ...
    public methodB()
    {
        new Bar().b();
    }
}

ध्यान दें कि मैंने जावा पहचानकर्ताओं के लिए स्वीकृत शैली नियमों के अनुरूप विधि और चर नाम भी तय किए हैं।

— स्टीफन सी
स्रोत

11

मैं कहूंगा "यदि आप इसे उत्पादन कोड में देखते हैं, तो यह एक संकेत है कि आपको अपनी भर्ती प्रक्रिया को फिर से जांचना चाहिए "

— बीटा

@ बटा - वह भी, हालांकि आपको जोरदार कोड-समीक्षा के साथ खराब कोडिंग आदतों को ठीक करने में सक्षम होना चाहिए।

— स्टीफन सी।

अधिक कोड समीक्षाओं के बारे में बिट के लिए +1। इसके बावजूद कि लोग क्या सोचते हैं, हायरिंग प्रैक्टिस में सुधार से इस तरह की समस्या से बचाव नहीं होगा - हायरिंग एक बकवास-शूट है, सबसे अच्छा आप जो कर सकते हैं वह आपके पक्ष में पासा लोड करता है।

— मत्तन्ज़

@StephenC "यह तरीकों को गैर-रीएन्ट्रेंट बनाता है, जो एक समस्या है अगर उन्हें उसी उदाहरण पर पुनरावृत्ति या बहु-थ्रेडेड संदर्भ में कहा जाता है।" । मुझे पता है कि क्या पुनरावृत्ति है, लेकिन यहां इसके लिए एक बिंदु नहीं देख सकता क्योंकि विधियां किसी भी ताले का उपयोग नहीं कर रही हैं? क्या आप समझा सकते हैं

— गीक

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

— स्टीफन सी।

39

मैं इसे एक चर के लिए अनावश्यक बड़े दायरे के रूप में कहूंगा। यह सेटिंग भी दौड़ की स्थिति के लिए अनुमति देता है यदि एकाधिक थ्रेड्स MethodA और MethodB तक पहुँचते हैं।

— गु 00 m s
स्रोत

12

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

— GlenPeterson 15

30

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

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

इस मामले में doorknob सिर्फ एक संदर्भ है, इसलिए यह सस्ता है। यदि डोरकनॉब एक वास्तविक वस्तु थी (और वे केवल संदर्भ के बजाय ऑब्जेक्ट का पुन: उपयोग कर रहे थे), तो यह एक होने के लिए काफी महंगा हो सकता है prudent global doorknob। हालांकि, जब यह सस्ता होता है, तो इसे ए के रूप में जाना जाता है cheapskate global doorknob।

आपका उदाहरण cheapskateविविधता का है।

— नेड टहनी
स्रोत

19

यहां प्राथमिक चिंता संक्षिप्त रूप में होगी - यदि Foo का उपयोग कई थ्रेड द्वारा किया जा रहा है, तो आपको समस्या है।

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

— मैथ्यू फ्लिन
स्रोत

15

यह "वेरिएबल रियूज़" के एक पक्ष के साथ "अनुचित स्कूपिंग" का एक विशिष्ट मामला है।

— Ikegami
स्रोत

7

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

यह भी बहस के लिए बनाता है कि क्या कुछ एक पैटर्न है, एक विरोधी पैटर्न है, या एक गलत तरीके से लागू पैटर्न है जो अभी भी कुछ स्थानों पर उपयोग करता है।

यह सिर्फ गलत है।

थोड़ा और जोड़ना है।

यह कोड अंधविश्वास है, या सबसे अच्छा कार्गो-पंथ अभ्यास है।

एक अंधविश्वास एक स्पष्ट औचित्य के बिना किया जाता है। यह कुछ वास्तविक से संबंधित हो सकता है, लेकिन कनेक्शन तर्कसंगत नहीं है।

एक कार्गो-पंथ अभ्यास वह है जहां आप कुछ ऐसा जानने की कोशिश करते हैं, जिसे आपने अधिक जानकार स्रोत से सीखा है, लेकिन आप वास्तव में प्रक्रिया के बजाय सतह के कलाकृतियों की नकल कर रहे हैं (पापुआ न्यू गिनी में एक पंथ के लिए इसका नाम है) बांस से बाहर विमान नियंत्रण रेडियो (WWII जापानी और अमेरिकी विमानों को वापस लाने की उम्मीद)।

इन दोनों मामलों में कोई वास्तविक मामला नहीं बनता है।

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

जैसे, एक एंटी-पैटर्न कुछ ऐसा है जो एक स्मार्ट व्यक्ति जो भाषा, समस्या डोमेन और उपलब्ध पुस्तकालयों को अच्छी तरह से जानता है, वह जानबूझकर करेगा, जो अभी भी उल्टा है (उल्टा पड़ता है)।

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

— जॉन हैना
स्रोत

1

लेकिन लोगों को लगता है कि यह एक अच्छा विचार है, शायद इसलिए क्योंकि उन्हें लगता है कि यह कोड के पुन: उपयोग का एक रूप है।

— जेएसबी JS

शुरुआती लोगों को अक्सर लगता है कि दो चर को घोषित करने के लिए किसी भी तरह से दो बार स्थान की आवश्यकता होती है, और इसलिए चर का पुन: उपयोग करना पसंद करते हैं। यह मेमोरी मॉडल (फ्री स्टोर बनाम स्टैक, स्टैक स्थानों के पुन: उपयोग की संभावना) और ऐसी अनुकूलन क्षमता दिखाता है जो सभी कंपाइलर प्रदर्शन करने में सक्षम हैं। मेरा तर्क है कि एक शुरुआत इसलिए चर को एक अच्छे विचार का पुन: उपयोग करने पर विचार कर सकती है, इसलिए इसे एंटीपैटर्न के रूप में वर्गीकृत किया जा सकता है।

— फिलिप

जो इसे एक अंधविश्वास नहीं, बल्कि एक अंधविश्वास बनाता है।

— जॉन हैना

3

(1) मैं कहूंगा कि यह अच्छा नहीं है।

यह मैनुअल हाउस का प्रदर्शन कर रहा है कि स्टैक स्वचालित रूप से स्थानीय चर के साथ कर सकता है।

कोई प्रदर्शन लाभ नहीं है क्योंकि "नया" प्रत्येक विधि आह्वान कहा जाता है।

EDIT: क्लास का मेमोरी फुटप्रिंट बड़ा होता है क्योंकि बार पॉइंटर हमेशा क्लास के जीवनकाल में मेमोरी को ऊपर ले जाता है। यदि बार पॉइंटर स्थानीय था, तो यह केवल मेथड कॉल के जीवनकाल के लिए मेमोरी का उपयोग करेगा। पॉइंटर के लिए मेमोरी केवल महासागर में एक बूंद है, लेकिन यह अभी भी एक अनावश्यक ड्रॉप है।

कक्षा में अन्य तरीकों के लिए बार दिखाई देता है। बार का उपयोग नहीं करने वाले तरीके इसे देखने में सक्षम नहीं होने चाहिए।

राज्य आधारित त्रुटियां। इस विशेष स्थिति में राज्य आधार त्रुटियां केवल "नई" कहे जाने के बाद से बहु-थ्रेडिंग में होनी चाहिए।

(2) मुझे नहीं पता कि इसके लिए कोई नाम है क्योंकि यह वास्तव में कई मुद्दे हैं, एक नहीं।
- आटोमेटिक हाउसकीपिंग जब ऑटोमैटिक उपलब्ध है -
अनावश्यक अवस्था
- जो कि अधिक समय तक रहती है, वह आजीवन -
विश्वसनीयता या स्कोप बहुत अधिक है

— mike30
स्रोत

2

मैं इसे "घूमने वाले ज़ेनोफोब" कहूंगा। यह अकेला रहना चाहता है, लेकिन यह नहीं जानता कि यह कहाँ या क्या है। इस प्रकार यह एक बुरी बात है जैसा कि अन्य लोगों ने कहा है।

— विश्व इंजीनियर
स्रोत

2

यहाँ अनाज के खिलाफ जा रहे हैं, लेकिन जब मैं दिए गए उदाहरण को अच्छी कोडिंग शैली के रूप में नहीं मानता हूं, तो यह अपने मौजूदा रूप में है, इकाई परीक्षण करते समय पैटर्न मौजूद है।

इकाई परीक्षण करने का यह काफी मानक तरीका है

public class BarTester
{
    private Bar bar;

    public Setup() { bar = new Bar(); }
    public Teardown() { bar = null; }

    public TestMethodA()
    {
        bar.A();        
    }

    public TestMethodB()
    {
        bar.B();
    }
}

ओपी के कोड के इस समकक्ष के एक refactoring है

public class BarTester
{
    private Bar bar;

    public TestMethodA()
    {
        bar = new Bar();
        bar.A();
        bar = null;
    }

    public TestMethodB()
    {
        bar = new Bar();
        bar.B();
        bar = null;
    }
}

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

— लीवर केर्सेमेकर्स
स्रोत

उस स्थिति में प्रत्येक परीक्षण के लिए स्थिरता को स्वतंत्र रूप से त्वरित किया जाता है, और चर पुन: उपयोग या संगामिति से संबंधित समस्याएं उत्पन्न नहीं होती हैं। सामान्य स्थिति में (इकाई परीक्षणों के बाहर) यह ज्ञात नहीं है कि प्रत्येक वस्तु पर अधिकांश एक विधि को कहा जाता है या नहीं।

— फिलिप

1

@Philipp - मैं पुन: उपयोग या संगामिति की समस्या पर विवाद नहीं करता, लेकिन ओपी का प्रश्न पैटर्न विच के बारे में था जो आमतौर पर यूनिट-परीक्षण में उपयोग किया जाता है। तथ्य यह है कि प्रत्येक परीक्षण के लिए तात्कालिकता का निर्धारण किया जाता है, परीक्षण ढांचे का कार्यान्वयन विवरण है। इकाई-परीक्षण में भी, पैटर्न केवल तभी सुरक्षित होता है जब परीक्षण ढांचे का उपयोग किया जाता है क्योंकि इसका उपयोग करना चाहिए। उत्पादन कोड में इस पैटर्न का उपयोग करते समय एक ही तर्क लागू होता है।

— लेवेन केर्सेमेकर्स

सेट barकरने की कोई आवश्यकता नहीं है null, जेयूनाइट वैसे भी हर परीक्षा पद्धति के लिए एक नया परीक्षण उदाहरण बनाता है।

— आज्ञाकारिता

2

बेक / फाउलर द्वारा रिफैक्टिंग में इस कोड गंध को टेम्परेरी फील्ड के रूप में संदर्भित किया जाता है।

http://sourcemaking.com/refactoring/temporary-field

मध्यस्थों के अनुरोध के द्वारा और अधिक विवरण जोड़ने के लिए संपादित: आप उपरोक्त संदर्भित URL में कोड गंध के बारे में या पुस्तक की हार्ड कॉपी में अधिक पढ़ सकते हैं। चूँकि ओपी इस विशेष एंटीपैटर्न / कोड गंध के नाम की तलाश कर रहा था, मैंने सोचा कि 10 साल से अधिक पुराने एक स्थापित स्रोत से इसके संदर्भ में असंबद्ध संदर्भ का हवाला देना मददगार होगा, हालांकि मुझे पूरी तरह से एहसास है कि मुझे देर हो चुकी है इस सवाल पर खेल है, इसलिए यह संभावना नहीं है कि जवाब वोट दिया जाएगा या स्वीकार किया जाएगा।

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

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

— ssmith
स्रोत

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

— आज्ञाकारिता

1

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

जैसा कि यह बुरा है या नहीं, मैं कहूंगा कि यह स्पष्ट रूप से है, और मुझे लगता है कि स्टीफन सी यह समझाने का एक उत्कृष्ट काम करता है। हालाँकि, यह "एंटी-पैटर्न" कहलाने लायक है या नहीं, मुझे लगता है कि यह और कोई भी कोडिंग प्रतिमान एक लेबल के साथ कर सकता है, क्योंकि यह आम तौर पर संचार को आसान बनाता है।

— एरिक डाईट्रिच
स्रोत

1

पहले से बताई गई समस्याओं के अलावा, स्वचालित कचरा संग्रह (जैसे C ++) के बिना पर्यावरण में इस दृष्टिकोण का उपयोग करने से मेमोरी लीक हो जाएगी, क्योंकि उपयोग के बाद अस्थायी वस्तुओं को मुक्त नहीं किया जाता है। (हालांकि यह थोड़ा दूर लग सकता है, वहाँ लोग हैं जो सिर्फ 'null' को 'NULL' में बदल देंगे और खुश होंगे कि कोड संकलित है।)

— peterph
स्रोत

1

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

— Evicatos
स्रोत

-1

मैंने इसे कई बार सामना किया है, आमतौर पर जब ताज़ा कोड पहले किसी ऐसे व्यक्ति द्वारा लिखा गया था जिसने वीबीए फॉर डमियों को अपने पहले शीर्षक के रूप में चुना था और जिस भी भाषा में वे ठोकर खाई थी उसमें एक अपेक्षाकृत बड़ी प्रणाली लिखी थी।

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

यह वास्तव में "एंटीपैटर्न" टैग के लायक नहीं है - लेकिन यह ओपी को फिर से कैसे बनाया जा सकता है इसके सुझावों को देखना अच्छा है।

— ली जेम्स
स्रोत

1

स्टैक एक्सचेंज प्रोग्रामर्स में आपका स्वागत है, अपना पहला उत्तर दर्ज करने के लिए धन्यवाद। ऐसा लगता है कि आप संभवतः FAQ में सूचीबद्ध एक कारणों की वजह से एक नीचे वोट किया था, programmers.stackexchange.com/faq । एफएक्यू प्रभावी (और मतदान वाले) उत्तर बनाने पर बहुत अच्छे सुझाव देता है। कभी-कभी लोग यह बताने के लिए पर्याप्त होते हैं कि डाउन वोट के बारे में एक नोट जोड़ने के लिए कि क्या यह किसी तरह से गलत है, डुप्लिकेट, बिना सबूत के राय, या मुझे भी, जो पहले वाला उत्तर दोहराता है। हममें से अधिकांश लोगों ने मतदान को बंद कर दिया है, बंद कर दिया है या उत्तर हटा दिए हैं, इसलिए चिंतित न हों। यह शुरू करने का सिर्फ एक हिस्सा है। स्वागत हे।

— DeveloperDon