किन मामलों में कम कोड बेहतर नहीं है? [बन्द है]

55

मैंने हाल ही में काम पर कुछ कोड रिफलेक्ट किया है, और मुझे लगा कि मैंने अच्छा काम किया है। मैंने कोड की 980 लाइनों को 450 पर गिरा दिया और कक्षाओं की संख्या को आधा कर दिया।

मेरे सहयोगियों को यह दिखाते समय कुछ सहमत नहीं थे कि यह एक सुधार था।

उन्होंने कहा - "कोड की कम लाइनें जरूरी बेहतर नहीं हैं"

मैं देख सकता हूं कि ऐसे चरम मामले हो सकते हैं जहां लोग वास्तव में लंबी लाइनें लिखते हैं और / या कुछ लाइनों को बचाने के लिए एक ही तरीके से सब कुछ डालते हैं, लेकिन यह वह नहीं है जो मैंने किया था। कोड मेरी राय में अच्छी तरह से संरचित है और आधे आकार के होने के कारण समझने / बनाए रखने के लिए सरल है।

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

design coding-style code-quality

— PiersyP
स्रोत

145

कोड का आकार उस समय में मापा जाता है जब आपको इसे पढ़ने और समझने की आवश्यकता होती है, न कि वर्णों या वर्णों की संख्या।

— बरगी

13

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

— jpmc26

8

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

— मैकीज पाइचोटका

65

आपके प्रश्न का उत्तर देने के लिए समर्पित एक संपूर्ण स्टैक एक्सचेंज साइट है: codegolf.stackexchange.com । :)

— फेडेरिको पोलोनी

10

किस बिंदु पर

— बॉब टवे

124

एक पतले व्यक्ति को अधिक वजन वाले व्यक्ति की तुलना में स्वस्थ होना जरूरी नहीं है।

980 लाइनों के बच्चों की कहानी 450 पंक्तियों की भौतिकी थीसिस को पढ़ने में आसान है।

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

उदाहरण के लिए, यह हो सकता है कि जब आपने कोड की कुल लंबाई कम कर दी हो - आपने अतिरिक्त अनौपचारिक जटिलता का परिचय दिया और कोड को अधिक गूढ़ बना दिया।

छोटे तरीकों में कोड के एक लंबे टुकड़े को विभाजित करना उतना ही हानिकारक हो सकता है जितना कि फायदेमंद हो सकता है ।

अपने सहकर्मियों से आपको विशिष्ट प्रतिक्रिया प्रदान करने के लिए कहें क्योंकि उन्हें लगता है कि आपके रिफैक्टिंग प्रयासों ने अवांछनीय परिणाम उत्पन्न किया है।

— एमए हैनिन
स्रोत

1

@PyyPP सिर्फ एक FYI करें, मुझे एक अच्छे रीफैक्टरिंग के बारे में जो दिशा-निर्देश दिए गए थे, उनमें से एक यह है कि हमें साइक्लोमैटिक जटिलता को एक वर्गमूल में कम करके देखना चाहिए कि यह मूल रूप से क्या था।

— एमए हनिन

4

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

— एमए हनिन

6

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

— एसी

1

सिर्फ इसलिए कि यह आवश्यक नहीं है इसका मतलब यह नहीं है कि इसका मूल्य नहीं है।

— क्रिस वोहलर्ट

1

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

— कोड_ड्रेड

35

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

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

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

— कार्ल बेवफेल्ड
स्रोत

1

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

18

एक उद्धरण, अक्सर अल्बर्ट आइंस्टीन के लिए जिम्मेदार ठहराया जाता है:

सभी चीजों को जहां तक हो सके सरल बनाएं, लेकिन सरलतम नहीं।

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

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

अगर मैं कहूं var x = 2 + 2;, तो यह तुरंत स्पष्ट है कि xपूर्णांक होना चाहिए। लेकिन अगर मैं कहूं var foo = value.Response;, तो यह पूरी तरह से कम स्पष्ट है fooकि इसके गुणों और क्षमताओं का क्या प्रतिनिधित्व है या क्या है। यहां तक कि अगर कंपाइलर आसानी से इसका पता लगा सकता है, तो यह एक व्यक्ति पर बहुत अधिक संज्ञानात्मक प्रयास करता है।

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

— मेसन व्हीलर
स्रोत

7

varउदाहरण के सरलीकरण की एक विशेष रूप से अच्छा है क्योंकि समय पढ़ने का सबसे और कोड को समझने अमूर्त का एक निश्चित स्तर पर व्यवहार पता लगाना शामिल है, ताकि विशिष्ट चरों की वास्तविक प्रकार जानते हुए भी आम तौर पर कुछ भी नहीं बदलता है नहीं है (यह केवल कम सार को समझने में आपकी मदद करता है)। एक बेहतर उदाहरण एक सरल कथन में सरल कोड की कई पंक्तियाँ होंगी - जैसे if ((x = Foo()) != (y = Bar()) && CheckResult(x, y)) समय को टटोलना, और इसके प्रकारों को जानना xया yथोड़ी सी भी मदद नहीं करना।

— बेन कॉटरेल

15

लंबा कोड संभवतः पढ़ने में आसान हो सकता है। यह आमतौर पर विपरीत है, लेकिन बहुत सारे अपवाद हैं - उनमें से कुछ अन्य उत्तरों में उल्लिखित हैं।

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

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

— पीटर
स्रोत

4

'Pecritenc' के लिए +1, और उपदेशात्मक आक्षेपों का एक बहुत अच्छा सारांश जो कि पूर्ववर्ती होने से पहले पूर्व-निर्धारित होना चाहिए।

1

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

— डैरेन रिंगर

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

— एरिक Eidt

@nocomprende किसी भी कारण से आपने उपदेशात्मक, पूर्वगामी, और पूर्ववर्ती का उपयोग किया? शायद Pecritenc के समान विधि?

— मिलिंद आर

@MilindR संभवतः एक पूर्वधारणा, एक पूर्वधारणा, या शायद एक व्यक्तिगत प्राथमिकता? या, शायद बिल्कुल भी कारण नहीं है, कॉफ़ेक्टर्स का एक ब्रह्मांडीय संगम, साजिश रचने वाली स्थिति। कोई विचार नहीं, वास्तव में। आप कैसे हैं?

1

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

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

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

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

3

"दादा-दादी की कक्षाएं"! हौ हौ! बस एडम और ईव वर्गों के लिए बाहर देखो। (और निश्चित रूप से भगवान वर्ग) इससे पहले, यह रूपों के बिना था, और शून्य।

1

यह पूरी तरह से निर्भर करता है। मैं एक ऐसे प्रोजेक्ट पर काम कर रहा हूं जो बूलियन वेरिएबल्स को फंक्शन पैरामीटर के रूप में अनुमति नहीं देता है, बल्कि इसके enumलिए प्रत्येक विकल्प के लिए एक समर्पित की आवश्यकता होती है ।

इसलिए,

enum OPTION1 { OPTION1_OFF, OPTION1_ON };
enum OPTION2 { OPTION2_OFF, OPTION2_ON };

void doSomething(OPTION1, OPTION2);

की तुलना में बहुत अधिक क्रिया है

void doSomething(bool, bool);

हालाँकि,

doSomething(OPTION1_ON, OPTION2_OFF);

की तुलना में बहुत अधिक पठनीय है

doSomething(true, false);

कंपाइलर को दोनों के लिए एक ही कोड जनरेट करना चाहिए, इसलिए छोटे फॉर्म का इस्तेमाल करने से कुछ हासिल नहीं होगा।

— साइमन रिक्टर
स्रोत

0

मैं कहूंगा कि सामंजस्य एक समस्या हो सकती है।

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

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

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

— frcake
स्रोत

0

जब कम कोड समान कोड के समान कार्य नहीं करता है। सादगी के लिए विचार करना अच्छा है, लेकिन आपको ध्यान रखना चाहिए कि समस्या का समाधान उस स्थान से न हो जो इस समाधान से मिलता है। कोड की 980 लाइनें 450 से अधिक कोने के मामलों को संभाल सकती हैं।
जब कम कोड सुशोभित के रूप में अधिक कोड के रूप में विफल नहीं होता है। मैंने "अनावश्यक" ट्राइ-कैच और अन्य त्रुटि-केस हैंडलिंग को हटाने के लिए कोड पर कुछ "रेफरी *** थकाऊ" काम किया है। अपरिहार्य परिणाम त्रुटि के बारे में एक अच्छा संदेश के साथ एक संवाद बॉक्स दिखाने के बजाय था और उपयोगकर्ता क्या कर सकता था, ऐप क्रैश हो गया या YSODed।
जब कम कोड कम रख-रखाव / अधिक कोड से अधिक है। कोड की संक्षिप्तता के लिए रिफैक्टिंग अक्सर LoC के हित में "अनावश्यक" कोड का निर्माण करता है। परेशानी यह है कि उन कोड का निर्माण, जैसे समानांतर इंटरफ़ेस घोषणाओं, निकाले गए तरीके / उपवर्ग आदि आवश्यक हैं, इस कोड को कभी भी इससे अधिक करने की आवश्यकता है, या इसे अलग तरह से करना चाहिए। चरम में, कुछ विशेष समस्या के अनुरूप कस्टम-समाधान, यदि समस्या की परिभाषा थोड़ी सी भी बदलती है, तो यह बिल्कुल भी काम नहीं कर सकती है।

एक उदाहरण; आपके पास पूर्णांकों की एक सूची है। इनमें से प्रत्येक पूर्णांक में सूची में एक को छोड़कर, एक डुप्लिकेट मान है। आपके एल्गोरिथ्म को उस अप्रकाशित मूल्य को खोजना होगा। सामान्य-मामला समाधान प्रत्येक संख्या के विरुद्ध प्रत्येक संख्या की तुलना तब तक करना है जब तक कि आपको कोई ऐसा नंबर नहीं मिलता है जिसकी सूची में कोई डुप्लिकेट नहीं है, जो कि N ^ 2-टाइम ऑपरेशन है। आप हैशटेबल का उपयोग करके हिस्टोग्राम का निर्माण भी कर सकते हैं, लेकिन यह बहुत ही अंतरिक्ष-अक्षम है। हालाँकि, आप इसे बिटवाइज़ XOR ऑपरेशन का उपयोग करके रैखिक-समय और निरंतर-स्थान बना सकते हैं; एक चल रहे "कुल" (शून्य से शुरू) के खिलाफ प्रत्येक पूर्णांक को XOR करें, और अंत में, चल रहा योग आपके अनपेक्षित पूर्णांक का मान होगा। बहुत खूबसूरत। जब तक आवश्यकताओं में बदलाव नहीं होता है, और सूची में एक से अधिक संख्या अनपेक्षित हो सकती है, या पूर्णांक शून्य शामिल हैं। अब आपका कार्यक्रम या तो कचरा या अस्पष्ट परिणाम देता है (यदि यह शून्य देता है, तो क्या इसका मतलब है कि सभी तत्व जोड़े गए हैं, या कि अप्रकाशित तत्व शून्य है?)। इस तरह की समस्या वास्तविक दुनिया की प्रोग्रामिंग में "चतुर" कार्यान्वयन की समस्या है।
जब कम कोड अधिक कोड की तुलना में कम स्व-दस्तावेजीकरण होता है। स्वयं कोड को पढ़ने और यह निर्धारित करने में सक्षम होने के नाते कि यह टीम के विकास के लिए महत्वपूर्ण है। एक ब्रेन-एफ *** एल्गोरिथ्म देते हुए आपने लिखा है कि एक जूनियर डेवलपर के लिए खूबसूरती से काम करता है और उसे आउटपुट को संशोधित करने के लिए उसे पूछने के लिए कह रहा है कि यह आपको बहुत दूर नहीं जा सकता है। बहुत से वरिष्ठ देवों को उस स्थिति से भी परेशानी होगी। किसी भी समय यह समझने में सक्षम होना कि कोड क्या कर रहा है, और इसके साथ क्या गलत हो सकता है, एक काम कर रहे टीम के विकास के माहौल की कुंजी है (और यहां तक कि एकल; मैं आपको गारंटी देता हूं कि जब आप 5 लिख चुके थे, तो प्रतिभा का फ्लैश आपके पास था। -कैंसर को ठीक करने के लिए लाइन विधि लंबे समय तक चलने वाली है जब आप उस फ़ंक्शन पर वापस आते हैं जो इसे पार्किंसंस को भी ठीक करने के लिए देख रहा है।)

— Keiths
स्रोत

0

कंप्यूटर कोड को कई चीजों को करने की जरूरत है। "न्यूनतम" कोड जो इन चीजों को नहीं करता है वह अच्छा कोड नहीं है।

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

कंप्यूटर कोड "स्केलेबल" होना चाहिए। एक गुप्त कोड केवल एक विशेष अनुप्रयोग के लिए काम कर सकता है, जबकि एक लंबा, लेकिन अधिक खुला-समाप्त कार्यक्रम नए अनुप्रयोगों को जोड़ना आसान बना सकता है।

कंप्यूटर कोड स्पष्ट होना चाहिए। जैसा कि एक अन्य उत्तरदाता ने प्रदर्शित किया है, हार्ड-कोर कोडर के लिए एक लाइन "एल्गोरिदमिक" प्रकार का कार्य करना संभव है जो काम करता है। लेकिन औसत-प्रोग्रामर को स्पष्ट करने से पहले एक-लाइनर को पांच अलग-अलग "वाक्यों" में तोड़ना पड़ा।

— टॉम औ
स्रोत

ड्यूटी देखने वाले की नजर में है।

-2

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

— हंस जानसेन
स्रोत

4

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

— एलेफ़ेज़ेरो

1

@alephzero वाह, मुझे उस कोड को देखना अच्छा लगेगा, यह सिर्फ क्रे क्रे होना चाहिए।

@alephzero, अच्छे संकलक बहुत कुछ कर सकते हैं, लेकिन दुख की बात है कि सब कुछ नहीं। उज्ज्वल पक्ष यह है कि वे चीजें हैं जो प्रोग्रामिंग को दिलचस्प रखती हैं!

— हंस जानसेन

2

@alephzero वास्तव में, अच्छा मैट्रिक्स गुणन कोड बस थोड़ा सा समय नहीं काटता है (अर्थात इसे एक स्थिर कारक द्वारा कम करें), यह विभिन्न असममित जटिलता के साथ पूरी तरह से अलग एल्गोरिथ्म का उपयोग करता है जैसे स्ट्रैसोन एल्गोरिथ्म रफ हे (n ^ 2.8) बजाय O (n ^ 3)।

— आर्थर टाका