आप एक आईडीई के बिना डिबग कैसे करते हैं? [बन्द है]


61

जब भी मैं एक IDE (वर्तमान में मैं गो के साथ छेड़छाड़ कर रहा हूं) देखता हूं, तो मुझे Vi, Emacs, Notepad ++ आदि की सिफारिश करने वाले लोगों से भरा एक धागा मिलता है।

मैंने आईडीई के बाहर कभी कोई विकास नहीं किया है; मुझे लगता है कि मैं खराब हो गया हूं। आप एक आईडीई के बिना डिबग कैसे करते हैं? क्या आप केवल लॉगिंग तक सीमित हैं?


53
जहाँ तक मुझे पता है Oldschool प्रिंटफ शैली डिबगिंग :-)
एंड्रयू वाल्टर्स

25
IDEs से पहले के दिनों में, हम डिबगर्स का उपयोग करते थे जो या तो एक रनिंग प्रोसेस से जुड़े होते थे या प्रोग्राम स्टेट की स्टेपिंग या आत्मनिरीक्षण की अनुमति देने के लिए प्रक्रिया को लपेटते थे। (gdb, perl -d, आदि ...) आईडीई में डीबगर्स का एकीकरण इसे सुविधाजनक बनाता है, लेकिन वे अलग से मौजूद हैं। असफल डिबगर्स, लॉगिंग ... बस सुनिश्चित करें कि लॉगिंग प्रोग्राम की स्थिति को तब नहीं बदलता है जब इसे वापस ले लिया जाता है और उस बग को फिर से शुरू करता है जिसे आप खोजने की कोशिश कर रहे थे।

7
कमांड लाइन डिबगर, (कई आईडीई डिबगर उन पर आधारित हैं)
शाफ़्ट फ्रीक

14
धीरे-धीरे और सावधानी से।
FrustratedWithFormsDesigner

3
जबकि प्रिंट काफी आम है इसका उपयोग कुछ कीड़े छिपा सकता है जो अधिक सूक्ष्म होते हैं जैसे दौड़ की स्थिति।
जेम्स

जवाबों:


86

डिबगर का उपयोग करके। अधिकांश भाग के लिए, यह वही है जो एक IDE पर्दे के पीछे करता है - यह केवल GUI में अनुभव को लपेटता है।

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

कमांड लाइन से डिबगिंग कैसा दिखता / महसूस होता है, इसका अंदाजा लगाने के लिए आप gdb मैनुअल देख सकते हैं ।

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


18
+1 के लिए "डिबगर का उपयोग करके"। आईडीई में I का अर्थ "एकीकृत" :) है
joshin4colours

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

1
@ साइरियन और इससे ipdbबेहतर है;)
इज़काता जनता

बहुत बढ़िया - मुझे नहीं पता था कि अस्तित्व में है, इज़काता। धन्यवाद।
अष्टसहस १r

@ joshin4colours एकीकृत! = संग्रह, नहीं?
कोल जॉनसन

35

मैंने ग्राफिक्स ड्राइवरों को लिखते समय कई वर्षों तक डिबगर का उपयोग किया। मेरे पास एक दूसरा कंप्यूटर था जो पहले वाले के खिलाफ डिबगर चलाता था (क्योंकि प्राथमिक कंप्यूटर में स्क्रीन तब काम नहीं करता था जब ग्राफिक्स ड्राइवर टूट गया था)। यह महत्वपूर्ण था कि मैं उस बिंदु पर कोड और स्टेप को रोक सकूं जहां मैंने हार्डवेयर लटका दिया था ताकि मुझे पता चल जाए कि क्या हो रहा है।

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

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

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


7
इस। बिल्कुल यह। मुझे लगता है, कि कम से कम मेरे लिए, समस्याएं तर्क त्रुटियों या इंटरैक्शन की होती हैं जो एक डिबगर किसी भी अधिक स्पष्ट नहीं करेगा। आपको समझना होगा कि कुछ गलत क्यों हो रहा है, न कि क्या
फेक नेम

2
+1 पूरी तरह से going backwards। मैं अक्सर अनुभव है: "अरे - waittaminute, यह सही मूल्य है कैसे किया यह बन इस ?", और कोड को पढ़ने के दौरान उत्पादन में आगे और पीछे जाना है। डीबगर्स पीछे की तरफ खराब हैं।
इजाकाता

हाँ, जीडीबी डंप किए गए कोर की जांच करने के लिए अच्छा है, लेकिन इस तरह की स्थितियों में, मैंने पाया कि प्रिंट स्टेटमेंट्स के गंभीर उपयोग ने वास्तव में मदद की।
ब्रायन

डिबगर उपयोगी हैं, लेकिन अल्पकालिक हैं। एक अच्छे लॉगिंग ढांचे के साथ, मुझे लगता है कि मैं अपने डिबगिंग सत्र का निर्माण कर सकता हूं। डिबगिंग सत्र को स्थायी बनाने के लिए प्रिंट स्टेटमेंट के साथ पूरक, स्थिति को समझने में मदद करने के लिए डीबगर का उपयोग करें। मुझे लगता है कि समय के साथ मैंने डिबगर पर कम से कम मुकदमा किया और अधिक से अधिक उत्पादक बन गया
न्यूटोपियन

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

11

कुछ लोग कमांड लाइन, या एक प्लगइन पर gdb का उपयोग करते हैं । डीडीडी की तरह जीडीबी में स्टैंडअलोन जीयूआई फ्रंट एंड भी हैं । आपकी भाषा के आधार पर, भाषा-विशिष्ट स्टैंडअलोन डीबगर GUI हैं, जैसे कि अजगर के लिए Winpdb , या जावा के लिए jswat । क्योंकि ये परियोजनाएं केवल डिबगिंग पर ध्यान केंद्रित करती हैं, वे अक्सर एकीकृत डिबगर्स से बेहतर होती हैं।

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


1
+1 कोर्स का दूसरा विकल्प आईडीई के संपादक पर रंग योजना और कीबाइंड सेट करना है, और नाटक करना :)
darvids0n

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

6

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


2

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


3
"एक समय था जब एक कार्यक्रम को फिर से शुरू करने और लिंक करने में बहुत लंबा समय लगता था, लेकिन आज सिर्फ कुछ सेकंड लगते हैं"। आपकी भाषा और परियोजना के आकार पर निर्भर करता है। अगर मैं अपने वर्तमान प्रोजेक्ट में हेडर फ़ाइल को बदल दूं, तो 32-सीपीयू मशीन को 256GB RAM (मैं मज़ाक नहीं कर रहा) पर पुनर्निर्माण में लगभग 65 मिनट लगेंगे
Nemanja Trifunovic

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

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

2

jimwise ने इस सवाल का काफी अच्छे से जवाब दिया, लेकिन मुझे लगा कि मुझे इसे जोड़ना चाहिए, क्या आपको पूरी आईडीई के बिना काम करना चाहिए, माइक्रोसॉफ्ट ने विंडोज के लिए कमांड लाइन डिबगर को सीडीबी कहा है । CDB कई अन्य टूल के साथ आता है, जिसमें WinDBG भी शामिल है जो GUI के बराबर है, जब आप Windows SDK डाउनलोड करते हैं।


4
क्या आप कृपया अधिक विवरण में बता सकते हैं कि प्रश्न का उत्तर कैसे दिया जाता है?
जन्नत

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

2

मैं आमतौर पर एक डिबगर का उपयोग नहीं करता हूं, शायद हर दो सप्ताह में एक बार।

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

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

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

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

यदि आप तर्क और डिबग / ट्रेस लेवल का उपयोग करने के साथ-साथ सभी कोडिंग कर रहे हैं, तो यह केवल आपके उत्कृष्ट लॉग स्टेटमेंट की जांच करने का मामला हो सकता है (संभवतः लॉग स्तर को बढ़ाकर) हार्डवेयर तक पहुंच के बिना समस्या का पता लगाने के लिए।

हालाँकि मुझे लगता है कि डीबगर एक शक्तिशाली उपकरण हैं, लेकिन उन्हें अपने टूलबॉक्स में एकमात्र उपकरण न बनने दें!


1

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

यह ध्यान देने योग्य है कि व्यापक परीक्षण डिबगिंग को विस्थापित करता है। एक रिपोर्ट किए गए बग को आपके कोड के बजाय आपके परीक्षण में बग होना महत्वपूर्ण माना जाता है।

वहाँ भी है printf। प्रत्येक पंक्ति के लिए रुकने के बजाय "लॉगिंग" की एक बड़ी मात्रा बनाने और इसके माध्यम से खोज करने के लिए उपयोगी हो सकता है। मुझे विशेष रूप से उपयोगी लगता है यदि आप लाइब्रेरी कक्षाओं को संशोधित कर सकते हैं जिसे आप -Xbootclasspath/p:जावा लाइब्रेरी कक्षाओं को हैक करने के लिए उपयोग करके उत्पादन में संशोधित नहीं कर पाएंगे ।


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

1

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

आप pudb का उपयोग कर सकते हैं जो कि एक साधारण यूजर इंटरफेस के साथ कंसोल आधारित है। यदि आप एक REPL दर्ज करना चाहते हैं और अधिक विस्तार से जांच करना चाहते हैं तो आप अपने पसंदीदा डीबगर जैसे pdb या ipdb को चुन सकते हैं।

उपलब्ध उपकरणों के अधिक व्यापक संग्रह के लिए कृपया PythonDebuggingTools Wiki को भी देखें।


मूल प्रश्न गो के बारे में था, अजगर के बारे में नहीं।
TMN

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