साफ पठनीय कोड बनाम तेजी से कोड पढ़ने के लिए कठिन। लाइन कब पार करनी है?

Question

जब मैं कोड लिखता हूं तो मैं हमेशा अपने कोड को यथासंभव स्वच्छ और पठनीय बनाने की कोशिश करता हूं।

हर अब और फिर एक समय आता है जब आपको लाइन को पार करने और अच्छे साफ कोड से थोड़ा बदसूरत कोड पर जाने के लिए इसे तेज करने की आवश्यकता होती है।

उस रेखा को पार करना कब ठीक है?

Comments

आपने अपने प्रश्न का उत्तर दिया, आप लाइन पार करते हैं जब आपको लाइन पार करने की आवश्यकता होती है

— gnibbler

इसके अलावा, आपका "गंदा कोड" अभी से 6 महीने पहले हार्डवेयर पर "क्लीन कोड" के रूप में तेजी से काम कर सकता है। हालांकि विंडोज की तरह ओवरबोर्ड मत जाओ। :)

— मतीन उल्हाक

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

— tylerl

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

— दान डिपलो

जब यह इन दिनों संकलक की बात आती है, तो आपका बदसूरत कोड आपके स्वच्छ कोड के समान ही होगा (यह मानते हुए कि आप वास्तव में अजीब सामान नहीं करते हैं)। विशेष रूप से .NET में, यह C ++ / MFC दिनों की तरह नहीं है जहां आप अपने चर को कैसे परिभाषित करते हैं, इसका प्रदर्शन पर प्रभाव पड़ेगा। मेंटेनेंस कोड लिखें। कुछ कोड बस जटिल हो जाएगा, लेकिन इसका मतलब यह नहीं है कि यह बदसूरत है।

— डस्टिनडाविस

Answer 1

जब आप लाइन पार करते हैं

• आपने मापा है कि आपका कोड इसके इच्छित उपयोग के लिए बहुत धीमा है ।
• आपने वैकल्पिक सुधारों की कोशिश की है जिन्हें कोड को मूक करने की आवश्यकता नहीं है।

यहां एक वास्तविक दुनिया उदाहरण है: एक प्रायोगिक प्रणाली जो मैं चला रहा हूं वह बहुत धीरे-धीरे डेटा का उत्पादन कर रहा था, प्रति रन 9 घंटे से अधिक ले रहा था और केवल 40% सीपीयू का उपयोग कर रहा था। कोड को बहुत अधिक गड़बड़ाने के बजाय, मैंने सभी अस्थायी फ़ाइलों को इन-मेमोरी फ़ाइल सिस्टम में स्थानांतरित कर दिया। गैर-बदसूरत कोड की 8 नई लाइनें जोड़ी गईं, और अब सीपीयू का उपयोग 98% से ऊपर है। समस्या सुलझ गयी; कोई कुरूपता की आवश्यकता नहीं है।

Comments

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

— पॉल आर।

@PaRR आप उस कोड को कैसे रखते हैं? टिप्पणियों के रूप में? यह गलत है, imo - टिप्पणियाँ पुरानी हो गई हैं, कोई भी उन्हें नहीं पढ़ता है, और व्यक्तिगत रूप से अगर मुझे टिप्पणी कोड दिखाई देता है तो मैं आमतौर पर इसे हटा देता हूं - यह वह है जो स्रोत नियंत्रण के लिए है। एक विधि पर एक टिप्पणी जो यह बताती है कि यह बेहतर है, इमो।

— एवगेनी

@ यूजीन: मैं आमतौर पर एक रूटीन नाम का मूल संस्करण रखता हूं fooऔर इसे नाम देता हूं foo_ref- आमतौर पर यह fooस्रोत फ़ाइल में तुरंत ऊपर रहता है । मेरे परीक्षण हार्नेस में मैं कहता हूं fooऔर foo_refसत्यापन और सापेक्ष प्रदर्शन माप के लिए।

— पॉल आर

@Paul यदि आप कर रहे हैं कि परीक्षण को विफल करने के लिए एक अच्छा विचार हो सकता है यदि अनुकूलित संस्करण रेफरी फ़ंक्शन की तुलना में कभी धीमा हो। यह तब हो सकता है जब आप इसे तेजी से आगे बढ़ाने के लिए बनाई गई धारणाएं अब सच नहीं हैं।

— user1852503

Answer 2

यह एक गलत द्वंद्व है। आप कोड को तेज और आसान बनाए रख सकते हैं।

जिस तरह से आप इसे साफ लिखते हैं, विशेष रूप से यथासंभव सरल एक डेटा संरचना के साथ।

फिर आपको पता चलता है कि नालियां कहां हैं (इसे चलाने के बाद , आपने इसे लिखा है, इससे पहले नहीं), और उन्हें एक-एक करके ठीक करें। (यहाँ एक उदाहरण है।)

जोड़ा गया: हम हमेशा ट्रेडऑफ़ के बारे में सुनते हैं, सही, जैसे समय और मेमोरी के बीच एक ट्रेडऑफ़, या गति और स्थिरता के बीच एक ट्रेडऑफ़? हालांकि इस तरह के घटता अच्छी तरह से मौजूद हो सकते हैं, यह नहीं माना जाना चाहिए कि कोई भी दिया गया कार्यक्रम वक्र पर है , या इसके पास कहीं भी।

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

मेरे अनुभव में, यहीं से बहुत सारे कार्यक्रम शुरू होते हैं।

Comments

मैं सहमत हूँ। वास्तव में तेज कोड जो साफ नहीं है, वह धीरे-धीरे धीमा होने वाला है क्योंकि आप इसे ठीक से संशोधित नहीं कर सकते हैं।

— edA-qa मोर्ट-ओरा-वाई

मैं इस बात से सहमत नहीं हूँ कि यह एक गलत द्वंद्व है; IMO विशेष रूप से लाइब्रेरी कोड ( एप्लिकेशन कोड में इतना नहीं ) में परिदृश्य होते हैं जहां विभाजन बहुत वास्तविक है। अधिक के लिए मेरा जवाब देखें।

— मार्क Gravell

मार्क, आप "लिंक" URL के साथ टिप्पणियों में उत्तरों के लिए लिंक कर सकते हैं। programmers.stackexchange.com/questions/89620/…

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

— मार्टिन

मैं असहमत हूं कि यह एक गलत द्वंद्व है। क्योंकि मैं बहुत सारे ग्राफिक्स का काम करता हूं, मेरे लिए सबसे स्पष्ट उदाहरण तंग ग्राफिक्स छोरों में है: मुझे नहीं पता कि यह अभी भी कितनी बार किया गया है, लेकिन कोर रेंडरिंग के लिए असेंबली का उपयोग करने के लिए सी में लिखे गए गेम इंजन के लिए यह आम बात है। लूप्स गति के हर आखिरी बूंद को निचोड़ने के लिए। यह मुझे उन स्थितियों के बारे में भी बताता है जहाँ आप पायथन में प्रोग्राम करते हैं लेकिन C ++ में लिखे मॉड्यूल का उपयोग करते हैं। "पढ़ना मुश्किल" हमेशा सापेक्ष होता है; किसी भी समय आप गति के लिए निचले स्तर की भाषा में आते हैं, बाकी की तुलना में यह कोड पढ़ना कठिन है।

— झूल

Answer 3

अपने ओएसएस अस्तित्व में मैं प्रदर्शन के उद्देश्य से बहुत सारे पुस्तकालय का काम करता हूं, जो कि कॉलर के डेटा-स्ट्रक्चर (यानी लाइब्रेरी के लिए बाहरी) से गहराई से जुड़ा हुआ है , आने वाले प्रकारों पर कोई जनादेश नहीं है। यहां, इस प्रदर्शन को बनाने का सबसे अच्छा तरीका मेटा-प्रोग्रामिंग है, जो (जब से मैं .NET-लैंड में हूं) का मतलब IL-emit है। यह कुछ बदसूरत, बदसूरत कोड है, लेकिन बहुत तेज है।

इस तरह, मैं खुशी से स्वीकार करता हूं कि लाइब्रेरी कोड एप्लिकेशन कोड की तुलना में "बदसूरत" हो सकता है , बस इसे कम करें (या शायद नहीं) इनपुट पर नियंत्रण है , इसलिए विभिन्न तंत्रों के माध्यम से कुछ कार्यों को प्राप्त करने की आवश्यकता है। या जैसा कि मैंने दूसरे दिन व्यक्त किया:

"पागलपन की चट्टान पर कोडिंग, इसलिए आपको नहीं करना है "

अब एप्लिकेशन कोड थोड़ा अलग है, क्योंकि यह वह जगह है जहां "नियमित" (समझदार) डेवलपर्स आम तौर पर अपने सहयोगी / पेशेवर समय का अधिक निवेश कर रहे हैं; प्रत्येक के लक्ष्य और अपेक्षाएं (IMO) थोड़ी अलग हैं।

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

Comments

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

— तदमर्स

@tdammers वास्तव में, और मैं जहाँ तक संभव हो ऐसा करने की कोशिश करता हूँ; लेकिन यह एक सुअर पर लिपस्टिक लगाने की तरह थोड़ा सा है।

— मार्क Gravell

ठीक है, शायद किसी को बदसूरत सिंटैक्स और बदसूरत एल्गोरिदम के बीच अंतर करना चाहिए - बदसूरत एल्गोरिदम कभी-कभी आवश्यक होते हैं, लेकिन बदसूरत सिंटैक्स आमतौर पर अक्षम्य आईएमओ होता है।

— तदममर्स

यदि आप जो कर रहे हैं, तो @IMO बदसूरत वाक्यविन्यास बहुत अपरिहार्य है , यह सामान्य भाषा के स्तर के नीचे अमूर्तता के कई स्तर हैं।

— मार्क ग्रेवेल

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

— एक्सप्लोसिव

Answer 4

जब आपने कोड को प्रोफाइल किया और सत्यापित किया कि यह वास्तव में एक महत्वपूर्ण मंदी है।

Comments

और "महत्वपूर्ण" क्या है?

— रूक

@ hotpaw2: यह बुद्धिमान उत्तर है - यह मानता है कि डेवलपर्स कम से कम कुछ हद तक प्रतिस्पर्धी हैं। अन्यथा हाँ, बबल सॉर्ट की तुलना में तेज़ी से कुछ का उपयोग करना (आमतौर पर) एक अच्छा विचार है। लेकिन अक्सर किसी को (1 के साथ रखने के लिए) एक 1% अंतर के लिए हीप्सॉर्ट के लिए स्वैप क्विकॉर्ट, केवल किसी और को उसी कारण से छह महीने बाद वापस स्वैप करने के लिए देखना होगा।

नहीं है कभी नहीं गैर स्वच्छ कोड बनाने के लिए एक कारण। यदि आप अपने कुशल कोड को साफ और आसान नहीं बना सकते हैं तो आप कुछ गलत कर रहे हैं।

— eda-qa mort-ora-y

@SF। - ग्राहक हमेशा इसे बहुत धीमा पाएगा , अगर यह तेज हो सकता है। वह कोड के "निर्मल" की परवाह नहीं करता है।

— रूक

@Rook: ग्राहक को (तुच्छ) इंटरफ़ेस कोड बहुत धीमा लग सकता है। कुछ बहुत ही सरल मनोवैज्ञानिक तरकीबें वास्तव में कोड को तेज किए बिना उपयोगकर्ता के अनुभव को बेहतर बनाती हैं - मक्खी पर कार्रवाई करने के बजाय एक पृष्ठभूमि दिनचर्या के लिए बटन बटन घटनाओं को आगे बढ़ाएं, एक प्रगति पट्टी या ऐसा कुछ दिखाएं, कुछ बेहूदा सवाल पूछें जबकि गतिविधि पृष्ठभूमि में की जाती है ... यह तब होता है जब ये पर्याप्त नहीं होते हैं, आप वास्तविक अनुकूलन पर विचार कर सकते हैं।

— एसएफ।

Answer 5

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

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

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

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

Answer 6

चूंकि प्रश्न " कोड पढ़ने में तेज़ कठिन " कहता है , इसलिए सरल उत्तर कभी नहीं होता है। कोड लिखने के लिए कोई बहाना नहीं है जो पढ़ना मुश्किल है। क्यों? दो कारण।

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

Comments

मैं इस बात से सहमत नहीं हो सकता कि उत्तर "कभी नहीं" है। कुछ एल्गोरिदम स्वाभाविक रूप से समझने और / या कुशलता से लागू करने के लिए बहुत मुश्किल हैं। कोड को पढ़ना, टिप्पणियों की संख्या की परवाह किए बिना, एक बहुत ही कठिन प्रक्रिया हो सकती है।

— रेक्स केर

Answer 7

जब यह फेंक-दूर कोड है। मेरा मतलब है कि शाब्दिक रूप से: जब आप किसी एक गणना या कार्य को करने के लिए एक स्क्रिप्ट लिखते हैं, और ऐसी निश्चितता के साथ जानते हैं, तो आपको कभी भी उस क्रिया को दोबारा नहीं करना पड़ेगा कि आप बिना किसी हिचकिचाहट के 'आरएम सोर्स-फाइल' कर सकें, तो आप चुन सकते हैं बदसूरत मार्ग।

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

Comments

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

— मार्क व्हाइटेकर

मैं इस बात से सहमत नहीं हूँ कि यह एक गलत द्वंद्व है; IMO विशेष रूप से लाइब्रेरी कोड (एप्लिकेशन कोड में इतना नहीं) में परिदृश्य होते हैं जहां विभाजन बहुत वास्तविक है। अधिक के लिए मेरा जवाब देखें।

— मार्क Gravell

@मार्क, अगर "एक और सक्षम प्रोग्रामर" वास्तव में सक्षम है, तो थ्रो-दूर कोड को समस्या नहीं होनी चाहिए :)

@ मर्क - आसान। बस फेंक-दूर कोड लिखें, ताकि यह किसी भी उत्पादन परीक्षण में विफल हो जाए, शायद कुछ अयोग्य तरीके से।

— हॉटपावर 2

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

— माकु

Answer 8

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

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

Comments

एक अच्छा व्यापार परिप्रेक्ष्य, कभी-कभी प्रोग्रामर को केवल तकनीकी से परे देखने की आवश्यकता होती है।

— यह.जोश

Answer 9

मत भूलो कि आप हार्ड-टू-रीड कोड को उपयुक्त प्रलेखन और टिप्पणी द्वारा समझने में आसान बना सकते हैं।

सामान्य तौर पर, आपके द्वारा वांछित फ़ंक्शन करने के लिए आसान-से-पढ़ा गया कोड लिखने के बाद प्रोफ़ाइल। अड़चनें आपको कुछ ऐसा करने की आवश्यकता हो सकती हैं जो इसे और अधिक जटिल दिखती है, लेकिन आप खुद को समझाकर इसे ठीक करते हैं।

Answer 10

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

स्वाभाविक रूप से भी कोड को बनाए रखने के लिए सबसे मुश्किल है, भले ही यह पढ़ने में कितना आसान या कठिन हो, एक समस्या पैदा नहीं करता है अगर इसे बदलने का कोई कारण नहीं है, तो केवल इसका उपयोग करें। और इस तरह की गुणवत्ता को प्राप्त करना संभव है, विशेष रूप से निम्न-स्तरीय सिस्टम कोड के लिए जहां प्रदर्शन अक्सर सबसे अधिक गिनती करने के लिए होता है। मेरे पास C कोड है जो मैं अभी भी नियमित रूप से उपयोग करता हूं जो कि 80 के दशक के बाद से नहीं बदला है। तब से इसे बदलने की जरूरत नहीं है। कोड fugly है, बिट-फ़िडलिंग दिनों में लिखा गया है, और मैं मुश्किल से इसे समझता हूं। फिर भी यह आज भी लागू है, और इसका भरपूर उपयोग करने के लिए मुझे इसके कार्यान्वयन को समझने की आवश्यकता नहीं है।

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

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

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

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