क्या आपको कोड पठनीयता के साथ कुशल कोड का त्याग करना चाहिए? [बन्द है]

37

क्या आपको कोड पठनीयता के साथ कुशल कोड का त्याग करना चाहिए?

जैसे 1 लाइन में कोड की 3 लाइनें।

मैं पीट गुडलिफ़ द्वारा कोड क्राफ्ट में पढ़ता हूं कि पठनीयता महत्वपूर्ण है।

तुम्हारे विचार?

13

आपको क्या लगता है कि कम लाइनों वाला कोड अधिक कुशल होने की संभावना है? यह शायद ही कभी आधुनिक भाषाओं के साथ होता है, हालांकि यह 8-बिट बेसिक दुभाषियों पर लागू हो सकता है।

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

69

न तो पठनीयता और न ही प्रदर्शन को लाइनों में मापा जाता है।

बहुत कम मामलों में, मैं गति के लिए पठनीयता का त्याग करता हूं, लेकिन बहुत कम ही। उच्च गति मशीनरी चलाने वाला एंबेडेड कोड एक मामला है। अधिकांश सॉफ्टवेयर के लिए, पठनीयता कहीं अधिक महत्वपूर्ण है।

— जिम सी

1

संबंधित जवाब: programmers.stackexchange.com/questions/39047/…

— निकोल

मैं हमेशा पठनीयता का पक्ष रखूंगा जब तक कि प्रदर्शन समस्या नहीं बन जाता। तब मुझे इसकी चिंता होने लगती।

— पीट

62

"कम लाइनों" हमेशा "अधिक कुशल" के रूप में एक ही बात नहीं है। मेरा मानना है कि "पठनीयता की कीमत पर एक कार्यक्रम को कम किया जाना चाहिए"।

कार्यक्रमों को लोगों को पढ़ने के लिए लिखा जाना चाहिए, और केवल संयोगवश मशीनों के निष्पादन के लिए।

-एबल्सन एंड सूसमैन, कंप्यूटर प्रोग्राम्स की संरचना और व्याख्या

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

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

— इनामाथी का पता चलता है
स्रोत

3

+1 कम रिटर्न दे रहा है, लेकिन मैंने यह भी पाया है कि एक छोटा प्रोग्राम आमतौर पर एक लंबे समय की तुलना में पढ़ना आसान होता है।

— माइकल के

23

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

— वेटिन

1

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

— विंको द सैन

एसआईसीपी के लिए + 1। बहुत बढ़िया किताब।

— जेसन येओ

30

कभी कभी हाँ।

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

बाद के एक उदाहरण के लिए, विकिपीडिया पर फास्ट इनवर्स स्क्वायर रूट लेख देखें।

मुझे आमतौर पर लगता है कि पहले कुछ पठनीय बनाना बेहतर होता है और बाद में प्रदर्शन की चिंता होती है, बशर्ते कि O (n) 2 से अधिक एल्गोरिथ्म जैसे O (n) को नहीं चुनना हो। अकेलेपन के लिए पठनीयता का त्याग करना, मेरे दिमाग में, गुमराह करने वाला है।

— एडम लीयर
स्रोत

4

मुझे लगता है कि "पठनीय कोड" और "एल्गोरिथ्म को जानने" के बीच अंतर हो सकता है। मुझे लगता है कि किसी भी कोड का अनुमान है, यदि आप एल्गोरिथ्म नहीं जानते हैं, तो पढ़ने और समझने के लिए कम या ज्यादा मुश्किल होगा। उदाहरण के लिए FISR मामले में, सादा कोड वास्तव में काफी पठनीय है, लेकिन एल्गोरिथ्म का दस्तावेजीकरण नहीं किया गया है। यदि आप FISR- एल्गोरिथ्म को जानते थे कि आप कितना अधिक पठनीय कोड लिख सकते हैं? बारीकी से संबंधित सवाल हो सकता है: जब एक फैंसी एल्गोरिदम चुनना है?

— मैग्लोब

@ मैग्लोब I विशेष रूप से 0x5f3759df के उपयोग की बात कर रहा था। प्रदर्शन के संबंध के बिना, आप ISR एल्गोरिथम को नियमित विभाजन का उपयोग करके उपयोग कर सकते हैं, जो कंप्यूटर इंटर्नल से परिचित कम व्यक्ति के लिए अधिक पठनीय होगा।

— एडम लेअर

3

यह शायद "के रूप में व्यक्त किया जा सकता है" यह कभी-कभी टिप्पणियों के 5 लाइनों और कोड के 20 लाइनों में व्यक्त परिष्कृत एल्गोरिथ्म और कोड की 5 पंक्तियों के साथ कोड की 20 पंक्तियों में व्यक्त एक भोली एल्गोरिथ्म को बदलने के लिए सही है "।

— पीटर टेलर

1

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

— Cercerilla

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

— मैथ्यू एम।

22

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

यह नहीं कहता है कि पुनर्लेखन को निश्चित रूप से अपठनीय होना चाहिए।

— ChrisF
स्रोत

22

मैंने इसे पहले उद्धृत किया था , और मैं इसे फिर से उद्धृत करूंगा:

इसे सही करें,
इसे स्पष्ट करें,
इसे संक्षिप्त करें,
इसे तेज़ बनाएं।

उस क्रम में।

वेस डायर

— बेनजोल को दर्शाता है
स्रोत

2

+1 यह सुनिश्चित करने के लिए मैं जल्दी से नीचे स्क्रॉल कर रहा था कि यह उद्धरण शामिल है। अब मुझे जवाब देने की जरूरत नहीं है। :-)

— रेशनलगीक

9

क्या आपको यह पता होना चाहिए कि कोड कितनी प्रभावी है?

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

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

मेरे दिमाग में, बिल्कुल कोई बहाना नहीं है कुछ बुनियादी टिप्पणियों के लिए नहीं। स्पष्ट रूप if ( x == 0 ) /* check if x is 0 */से पूरी तरह से बेकार है; आपको अनावश्यक शोर को कोड में नहीं जोड़ना चाहिए, लेकिन ऐसा कुछ:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

काफी मददगार है।

— user10197
स्रोत

6

क्या आपको यह पता होना चाहिए कि कोड कितनी प्रभावी है?

यदि दक्षता आपका वर्तमान लक्ष्य है (जैसे अनुकूलन चरण) और आप जानते हैं - आपके पास मैट्रिक्स हैं, तो नहीं? - कोड की वह लाइन (एस) वर्तमान अड़चन है, फिर हां।

अन्यथा, नहीं: पठनीयता आपको (या अन्य एक) इस कोड को बाद में बदलने में सक्षम होने के लिए और अधिक कुशल बनाने में सक्षम होगी, क्योंकि यह समझना आसान है।

— रिक्लेम कालेम है
स्रोत

4

कोई भी कोड गोल्फ नहीं जीतता

जैसे कोड की 3 लाइन 1 लाइन में

एक विशेष रूप से भयानक विचार।

कोड गोल्फ खेलने की लागत - बहुत अधिक है।

अपठनीय कार्यक्रमों को बनाए रखने की लागत - खगोलीय।

इस तरह के न्यूनतम कोड का मूल्य - शून्य। यह अभी भी काम करता है, लेकिन किसी भी "बेहतर" काम नहीं करता है।

बुद्धिमानी से चुना दक्षता

सही एल्गोरिथ्म और डेटा संरचना को चुनने की लागत - मध्यम।

सही एल्गोरिथ्म और डेटा संरचना को बनाए रखने के लिए लागत - कम।

सही एल्गोरिथ्म और डेटा संरचना का मूल्य - उच्च। संसाधन का उपयोग कम है।

मूर्खता ("सूक्ष्म अनुकूलन") दक्षता

सूक्ष्म अनुकूलन के आसपास खेलने की लागत - उच्च।

अपठनीय, सूक्ष्म अनुकूलित कोड को बनाए रखने की लागत - बहुत अधिक है।

सूक्ष्म-अनुकूलन का मूल्य - भिन्न होता है। जब यहां गैर-शून्य मूल्य होता है, तो लागत अभी भी इसे कम कर देती है।

— S.Lott
स्रोत

2

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

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

— rjzii
स्रोत

2

कई तरकीबें, जो कोड को तेजी से बनाने वाली थीं, लेकिन कोड को कम पढ़ने योग्य बनाते हैं, अब आवश्यक नहीं हैं, क्योंकि या तो कंपाइलर बहुत चालाक (यहां तक कि अधिकांश डेवलपर्स की तुलना में चतुर) या मशीनों ने हास्यास्पद तेजी से प्राप्त किया।

— LennyProgrammers
स्रोत

2

मैं "प्रदर्शन पर पठनीयता" तर्क स्वीकार नहीं करता। मुझे इस पर एक अलग स्पिन के साथ आपको जवाब देना चाहिए।

कुछ पृष्ठभूमि: आप जानते हैं कि मुझे क्या बीमारी है? जब मैं अपने कंप्यूटर पर डबल क्लिक करता हूं और मुझे वास्तव में इसके आबाद होने का इंतजार करना पड़ता है। यदि यह 5 सेकंड से अधिक समय लेता है, तो मुझे वास्तव में निराशा होती है। मूर्खतापूर्ण बात यह है, और इसके लिए Microsoft को दोष न दें, यह है कि कुछ मामलों में इसके इतने लंबे समय तक लेने का कारण यह है कि एक निर्णय किस आइकन को दिखाने की आवश्यकता है! ये सही है। इसलिए यहां मैं बैठा हूं, केवल मेरी सी: ड्राइव पर जाने में दिलचस्पी है, और मुझे अपने सीडी-रोम तक पहुंचने के लिए ड्राइवर का इंतजार करना होगा और वहां से आइकन पढ़ना होगा (यह मानते हुए कि ड्राइव में सीडी है)।

ठीक है। तो बस एक सेकंड के लिए मेरे बीच की सभी परतों की कल्पना करें कि मेरा कंप्यूटर डबल क्लिक कर रहा है और यह वास्तव में सीडी-रोम के ड्राइवरों के माध्यम से बात कर रहा है। अब कल्पना कीजिए कि हर परत ... तेज थी ...

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

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

— Maltrap
स्रोत

"ठीक है। तो बस एक सेकंड के लिए मेरे बीच की सभी परतों की कल्पना करें कि मेरा कंप्यूटर डबल क्लिक कर रहा है और यह वास्तव में सीडी-रॉम के ड्राइवरों के माध्यम से बात कर रहा है। अब कल्पना करें कि हर परत ... तेज ..." 2 डीवीडी के साथ मेरे लिए तुरंत ड्राइव्स

— रंगोरिक

एक शब्द: अपग्रेड

— jmort253

2

दोस्तों, मेरे साथ यहाँ काम करें, यह एक दृष्टांत है ...

— माल्ट्राप

@ रैंगरिक यही है कि मैं एक उपहार के बजाय बैसाखी के रूप में प्रौद्योगिकी में प्रगति का उपयोग करता हूं। यह उद्योग के लिए अच्छी तरह से काम करता है यदि आप उपयोगकर्ताओं को अपनी जेब अधिक बार खोलने के लिए मना सकते हैं।

— जोनाथन नेफेल्ड

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

— जोनाथन नेफेल्ड

2

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

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

— डिसलेट प्लैनेट
स्रोत

1

शायद ही कभी पठनीयता की कीमत पर कोड को तेजी से चलाने के लिए आरओआई इसके लायक होगा। आधुनिक कंप्यूटर इतनी तेजी से चलते हैं कि मुझे संदेह है कि ऐसा कोई परिदृश्य होगा जहां आप यह चाहते हैं। यदि कोई कंप्यूटर कोड चला रहा है, तो उस कोड को बनाए रखना होगा।

उस अंत तक, मुझे पठनीयता बहुत महत्वपूर्ण लगती है। बेशक, जैसा कि कई बार कहा गया है, सिर्फ इसलिए कि कोड पठनीय है इसका मतलब यह धीमा है जरूरी नहीं है।

एक अच्छा उदाहरण एक चर नाम है: $a

क्या है $a?? यह संदर्भ से बाहर है इसलिए आप इसका उत्तर नहीं दे सकते हैं लेकिन क्या आपने कभी वास्तविक कोड में इसे चलाया है? अब मान लें कि किसी ने लिखा है $file_handle- अब वह क्या है? यह संदर्भ से बाहर भी स्पष्ट है। चर नाम की लंबाई कंप्यूटर के लिए एक नगण्य अंतर बनाती है।

मुझे लगता है कि यहाँ होना सामान्य ज्ञान है।

कुछ अनुप्रयोगों में एक बिट-शिफ्ट शॉर्ट-कट हो सकता है, जो सभी को समझ में नहीं आएगा, लेकिन मुझे लगता है कि कुछ बिंदु पर कम रिटर्न है और एक परिदृश्य खोजना दुर्लभ है *।

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

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

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

इसलिए, व्यवहार में, मुझे लगता है कि आप अपने आप को या दूसरों को चोट पहुँचाने की अधिक संभावना रखते हैं ... (मैं अपना सप्ताहांत वापस पा लूंगा।)

— फ्रैंक वी
स्रोत

1

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

x++; // Add one to x

बल्कि, आपके लिए, ६ महीने या १२ महीने या कुछ अन्य पर्याप्त रूप से लंबे समय के लिए टिप्पणी करें। एक कोडिंग मानक अपनाएं, और उसका पालन करें।

— Throwback1986
स्रोत

"काम करने के लिए अपने संकलक पर भरोसा करें" के लिए +1। यह मेरी नई स्काइप टिप्पणी है।

— jmort253

0

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

इसके अलावा, आधुनिक संकलक निर्देशों को बहुत प्रभावी ढंग से अनुकूलित करते हैं। कोड की कितनी पंक्तियाँ आप कुछ करने के लिए टाइप करते हैं और निर्देशों के संदर्भ में कंपाइलर क्या बनाता है, यह आवश्यक रूप से संबंधित नहीं है। इस मामले को समझने के लिए संकलक पर पढ़ें।

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

— GrandmasterB
स्रोत

-1

पठनीयता अक्षम और आलसी प्रोग्रामर्स के लिए एक बहाना है (वास्तव में "सादगी" के लिए लागू होता है जब एक गंदे एल्गोरिथ्म / डिजाइन का बचाव करने के लिए एक तर्क के रूप में उपयोग किया जाता है)!

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

जैसा कि किसी और ने उल्लेख किया है कि अगर किसी समाधान के पहलुओं को "समझना मुश्किल है", तो यह है कि टिप्पणियाँ क्या हैं। आदेश "सही, पठनीय, तेज" (या ऐसा कुछ), जिसका किसी और ने उल्लेख किया है, वह केवल समय की बर्बादी है।

मेरे पास यह विश्वास करने के लिए वास्तव में कठिन समय है कि वहाँ प्रोग्रामर हैं, जो एक समस्या के साथ प्रस्तुत करते हैं जब वे लाइनों में सोचते हैं "... यह इस तरह से किया जाना चाहिए लेकिन मैं उस तरह से बनाऊंगा जो कम कुशल लेकिन अधिक पठनीय है / बनाए रखने योग्य और ऐसे अन्य बकवास ... "। इसका खामियाजा यह है कि अगले डेवलपर (अक्षमताओं को देखते हुए) शायद सबसे अधिक कोड को संशोधित करेगा और अगला भी ऐसा ही करेगा और ऐसा ही होगा ... अंतिम परिणाम यह है कि कुछ संस्करणों के बाद कोड वही बन जाएगा जो मूल है डेवलपर को 1 जगह लिखा होना चाहिए। मूल डेवलपर के लिए एकमात्र बहाना ए है। वह / वह इसके बारे में नहीं सोचती थी (पर्याप्त रूप से) और (जैसा कि पहले उल्लेख किया गया है) बी। समय और संसाधन की कमी।

— कोई व्यक्ति
स्रोत

-2

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

— www0z0k
स्रोत