क्या एक प्रोग्रामर के लिए कई बार अपने स्वयं के कोड पर 100% स्पष्टता नहीं होना सामान्य है? [बन्द है]

Question

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

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

क्या प्रोग्रामर्स के लिए यह सामान्य है कि वे जटिल कोड लिखते समय यह न समझें कि वे आधे समय क्या कर रहे हैं?

Comments

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

— SHODAN

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

— SJuan76

मेरे पास अपने कोड पर कभी भी 100% स्पष्टता नहीं है।

— कोडइन्कॉस्टोस नोव

यह 5D सरणी वास्तव में लगता है कि यह कुछ अमूर्त का उपयोग कर सकता है।

क्या किसी भी डेवलपर के पास हर समय उसके कोड पर 100% स्पष्टता है?

— जोहान

Answer 1

नहीं, यह सामान्य नहीं है ¹ । कम से कम, यह अच्छे प्रोग्रामर के लिए सामान्य नहीं है। यह शायद है किसी कार्यक्रम के लिए सीखने के लिए सामान्य।

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

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

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

---

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

Comments

[१] अधिक निराशावादी दृष्टिकोण से, यह सामान्य है लेकिन यह अच्छा नहीं है।

— दान

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

— रवांग

1-डी सरणी एक लाइन है, 2-डी एक ग्रिड है, 3-डी एक क्यूब है, 4-डी क्यूब्स की एक लाइन है, 5-डी क्यूब्स का एक ग्रिड है, आदि, लेकिन मुझे एक उपयोग नहीं दिखता है जब शतरंज की बात आती है तो ऐसी जटिल डेटा संरचना के लिए।

— 15:27 बजे user2785724

Answer 2

इसके दो प्रकार हैं: 1.) भ्रम 2.) आनंदित अज्ञान

पहला खराब है और समय और अनुभव के साथ गायब हो सकता है।

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

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

तो "न जानने" वास्तव में सॉफ्टवेयर विकास में एक निरंतरता है - यह सिर्फ यह है कि आप इसे कैसे प्रबंधित करते हैं या नहीं।

Comments

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

— क्रेग

Answer 3

मैं कहूंगा कि यह लोगों की देखभाल करने से ज्यादा आम है। यहां तक ​​कि ब्रायन कर्निघन ने भी इसे स्वीकार किया:

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

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

इसी तरह, हम अमूर्त के एक स्तर पर कोड लिखना पसंद करते हैं, लेकिन हम इसे अमूर्त की कई उच्च परतों में पढ़ना पसंद करते हैं। इसलिए कोड लिखने और पढ़ने का हमारा पसंदीदा तरीका संघर्ष है। इसका मतलब है कि कोड को पढ़ना आसान है, आमतौर पर कौशल का एक अलग सेट के साथ एक अलग, सचेत कदम है।

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

Comments

मुझे उस एक पर ब्रायन से असहमत होना पड़ता है, मुझे डिबगिंग बहुत पसंद है, मैं उन कुछ लोगों में से एक हूं, जिन्हें मैं इंडस्ट्री में जानता हूं, लेकिन मैं ऐसा कोड रेट नहीं करता, जो मैं लिखता हूं।

— जेम्स स्नेल

@JamesSnell उन्होंने यह नहीं कहा कि डिबगिंग खराब या अप्रिय है, केवल यह कि यह कठिन है, और जटिल कोड डीबग करना और भी कठिन है।

— कोबजार

Answer 4

मुझे लगता है कि यह कुछ ऐसा है जो अनुभव के साथ दूर चला जाएगा।

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

आपके पास बहुत से क्षण होंगे जहां आप 6 महीने पहले लिखे गए कुछ कोड को देख रहे हैं और सोच रहे हैं कि "यहां क्या हो रहा है?" कोड 'और अधिक।

स्रोत: कभी भी 5 आयामी सरणी का उपयोग नहीं किया गया :)

Comments

@ 83457 - क्योंकि 5d सरणी 2d समस्या का एक खराब मॉडल है। यदि आप वास्तव में सोचते हैं कि यह अच्छा कोड है तो इसे codereview.stackexchange.com पर छोड़ दें और देखें कि आपको क्या उत्तर मिलता है।

— जेम्स स्नेल

@ 83457 - अगर यह 'नरक के रूप में भ्रमित' है, तो आपने खुद को जवाब दिया है। यह संभव हो सकता है कि 5-डी सरणी भ्रमित नहीं हो रही है, लेकिन शायद हम में से अधिकांश के लिए नहीं, हमारे कौशल के स्तर पर कोई फर्क नहीं पड़ता।

— dbasnett 16

@ 83457 नरक के रूप में भ्रमित होने का उपयोग न करने के लिए पहले से ही एक बहुत अच्छी प्रेरणा होनी चाहिए।

— फैबियो मारकोलिनी

जब तक आपके पास प्रत्येक आयाम के लिए एक अच्छा कारण है, तब तक मुझे 5D सरणी से बचने का कोई कारण नहीं दिखता है। शायद एक बेहतर समाधान है, जैसे कि एक जटिल कुंजी या कई निचले आयामी सरणियों के साथ एक शब्दकोश, लेकिन मैं एक शतरंज एआई जैसी मुश्किल समस्या के लिए उपयुक्त 5 डी सरणी की कल्पना कर सकता हूं।

— कोडइन्कॉस्टोस नोव

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

— डेवॉर्ड

Answer 5

"सामान्य" बहुत व्यक्तिपरक है, इसलिए मैं कहता हूं: यह बहुत सामान्य है, लेकिन इससे बचा जाना चाहिए।

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

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

सम्बंधित:

• जब अंडरस्टैंडिंग का अर्थ है रीराइटिंग - कोड को समझने की समस्या के बारे में लेख।
• प्रभावी एमएल - एमएल / ओकेएमएल के बीच एक लंबी बात, "पाठकों" (यानी अनुरक्षक) के लिए कोड कैसे लिखें: "लेखकों पर अनुकूल पाठक।" मैं यह देखने की सलाह देता हूं कि आप चाहे किसी भी भाषा का उपयोग करें।

Answer 6

मुझे नहीं लगता कि यह सामान्य है, लेकिन बहुत जटिल कार्यक्रमों के लिए, जिस शतरंज कार्यक्रम का आप उल्लेख करते हैं, मुझे लगता है कि यह निश्चित रूप से संभव है।

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

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

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

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

Comments

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

— रवांग

@rwong धन्यवाद। इसका अधिकांश अनुभव यह है - मैं 46 वर्षों से कार्यक्रम लिख रहा हूं और मेरा जल्द से जल्द छोड़ने का कोई इरादा नहीं है।

— tcrosley

Answer 7

यहाँ बहुत सारे सभ्य उत्तर हैं।

मेरे पास इस पर कुछ जोड़े हैं।

एक यह है कि यदि आप यह नहीं समझते हैं कि आपका कोड क्यों काम करता है, तो a) यह शायद नहीं है (यह शायद केवल ऐसा लगता है कि यह काम करता है), और b) जब आप समस्या डोमेन को अच्छी तरह से समझ नहीं पाए, तो आप कोडिंग शुरू की, या समस्या डोमेन को छोटे, सरलीकृत इकाइयों में तोड़ने से पहले शुरू नहीं किया।

इस पर मेरी अन्य बात यह है कि असली कुंजी आपके कोड में सामान्य ज्ञान पैटर्न और सम्मेलनों का उपयोग करना है। यह एक छोटे से पोस्ट से बहुत बड़ा विषय है। लेकिन इस विषय पर अच्छे साहित्य की तलाश करें, जिनमें "कोड कम्प्लीट" और "राइटिंग सॉलिड कोड" जैसी कुछ पुरानी स्टैंडबाय शामिल हैं।

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

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

सॉफ्टवेयर से निपटने वाली अधिकांश समस्याएं प्रकृति द्वारा जटिल हैं। सॉफ्टवेयर डिजाइन जटिलता के प्रबंधन में एक अभ्यास है।

Answer 8

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

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

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