दूसरों के स्रोत कोड की व्याख्या करना [बंद]


9

नोट: मैं इस प्रश्न से अवगत हूँ । यह प्रश्न थोड़ा अधिक विशिष्ट और गहन है, हालांकि, इसे डिबग करने या लेखक से पूछने के बजाय वास्तविक कोड को पढ़ने पर ध्यान केंद्रित करना है।

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

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

मैं आम तौर पर पहले आम त्रुटियों की जांच करता हूं - एक्सट्रैक्ट ऑपरेटर्स आदि के बजाय अल्पविराम या कोष्ठक का उपयोग करना, अल्पविराम का उपयोग करना।

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

आप आमतौर पर दूसरों के स्रोत कोड को कैसे पढ़ते हैं? क्या आप शीर्ष-डाउन से कोड के माध्यम से पढ़ते हैं, या क्या आप प्रत्येक फ़ंक्शन का पालन करते हैं जैसे इसे कहा जाता है? आपको कैसे पता चलेगा कि "रिफैक्टर का समय क्या है?"


1
मैं कहूंगा: खराब प्रोग्रामर पर अपना समय बर्बाद न करें, यहां तक ​​कि कॉलेज में भी ... जब तक आप इसके लिए उनसे शुल्क नहीं लेते। सफलता के लिए ट्रिक यह है: इम को बेवकूफ बनाते हुए उनकी $ ले।
नौकरी

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

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

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

जवाबों:


22

पहला टिप: वाक्यविन्यास त्रुटियों, गलत तरीके से किए गए कोष्ठक और अन्य तुच्छ गलतियों को खोजने के लिए एक आईडीई (या बहुत अच्छा संपादक :)) का उपयोग करें।

दूसरा चरण: एक प्रारूप में सभी कोड जो आप के साथ सहज महसूस करते हैं, स्वतः पूर्ण करें। आपको लगता है कि यह ज्यादा मायने नहीं रखता लेकिन आश्चर्यजनक रूप से, यह करता है।

यदि वे खराब नाम वाले हैं तो स्थानीय चर का नाम बदलने से डरो मत। (यदि आपके पास पूर्ण प्रणाली तक पहुंच है, तो आप कुछ भी नाम बदल सकते हैं और आपको चाहिए।)

अपने आप को टिप्पणी जोड़ें जब आपको पता चलता है कि एक निश्चित कार्य / विधि क्या कर रही है।

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


मूल लेखक का सम्मान करते हुए भी मैं कैसे सुधार / नाम बदल सकता हूं? क्या मुझे टिप्पणियों को सामान की तरह छोड़ देना चाहिए // Renamed to ABC for XYZ?
मैक्समप

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

6
@Maxpm - आप कोड फ़ाइल की प्रतिलिपि बनाएँ। वह करें जो आप कभी भी करना चाहते हैं और फिर वापस जाएं और वहां सिस्टम पर समस्या को ठीक करने में उनकी मदद करें। अच्छा है कि मैं इसे कैसे करूंगा।
एरिन

@Maxpm कोड की एक प्रतिलिपि बनाएँ और इसे पहले astyle ( astyle.sourceforge.net ) के माध्यम से चलाएं । प्रोग्राम को सीखने वाले लोग शायद ही कभी सुसंगत कोडिंग शैली रखते हैं। कोड को ठीक से फ़ॉर्मेट करके देखने से उसे "पार्सिंग" करने में बहुत मदद मिलती है।
विटोर पाय

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

20

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


2
नीचे वोट क्यों? यह एक अच्छा विचार है।
मैट एलेन

मैं सहमत हूँ। बहुत अजीब लगता है।
माइकल के

@Matt ad Michael, ड्राइव-बाय-डाउनवॉटर, इतना नहीं कि आप मेरा अनुमान लगा सकें ...
Nim

एक अच्छा विचार है, लेकिन वास्तविक जीवन में आपको एक कोड दिए जाने की संभावना है "जो कि समर्थन से खिलता है जिसे आठ साल पहले काम पर पोर्न देखने के लिए निकाल दिया गया था" और फिर क्या, चलाने के लिए कोई नहीं है। साथ ही, किसी व्यक्ति द्वारा दिए गए स्पष्टीकरण का वास्तविक मूल्य क्या है जो संभवत: मूल बातें के साथ संघर्ष करता है?
१५:०५ पर biziclop

यह एक अच्छा जवाब है। उन्हें इस बात का कुछ अंदाजा होना चाहिए कि उन्हें क्या लगता है कि उनका कोड करने के लिए है या कम से कम वह ऐसा करना चाहते हैं।
जेफ़ो

3

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

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


+1 - कोड विकसित करना और अन्य लोगों द्वारा लिखे गए बग्स को ट्रैक करना 2 बहुत अलग कौशल हैं। नियोक्ता सराहना नहीं करते हैं कि उनके पास क्या है जब उन्हें कोई ऐसा व्यक्ति मिलता है जो दोनों को बहुत अच्छी तरह से कर सकता है।
डंक

2

सबसे पहले, अगर सिंटैक्स त्रुटियां हैं, तो आपको बस कंपाइलर त्रुटियों को ध्यान से पढ़ना होगा। अक्सर एक पंक्ति को त्रुटि के रूप में हाइलाइट किया जाता है, लेकिन यह वास्तव में पिछली पंक्ति थी जिसमें त्रुटि है।

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

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

ठीक है, तो क्या हुआ अगर कोई सिंटैक्स त्रुटियां नहीं हैं? फिर यह कोड के माध्यम से कदम रखने का समय है! आप इसके लिए डिबगर का उपयोग कर सकते हैं, लेकिन printfपूरे कोड में कॉल करना भी अत्यधिक प्रभावी है। उदाहरण के लिए, यदि कोई forलूप है, तो लूप काउंटर के लिए प्रिंट स्टेटमेंट में जोड़ें। नेस्टेड forलूप के मामले में , आप पा सकते हैं कि गलत चर को बढ़ाया जा रहा है।

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

अंत में, बस अपने मित्र से पूछें कि क्या हो रहा है! इसे देखने और कहने के बजाय "उह" उनसे पूछें कि वे क्या कर रहे हैं: "अब क्या करता nहै?" संवाद शुरू करने से, वे अपने स्वयं के प्रश्न का उत्तर दे सकते हैं, या, आप महसूस कर सकते हैं कि जिस तरह से उन्होंने कार्यक्रम की अवधारणा की थी उसमें दोष था, जो आपको समाधान की ओर ले जा सकता है।

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


1

मुझे यह कहने से नफरत है, लेकिन यहां कोई चांदी की गोली नहीं है।

सच कहूं तो अगर मैं यह समझने में सक्षम था कि दूसरों के कहने का मतलब क्या है जब उन्होंने लिखा कि उन्होंने 10% मामलों में भी क्या किया, तो मैं अब तक लाखों लोगों पर शक कर सकता था।

एक अधिक व्यावहारिक नोट पर, एक बुद्धिमान आईडीई का उपयोग करना चरण 1 है।

चरण 2 स्रोत कोड पदानुक्रम का पता लगाने के लिए doxygen या कुछ समान चलाने के लिए होगा ।

चरण 3 लंगर कार्यों या वस्तुओं का पता लगाना है, सामान जो आपकी कमांड लाइन या फ़ाइल को संसाधित करता है और फिर तर्क करता है।

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


1

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

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


1

मुझे अक्सर स्कूल में लैब में एक ही पूछा जाता था। आमतौर पर प्रश्न के साथ शुरू हुआ, "मैं इस संकलक त्रुटि को कैसे ठीक करूं?" इसलिए मैं झूलने else, अर्धविराम और इस तरह के झूलने पर बहुत अच्छा लगा । (मैक्रोज़ डिबग करने में भी मज़ेदार हैं - #define CUBE(x) x * x * xएक गलती है जो हम सभी को बनाने के लिए किस्मत में है।) एक फायदा यह था कि मैं एक ही शिक्षकों के साथ एक ही कक्षा से गुजरा था, इसलिए मैं पहले से ही आवश्यकताओं से परिचित था।

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

पूरा विचार दूसरे छात्र का मार्गदर्शन करने में मदद करना है। उनके लिए उनके कोड को फिर से लिखने से उन्हें सीखने में मदद नहीं मिलेगी।


#define CUBE(x) x * x * xप्रकार-असमानता के अलावा और क्या गलत है ?
जॉब

जब कहा जाता है CUBE(3), तो यह ठीक है। इसके साथ कॉल करें CUBE(x + 1)और आपको वह मिलता है x + 1 * x + 1 * x + 1जिसका सी में मूल्यांकन किया गया है x + (1 * x) + (1 * x) + 1। यह मूल्यांकन करता है कि 3x + 1कौन x <सुप> 3 </ sup> नहीं है! आप इसे घोषित करके ठीक करें #define CUBE(x) (x) * (x) * (x)
माइकल के

0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.