क्या कंस्ट्रक्टर में "नया" का उपयोग हमेशा बुरा होता है?

Question

मैंने पढ़ा है कि एक कंस्ट्रक्टर में "नए" का उपयोग करना (सरल मूल्य वाले किसी अन्य ऑब्जेक्ट के लिए) बुरा अभ्यास है क्योंकि यह यूनिट परीक्षण को असंभव बनाता है (तब उन सहयोगियों को भी बनाने की आवश्यकता होती है और उनका मजाक नहीं उड़ाया जा सकता है)। जैसा कि मैं यूनिट परीक्षण में वास्तव में अनुभवी नहीं हूं, मैं कुछ नियमों को इकट्ठा करने की कोशिश कर रहा हूं जो मैं पहले सीखूंगा। इसके अलावा, यह एक नियम है जो आम तौर पर मान्य है, चाहे भाषा का उपयोग क्यों न हो?

Comments

यह परीक्षण को असंभव नहीं बनाता है। यह आपके कोड को बनाए रखना और परीक्षण करना कठिन बनाता है, हालाँकि। की एक पढ़ा है नया है गोंद उदाहरण के लिए।

— डेविड अरनो

"हमेशा" हमेशा गलत होता है। :) सर्वोत्तम प्रथाएं हैं, लेकिन अपवाद लाजिमी हैं।

— पॉल

यह कौनसी भाषा है? newअलग-अलग भाषाओं में अलग-अलग चीजों का मतलब है।

— user2357112

यह सवाल भाषा पर थोड़ा निर्भर करता है, है ना? सभी भाषाओं में एक newकीवर्ड भी नहीं होता है । आप किन भाषाओं के बारे में पूछ रहे हैं?

— ब्रायन ओकले

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

— मैट टिम्मरमैन

Answer 1

हमेशा अपवाद होते हैं, और मैं शीर्षक में 'हमेशा' के साथ मुद्दा लेता हूं, लेकिन हां, यह दिशानिर्देश आम तौर पर मान्य है, और साथ ही निर्माणकर्ता के बाहर भी लागू होता है।

एक निर्माता में नए का उपयोग करना SOLID (निर्भरता व्युत्क्रम सिद्धांत) में डी का उल्लंघन करता है। यह आपके कोड को परीक्षण करने के लिए कठिन बनाता है क्योंकि इकाई परीक्षण सभी अलगाव के बारे में है; यदि ठोस संदर्भ हैं तो वर्ग को अलग करना कठिन है।

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

कंस्ट्रक्टर में नए का उपयोग नहीं करने से आपका कोड अधिक लचीला हो जाता है। यह उन भाषाओं पर भी लागू होता है जो newऑब्जेक्ट आरंभीकरण के अलावा अन्य निर्माणों का उपयोग कर सकते हैं ।

हालांकि, स्पष्ट रूप से, आपको अच्छे निर्णय का उपयोग करने की आवश्यकता है। ऐसे बहुत सारे समय होते हैं जब यह उपयोग करने के लिए ठीक है new, या जहां यह बेहतर नहीं होगा, लेकिन आपके पास नकारात्मक परिणाम नहीं होंगे। कहीं न कहीं, किसी न किसी को बुलाना ही newहोगा। बस newएक वर्ग के अंदर फोन करने के बारे में बहुत सावधान रहें कि बहुत सारी अन्य कक्षाएं निर्भर हैं।

कुछ करना जैसे कि आपके कंस्ट्रक्टर में एक खाली निजी संग्रह को शुरू करना ठीक है, और इसे इंजेक्ट करना बेतुका होगा।

एक वर्ग के लिए जितना अधिक संदर्भ होता है, उतना ही सावधान रहना चाहिए कि आप newउसके भीतर से कॉल न करें ।

Comments

मैं वास्तव में इस नियम में कोई मूल्य नहीं देखता हूं। कोड में तंग युग्मन से बचने के लिए नियम और दिशानिर्देश हैं। यह नियम ठीक उसी मुद्दे से निपटने के लिए लगता है, सिवाय इसके कि हमें कोई अतिरिक्त मूल्य नहीं देते हुए यह अविश्वसनीय रूप से बहुत प्रतिबंधात्मक है। तो क्या बात है? उन सभी विशेष मामलों से निपटने के बजाय मेरे लिंक्डलिस्ट कार्यान्वयन के लिए एक डमी हेडर ऑब्जेक्ट क्यों बनाया जाएगा head = nullजो किसी भी तरह से कोड को बेहतर बनाने से आते हैं ? क्यों शामिल संग्रह को शून्य के रूप में छोड़ दिया जाएगा और उन्हें बनाने की मांग निर्माणकर्ता में ऐसा करने से बेहतर होगी?

— वू

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

— वूक

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

— Voo

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

— jpmc26

@ jpmc26, BJoBnh में जाने के बिना अगर मैं इस उत्तर को निंदा करता हूं या नहीं, तो बिंदु बहुत स्पष्ट रूप से व्यक्त किया गया है। यदि आपको लगता है कि "निर्भरता व्युत्क्रम प्रिंसिपल", "ठोस संदर्भ" या "ऑब्जेक्ट इनिशियलाइज़ेशन" सिर्फ buzzwords हैं, तो वास्तव में आप अभी नहीं जानते कि उनका क्या मतलब है। जवाब की गलती नहीं है।

— आर। शमित्ज़

Answer 2

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

यदि वर्ग एक संग्रह का प्रतिनिधित्व करता है, तो इसमें एक आंतरिक सहायक सरणी या सूची या हैशसेट हो सकता है। यह newइन सहायकों को बनाने के लिए उपयोग करेगा और इसे काफी सामान्य माना जाएगा। वर्ग विभिन्न आंतरिक सहायकों का उपयोग करने के लिए इंजेक्शन की पेशकश नहीं करता है और इसका कोई कारण नहीं है। इस मामले में, आप ऑब्जेक्ट के सार्वजनिक तरीकों का परीक्षण करना चाहते हैं, जो संग्रह में तत्वों को संचय, हटाने और बदलने के लिए जा सकते हैं।

---

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

सारांश में, आपको कुछ निर्णय का उपयोग करना होगा कि क्या अमूर्त को केवल एक या एक से अधिक आंतरिक / सहायक वस्तुओं की आवश्यकता है, जबकि अभी भी कॉलर द्वारा एक ही अमूर्त के रूप में देखा जा रहा है, या, क्या अन्य वस्तुओं को बनाने के लिए कॉलर को बेहतर उजागर किया जाएगा या नहीं निर्भरता का नियंत्रण, जिसका सुझाव दिया जाएगा, उदाहरण के लिए, जब कॉलर कक्षा का उपयोग करने में इन अन्य वस्तुओं को देखता है।

Comments

+1। यह बिल्कुल सही है। आपको यह पहचानना होगा कि कक्षा का इच्छित व्यवहार क्या है, और यह निर्धारित करता है कि किन कार्यान्वयन विवरणों को उजागर करने की आवश्यकता है और जो नहीं करते हैं। एक प्रकार का सूक्ष्म अंतर्ज्ञान खेल है जिसे आपको यह निर्धारित करने के साथ खेलना है कि वर्ग "जिम्मेदारी" क्या है।

— jpmc26

Answer 3

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

Comments

Not all collaborators are interesting enough to unit-test separatelyकहानी का अंत :-), यह मामला संभव है और किसी ने उल्लेख करने की हिम्मत नहीं की। @Joppe मैं आपको उत्तर को थोड़ा विस्तृत करने के लिए प्रोत्साहित करता हूं। उदाहरण के लिए, आप उन वर्गों के कुछ उदाहरण जोड़ सकते हैं जो केवल कार्यान्वयन विवरण हैं (प्रतिस्थापन के लिए उपयुक्त नहीं) और यदि हम इसे आवश्यक समझें तो उन्हें बाद में कैसे निकाला जा सकता है।

— लैवि

@ लीव डोमेन मॉडल आमतौर पर ठोस, गैर-सार होते हैं, आप वहां नेस्टेड ऑब्जेक्ट को इंजेक्ट करने के बारे में नहीं जाते हैं। सरल मूल्य वस्तु / जटिल वस्तु होने अन्यथा कोई तर्क भी उम्मीदवार नहीं है।

— Joppe

+1, बिल्कुल। यदि कोई भाषा सेट की गई है ताकि आपको फ़ाइल से संबंधित कुछ भी करने के लिए कॉल करना पड़े, तो उस कॉल new File()को मना करने का कोई अर्थ नहीं है। आप क्या करने जा रहे हैं, stdlib के Fileमॉड्यूल के खिलाफ प्रतिगमन परीक्षण लिखें ? कम संभावना। दूसरी ओर, स्व-आविष्कृत वर्ग newपर कॉल करना अधिक संदिग्ध है।

— किलन फ़ॉथ

@ केलियनफोथ: गुड लक यूनिट परीक्षण कुछ भी जो सीधे कॉल करता है new File(), हालांकि।

— फोशी

यह एक अनुमान है । हम ऐसे मामलों का पता लगा सकते हैं जहां इसका कोई मतलब नहीं है, ऐसे मामले जहां यह उपयोगी नहीं है और ऐसे मामले जहां यह समझ में आता है और यह उपयोगी है। यह जरूरतों और प्राथमिकताओं की बात है।

— लैवि

Answer 4

जैसा कि मैं यूनिट परीक्षण में वास्तव में अनुभवी नहीं हूं, मैं कुछ नियमों को इकट्ठा करने की कोशिश कर रहा हूं जो मैं पहले सीखूंगा।

उन समस्याओं के लिए "नियम" सीखें, जिनका आपने कभी सामना नहीं किया है। यदि आप कुछ "नियम" या "सर्वोत्तम अभ्यास" पर आते हैं, तो मैं सुझाव दूंगा कि एक सरल खिलौना उदाहरण का उपयोग करें जहां यह नियम "माना जाता है" का उपयोग किया जाए, और उस समस्या को हल करने की कोशिश करते हुए , जो "नियम" कहता है, उसे अनदेखा करना।

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

फिर "नियम" का पालन करके उसी समस्या को हल करने का प्रयास करें। फिर से, आपके सामने आने वाली समस्याओं की एक सूची बनाएं। सूचियों की तुलना करें, और सोचें कि नियम का पालन करते समय कौन सी स्थितियां बेहतर हो सकती हैं, और कौन सी नहीं।

---

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

मुख्य तर्क समस्या डोमेन के आधार पर "अंदर" चीजों की गणना करने के बारे में है। ऐसा लगता है कि कक्षाओं में शामिल हो सकता है User, Document, Order, Invoice, आदि यह ठीक कोर कक्षाएं फोन के लिए newअन्य मुख्य वर्गों के लिए, के बाद से वे "आंतरिक" कार्यान्वयन विवरण। उदाहरण के लिए, एक निर्माण Orderभी एक बना सकता है Invoiceऔर एक Documentविवरण जो आदेश दिया गया था। परीक्षणों के दौरान इनका मजाक उड़ाने की कोई आवश्यकता नहीं है, क्योंकि ये वास्तविक चीजें हैं जिन्हें हम परीक्षण करना चाहते हैं!

पोर्ट और एडेप्टर हैं कि बाहरी दुनिया के साथ कोर लॉजिक कैसे बातचीत करते हैं। यह वह जगह है जहां चीजें चाहते Database, ConfigFile, EmailSender, आदि रहते हैं। ये ऐसी चीजें हैं जो परीक्षण को कठिन बनाती हैं, इसलिए इन्हें मुख्य तर्क के बाहर बनाना आवश्यक है, और उन्हें आवश्यकतानुसार (या तो निर्भरता इंजेक्शन के साथ, या विधि तर्क आदि) पास करना चाहिए।

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

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

Answer 5

मुझे उस प्रश्न का उत्तर देने की अनुमति दें, जो मैं यहां महत्वपूर्ण बिंदुओं पर विचार कर रहा हूं। मैं कुछ उपयोगकर्ता को संक्षिप्तता के लिए उद्धृत करूंगा।

हमेशा अपवाद होते हैं, लेकिन हां, यह नियम आम तौर पर मान्य है, और साथ ही निर्माणकर्ता के बाहर भी लागू होता है।

एक निर्माता में नए का उपयोग करना SOLID (निर्भरता व्युत्क्रम प्रिंसिपल) में डी का उल्लंघन करता है । यह आपके कोड को परीक्षण करने के लिए कठिन बनाता है क्योंकि इकाई परीक्षण सभी अलगाव के बारे में है; यदि ठोस संदर्भ हैं तो वर्ग को अलग करना कठिन है।

-TheCatWhisperer-

हां, newनिर्माणकर्ताओं के अंदर उपयोग करने से अक्सर डिजाइन की खामियां (उदाहरण के लिए तंग-युग्मन) होती हैं जो हमारे डिजाइन को कठोर बनाती हैं। कठिन परीक्षण करने के लिए हाँ, लेकिन असंभव नहीं। यहाँ खेलने की संपत्ति लचीलापन (परिवर्तनों के प्रति सहिष्णुता) ^{1 है} ।

फिर भी, उपरोक्त उद्धरण हमेशा सच नहीं होता है। कुछ मामलों में, ऐसी कक्षाएं हो सकती हैं जो कसकर युग्मित होने के लिए होती हैं । डेविड अर्नो ने एक जोड़े पर टिप्पणी की है।

बेशक अपवाद हैं जहां कक्षा एक अपरिवर्तनीय मूल्य वस्तु है, एक कार्यान्वयन विस्तार , आदि जहां उन्हें कसकर युग्मित माना जाता है ।

-दविद अरनो-

ठीक ठीक। कुछ कक्षाएं (उदाहरण के लिए इनर-क्लासेस) मुख्य वर्ग का कार्यान्वयन विवरण हो सकती हैं। ये मुख्य वर्ग के साथ परीक्षण किए जाने के लिए हैं, और वे जरूरी रूप से बदली या विस्तार योग्य नहीं हैं।

इसके अलावा, अगर हमारा SOLID पंथ हमें इन वर्गों को निकालने में सक्षम बनाता है , तो हम एक और अच्छे सिद्धांत का उल्लंघन कर सकते हैं। तथाकथित लॉ ऑफ़ डेमेटर । दूसरी ओर, मुझे यह डिज़ाइन के दृष्टिकोण से वास्तव में महत्वपूर्ण लगता है।

तो संभावना जवाब, हमेशा की तरह, निर्भर करता है । अंदर के निर्माणकर्ताओं का उपयोग करना newएक बुरा अभ्यास हो सकता है। लेकिन हमेशा व्यवस्थित रूप से नहीं।

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

---

^{1: SOLID का मुख्य लक्ष्य हमारे कोड को अधिक परीक्षण योग्य बनाना नहीं है। यह हमारे कोड को परिवर्तनों के प्रति अधिक सहिष्णु बनाने के लिए है। अधिक लचीला और परिणाम में, परीक्षण करने में आसान}

^{नोट: डेविड अर्नो, TheWhisperCat, मुझे आशा है कि आपको कोई आपत्ति नहीं है।}

Answer 6

एक सरल उदाहरण के रूप में, निम्नलिखित छद्मकोश पर विचार करें

class Foo {
  private:
     class Bar {}
     class Baz inherits Bar {}
     Bar myBar
  public:
     Foo(bool useBaz) { if (useBaz) myBar = new Baz else myBar = new Bar; }
}

चूंकि newका एक शुद्ध कार्यान्वयन विस्तार है Foo, और दोनों Foo::Barऔर Foo::Bazका हिस्सा हैं Foo, जब इकाई के परीक्षण Fooवहाँ के कुछ हिस्सों मजाक का कोई मतलब नहीं है Foo। आप केवल यूनिट-परीक्षण करते समय बाहर के भागों का मज़ाक उड़ाते हैं ।FooFoo

Answer 7

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

EDIT: डाउनवॉटर्स के लिए - यहां एक सॉफ्टवेयर डेवलपमेंट बुक का लिंक संभव कोड गंध के रूप में 'न्यू' फ़्लैग कर रहा है: https://books.google.com/books?id=18SuDgAAQBAJ&lpg=PT169&dq.new%20keyword%20code%20smell&pg=PT169 # v = onepage & q = नए% 20keyword% 20code% 20smell & f = झूठी

Comments

Yes, using 'new' in your non-root classes is a code smell. It means you are locking the class into using a specific implementation, and will not be able to substitute another.यह समस्या क्यों है? निर्भरता के पेड़ में हर एक निर्भरता को प्रतिस्थापन के लिए खुला नहीं होना चाहिए

— Laiv

@Paul: डिफ़ॉल्ट कार्यान्वयन होने का अर्थ है कि आप डिफ़ॉल्ट रूप में निर्दिष्ट ठोस वर्ग के लिए कसकर बाध्य संदर्भ लेते हैं। हालांकि यह एक तथाकथित "कोड गंध" नहीं बनाता है।

— रॉबर्ट हार्वे

@EzoelaVacca: मैं किसी भी संदर्भ में "कोड गंध" शब्दों का उपयोग करने के बारे में सतर्क रहूंगा। यह "रिपब्लिकन" या "लोकतांत्रिक" कहने जैसा है। उन शब्दों का क्या मतलब है? जैसे ही आप कुछ ऐसा लेबल देते हैं, आप वास्तविक मुद्दों के बारे में सोचना बंद कर देते हैं, और सीखना बंद हो जाता है।

— रॉबर्ट हार्वे

"अधिक लचीला" स्वचालित रूप से "बेहतर" नहीं है।

— whatsisname

@EzoelaVacca: newकीवर्ड का उपयोग करना एक बुरा अभ्यास नहीं है, और कभी भी नहीं था। यह है कि आप उस टूल का उपयोग करते हैं जो मायने रखता है। आप एक स्लेजहेमर का उपयोग नहीं करते हैं, उदाहरण के लिए, जहां एक गेंद पीन हथौड़ा पर्याप्त होगा।

— रॉबर्ट हार्वे