टाइप इंट्रेंस के लिए ट्रेडऑफ क्या है?

Question

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

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

Comments

C # में, सामान्य दिशानिर्देश हमेशा उपयोग न करने के लिए कहते हैं varक्योंकि यह कभी-कभी पठनीयता को नुकसान पहुंचा सकता है।

— मेफी

"... या क्यों कहते हैं कि जावा या पुरानी अच्छी भाषाओं में प्रकार का कोई हस्तक्षेप नहीं है" कारण संभवतः ऐतिहासिक हैं; ML विकिपीडिया के अनुसार C के 1 साल बाद दिखाई दिया और उसे टाइप इनफैक्शन था। जावा C ++ डेवलपर्स से अपील करने की कोशिश कर रहा था । C ++ ने C के विस्तार के रूप में शुरू किया, और C की प्राथमिक चिंताओं को विधानसभा पर एक पोर्टेबल आवरण और संकलन के लिए आसान किया जा रहा था। जो कुछ भी इसके लायक है, मैंने पढ़ा है कि सबटाइपिंग सामान्य मामले में भी प्रकार की अनिर्णय बनाता है।

— डोभाल

@Doval Scala, एक ऐसी भाषा के लिए, जो उपप्रकार विरासत का समर्थन करती है, के लिए बहुत अच्छा काम करती है। यह किसी भी एमएल-परिवार की भाषा के रूप में अच्छा नहीं है, लेकिन यह उतना ही अच्छा है जितना आप पूछ सकते हैं, भाषा का डिज़ाइन दिया गया है।

— KChaloux

टाइप डिडक्शन (मोनोडायरेक्शनल, जैसे C # varऔर C ++ auto) और टाइप इनफैक्शन (बिडायरेक्शनल , जैसे हास्केल let) के बीच अंतर करना उचित है । पूर्व के मामले में, किसी नाम का प्रकार केवल उसके आरंभिक अक्षर से अनुमान लगाया जा सकता है - इसके उपयोग को नाम के प्रकार का पालन करना चाहिए। उत्तरार्द्ध मामले में, एक नाम का प्रकार इसके उपयोगों से भी हो सकता है - जो इसमें उपयोगी है कि आप []एक खाली अनुक्रम के लिए लिख सकते हैं , तत्व प्रकार की परवाह किए बिना, या newEmptyMVarएक नए अशक्त परस्पर संदर्भ के लिए, संदर्भ की परवाह किए बिना। प्रकार।

— जॉन पूर्डी

विशेष रूप से कुशलतापूर्वक लागू करने के लिए प्रकार का अनुमान अविश्वसनीय रूप से जटिल हो सकता है। लोग नहीं चाहते हैं कि उनके संकलन की जटिलता अधिक जटिल अभिव्यक्तियों से घातांक झटका हो। दिलचस्प पढ़ें: cocoawithlove.com/blog/2016/07/12/type-checker-issues.html

— अलेक्जेंडर - मोनिका

Answer 1

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

1. टाइप एनोटेशन प्रलेखन के रूप में कार्य करते हैं । यह विशेष रूप से हास्केल के रूप में अभिव्यंजक के रूप में सच है। किसी फ़ंक्शन के नाम और उसके प्रकार को देखते हुए आप आमतौर पर इस बात पर बहुत अच्छा अनुमान लगा सकते हैं कि फ़ंक्शन क्या करता है, खासकर जब फ़ंक्शन पैरामीट्रिक पॉलीमॉर्फिक है।
2. प्रकार एनोटेशन विकास को ड्राइव कर सकते हैं । किसी फ़ंक्शन के शरीर को लिखने से पहले एक प्रकार का हस्ताक्षर लिखने से परीक्षण-संचालित विकास जैसा लगता है। मेरे अनुभव में, एक बार जब आप हास्केल फ़ंक्शन बनाते हैं, तो यह आमतौर पर पहली बार काम करता है। (बेशक, यह स्वचालित परीक्षणों की आवश्यकता को कम नहीं करता है!)
3. स्पष्ट प्रकार आपकी मान्यताओं की जांच करने में आपकी सहायता कर सकते हैं । जब मैं कुछ कोड को समझने की कोशिश कर रहा हूं जो पहले से ही काम कर रहा है, तो मैं अक्सर इसे सही प्रकार के एनोटेशन के रूप में मानता हूं। यदि कोड अभी भी संकलित करता है तो मुझे पता है कि मैं इसे समझ गया हूं। यदि ऐसा नहीं होता है, तो मैं त्रुटि संदेश पढ़ता हूं।
4. प्रकार के हस्ताक्षर आपको बहुरूपी कार्यों का विशेषज्ञ बनाते हैं । यदि कभी-कभी कुछ कार्य बहुरूप नहीं होते हैं, तो बहुत ही एपीआई अधिक अभिव्यंजक या उपयोगी होता है। कंपाइलर शिकायत नहीं करेगा यदि आप किसी फ़ंक्शन को अनुमान से कम सामान्य प्रकार देते हैं। क्लासिक उदाहरण है map :: (a -> b) -> [a] -> [b]। इसका अधिक सामान्य रूप ( fmap :: Functor f => (a -> b) -> f a -> f b) सभी Functorसूचियों पर लागू होता है , न कि केवल सूचियों पर। लेकिन यह महसूस किया गया कि mapशुरुआती लोगों के लिए समझना आसान होगा, इसलिए यह अपने बड़े भाई के साथ रहता है।

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

जावा * यह साबित करता है कि बहुत अधिक प्रकार के एनोटेशन की आवश्यकता वाली भाषा कष्टप्रद हो जाती है, लेकिन बहुत कम के साथ आप ऊपर बताए गए फायदों से चूक जाते हैं। ऑप्ट-आउट प्रकार की आक्षेप वाली भाषाएं दो चरम सीमाओं के बीच एक सहमत संतुलन को प्रभावित करती हैं।

_{* यहां तक ​​कि जावा, वह महान बलि का बकरा, एक निश्चित मात्रा में स्थानीय प्रकार के इंजेक्शन लगाता है। इस तरह के एक बयान में Map<String, Integer> = new HashMap<>();, आपको निर्माणकर्ता के सामान्य प्रकार को निर्दिष्ट करने की आवश्यकता नहीं है। दूसरी ओर, एमएल-शैली की भाषाएं आमतौर पर विश्व स्तर पर देखने योग्य हैं।}

Comments

लेकिन आप शुरुआत नहीं कर रहे हैं;) आपको वास्तव में "पाने" से पहले टाइप की कक्षाओं और प्रकारों की समझ होनी चाहिए Functor। सूचियाँ और mapगैर-अनुभवी हास्केलर से परिचित होने की अधिक संभावना है।

— बेंजामिन हॉजसन

क्या आप C # varके प्रकार के अनुमान का एक उदाहरण मानते हैं?

— बेंजामिन हॉजसन

हां, C # varका एक उचित उदाहरण है।

— डोभाल

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

— डोभाल

ध्यान दें कि new HashMap<>();सिंटैक्स केवल जावा 7 में जोड़ा गया था, और जावा 8 में लैम्ब्डा काफी "वास्तविक" प्रकार के अनुमान के लिए अनुमति देते हैं।

— माइकल बोरगवर्ड

Answer 2

C # में, संकलन समय पर प्रकार का अनुमान लगाता है, इसलिए रनटाइम लागत शून्य है।

शैली के रूप में, varउन स्थितियों के लिए उपयोग किया जाता है जहां यह या तो असुविधाजनक है या मैन्युअल रूप से निर्दिष्ट करने के लिए अनावश्यक है। Linq एक ऐसी स्थिति है। एक और है:

var s = new SomeReallyLongTypeNameWith<Several, Type, Parameters>(andFormal, parameters);

जिसके बिना आप केवल कहने के बजाय अपने वास्तव में लंबे प्रकार के नाम (और प्रकार के मापदंडों) को दोहरा रहे होंगे var।

प्रकार का वास्तविक नाम का उपयोग करें जब स्पष्ट रूप से कोड स्पष्टता में सुधार होता है।

ऐसी कुछ स्थितियाँ हैं जहाँ प्रकार का प्रयोग नहीं किया जा सकता है, जैसे कि सदस्य चर घोषणाएँ जिनके मूल्य निर्माण के समय निर्धारित किए गए हैं, या जहाँ आप वास्तव में ठीक से काम करना चाहते हैं (Hackerrank का IDE चर के सदस्यों को तब तक सूचित नहीं करेगा जब तक कि प्रकार स्पष्ट रूप से घोषित न हो) ।

Comments

"सी # में, टाइप-इंफ़ेक्शन संकलन-समय पर होता है, इसलिए रनटाइम लागत शून्य है।" परिभाषा के अनुसार संकलन समय पर टाइप इंफ़ेक्शन होता है, इसलिए हर भाषा में ऐसा होता है।

— डोभाल

इतना बेहतर।

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

@ डोवाल ने जेआईटी संकलन के दौरान टाइप इंट्रेंस प्रदर्शन करना संभव है, जिसमें स्पष्ट रूप से रनटाइम लागत है।

— जूल्स

@ जूल्स यदि आप कार्यक्रम को चलाने के रूप में दूर हो गए हैं, तो यह पहले से ही टाइप किया हुआ है; कुछ भी नहीं बचा है। आप जिस बारे में बात कर रहे हैं उसे आमतौर पर टाइप इंफ़ेक्शन नहीं कहा जाता है, हालांकि मुझे यकीन नहीं है कि उचित शब्द क्या है।

— डोभाल

Answer 3

अच्छा प्रश्न!

1. चूंकि प्रकार स्पष्ट रूप से एनोटेट नहीं है, इसलिए यह कई बार कोड को पढ़ने के लिए कठिन बना सकता है - अधिक बग के लिए अग्रणी। बेशक इसका सही उपयोग कोड क्लीनर और अधिक पठनीय बनाता है । यदि आप निराशावादी हैं और सोचते हैं कि अधिकांश प्रोग्रामर खराब हैं (या जहां अधिकांश प्रोग्रामर खराब हैं) काम करते हैं , तो यह शुद्ध नुकसान होगा।
2. जबकि प्रकार का अनुमान एल्गोरिथ्म अपेक्षाकृत सरल है, यह मुफ़्त नहीं है । इस तरह की बात संकलन समय को थोड़ा बढ़ा देती है।
3. चूंकि प्रकार स्पष्ट रूप से एनोटेट नहीं है, इसलिए आपका आईडीई अनुमान नहीं लगा सकता है कि आप क्या करने की कोशिश कर रहे हैं, घोषणा प्रक्रिया के दौरान स्वत: पूर्ण और इसी तरह के सहायकों को नुकसान पहुंचा रहे हैं।
4. फ़ंक्शन ओवरलोड्स के साथ संयुक्त, आप कभी-कभी उन स्थितियों में पहुंच सकते हैं जहां प्रकार की एल्गोरिथ्म एल्गोरिथ्म तय नहीं कर सकता है कि कौन सा रास्ता लेना है, जिससे बदसूरत कास्टिंग शैली एनोटेशन हो। (उदाहरण के लिए C # के अनाम फ़ंक्शन सिंटैक्स के साथ यह बहुत कम होता है)।

और अधिक गूढ़ भाषाएं हैं जो स्पष्ट प्रकार के एनोटेशन के बिना अपनी विचित्रता नहीं कर सकती हैं। अब तक, कोई भी ऐसा नहीं है जो मुझे पता है कि आम / लोकप्रिय / होनहार हैं जो उल्लेख करने के अलावा पर्याप्त हैं।

Comments

स्वत: पूर्ण प्रकार के अनुमान के बारे में एक बकवास नहीं देता है। इससे कोई फर्क नहीं पड़ता कि प्रकार कैसे तय किया गया था, केवल उस प्रकार का क्या है। और सी # लैंबडास के साथ समस्याओं का अनुमान से कोई लेना-देना नहीं है, वे इसलिए हैं क्योंकि लैम्ब्डा पॉलीमॉर्फिक हैं, लेकिन टाइप सिस्टम इसके साथ सामना नहीं कर सकता है - जिसका आक्षेप से कोई लेना-देना नहीं है।

— डेडएमजी

@deadmg - निश्चित रूप से, एक बार चर घोषित होने के बाद इसे कोई समस्या नहीं होती है, लेकिन जब आप चर घोषणा में टाइप कर रहे होते हैं, तो यह राइट हैंड साइड के विकल्पों को घोषित प्रकार तक सीमित नहीं कर सकता है क्योंकि कोई घोषित प्रकार नहीं है।

— तेलस्टिन

@deadmg - लैंबडास के रूप में, मैं आपके मतलब के बारे में सुपर स्पष्ट नहीं हूं, लेकिन मुझे पूरा यकीन है कि यह पूरी तरह से सही नहीं है कि मेरी समझ कैसे काम करती है। यहां तक ​​कि कुछ भी सरल जितना var foo = x => x;असफल होता है क्योंकि भाषा को xयहां पर जानने की जरूरत है और कुछ भी नहीं है। जब लैम्ब्डा बनाया जाता है, तो वे स्पष्ट रूप से टाइप किए गए प्रतिनिधियों के Func<int, int> foo = x => xरूप में निर्मित होते हैं, CIL में निर्मित होते हैं, Func<int, int> foo = new Func<int, int>(x=>x);जहाँ लैम्बडा को एक उत्पन्न, स्पष्ट रूप से टाइप किए गए फ़ंक्शन के रूप में बनाया जाता है। मेरे लिए, प्रकार का x

— जिक्र

@Telastyn यह सच नहीं है कि भाषा में कुछ भी नहीं है। अभिव्यक्ति टाइप करने के लिए आवश्यक सभी जानकारी x => xलैम्बडा के अंदर ही निहित है - यह आसपास के दायरे से किसी भी चर को संदर्भित नहीं करता है। किसी भी समझदार कार्यात्मक भाषा सही ढंग से अनुमान कर होता है कि अपने प्रकार है "सभी प्रकार के लिए a, a -> a"। मुझे लगता है कि डेडएमजी कहने की कोशिश कर रहा है कि सी # प्रकार की प्रणाली में मूल प्रकार की संपत्ति का अभाव है, जिसका अर्थ है कि किसी भी अभिव्यक्ति के लिए सबसे सामान्य प्रकार का पता लगाना हमेशा संभव है। यह नष्ट करने के लिए एक बहुत ही आसान संपत्ति है।

— डोभाल

@ डोभाल - एनएच ... सी # में जेनेरिक फंक्शन ऑब्जेक्ट्स जैसी कोई चीज नहीं है, जो मुझे लगता है कि आप जो बात कर रहे हैं, उससे कहीं ज्यादा अलग है, भले ही यह उसी परेशानी की ओर ले जाए।

— तेलस्तीन

Answer 4

यह मुझे बहुत अच्छा लग रहा है, लेकिन मैं सोच रहा हूं कि क्या कोई ट्रेड-ऑफ है या क्यों कहते हैं कि जावा या पुरानी अच्छी भाषाओं में हस्तक्षेप नहीं है

जावा यहां नियम के बजाय अपवाद होता है। यहां तक ​​कि C ++ (जो कि मैं एक "अच्छी पुरानी भाषा" :) के रूप में योग्य हूं,) autoC 11 11 मानक के बाद से कीवर्ड के साथ प्रकार के अनुमान का समर्थन करता है । यह न केवल चर घोषणा के साथ काम करता है, बल्कि फ़ंक्शन रिटर्न प्रकार के रूप में भी होता है, जो कुछ जटिल टेम्पलेट फ़ंक्शन के साथ विशेष रूप से उपयोगी है।

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

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

मैं डेवलपर को टाइप इंट्रैक्शन का उपयोग करने का अवसर देने में वास्तविक कमी नहीं देखता।

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

तो असली ड्रा बैक तब होता है जब कोई भाषा अंतर्निहित टाइपिंग का समर्थन नहीं करती है, क्योंकि इसके साथ यह बताता है कि डेवलपर के पास इसका उपयोग करने का कोई वैध कारण नहीं है, जो कि सच नहीं है।

Answer 5

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

एचएम प्रकार का आविष्कार एक शानदार नवाचार है जो बहुरंगी प्रकार की कार्यात्मक भाषाओं के साथ अच्छी तरह से काम करता है, लेकिन गो के लेखक शायद यह तर्क देंगे कि यह बहुत अधिक करने की कोशिश करता है:

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

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

Comments

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

— Ixrec

Answer 6

इससे पठनीयता को ठेस पहुंचती है।

तुलना

var stuff = someComplexFunction()

बनाम

List<BusinessObject> stuff = someComplexFunction()

यह विशेष रूप से एक समस्या है जब एक आईडीई के बाहर पढ़ना पसंद है जैसे कि जीथब।

Comments

इससे पहले किए गए 6 अंकों से अधिक कुछ भी नहीं दिया गया था और पहले 6 उत्तरों में समझाया गया था

— gnat

यदि आप "जटिल अपठनीय" के बजाय उचित नाम का उपयोग करते हैं, तो varपठनीयता को नुकसान पहुंचाए बिना उपयोग किया जा सकता है। var objects = GetBusinessObjects();

— Fabio

ठीक है, लेकिन फिर आप चर नामों में टाइप सिस्टम को लीक कर रहे हैं। यह अय नोटेशन जैसा है। Refactorings के बाद आप उन नामों से समाप्त होने की संभावना रखते हैं जो कोड से मेल नहीं खाते हैं। सामान्य तौर पर, कार्यात्मक शैली आपको प्राकृतिक नेमस्पेसिंग लाभ खो देती है जो कक्षाएं प्रदान करती हैं। इसलिए आप वर्ग.आर्इआ () के बजाय अधिक वर्गआय () के साथ समाप्त करें।

— मिगेल