आईडीई में डिबगिंग बेहतर क्यों है? [बन्द है]


145

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

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

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

मैं क्या खो रहा हूँ? नैदानिक printविवरणों के विचारशील उपयोग की तुलना में आईडीई डिबगिंग टूल इतना अधिक प्रभावी क्या है?

क्या आप ऐसे संसाधनों (ट्यूटोरियल, किताबें, स्क्रैनास्ट) का सुझाव दे सकते हैं जो आईडीई डिबगिंग की बारीक तकनीकों को दर्शाते हैं?


मीठे जवाब! समय निकालने के लिए सभी का बहुत-बहुत धन्यवाद। बहुत रोशन। मैंने कई लोगों को वोट दिया, और किसी को भी वोट नहीं दिया।

कुछ उल्लेखनीय बिंदु:

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

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

मैं सहमत हूं, यह सवाल लगभग दावा कर रहा है कि आप एक आईडीई में डिबगर के साथ डिबग नहीं कर सकते हैं यह मामला नहीं है। आप आईडीई के साथ या उसके बिना एक डिबगर चला सकते हैं, मुझे यकीन है कि वह जानता है कि हालांकि :) शायद वह विशिष्ट रूप से दृश्य डिबगर्स के बारे में पूछ रहा है?
हफीज

हां, दृश्य डिबगर्स। मुझे गैर-दृश्य डीबगर्स जैसे कि gdb के बारे में भी पता है, लेकिन इनमें एक ही प्रकार की वकालत नहीं मिलती है।
बिल करविन

मुझे लगता है कि आपके प्रश्न के साथ मुख्य मुद्दा यह है कि आप डिबगर के लिए आईडीई की गलती करते हैं। आप आईडीई में डिबगिंग के बारे में पूछते हैं, फिर भी आप आईडीई को डीबगर के साथ समान करते हैं और 'नॉन-आईडीई' का मतलब है कि वे डिबगर का उपयोग नहीं करते हैं। आईडीई! = डिबगर। मुझे आईडीई से नफरत है लेकिन मुझे डिबगर्स पसंद है, आपके प्रश्न का उत्तर देने के लिए मुझे आईडीई और डीबगर के लिए अलग-अलग बिंदुओं की व्याख्या करने की आवश्यकता होगी। यह पूछना पसंद है: "क्या पृथ्वी गोल है या मैं सिर्फ साइकिल खरीद सकता हूं?"
stefanB

6
@stefanB: मुझे अपने प्रश्न के कई अच्छे उत्तर मिले, जिससे पता चलता है कि आप अनावश्यक रूप से बालिग हो रहे हैं।
बिल कार्विन

जवाबों:


108

कुछ क्षमताओं के कुछ उदाहरण जो एक IDE डीबगर आपको कोड में ट्रेस संदेश देगा:

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

सारांश में, प्रिंट स्टेटमेंट (आम तौर पर) स्थिर होते हैं और यदि आपके मूल विवरण पर्याप्त रूप से विस्तृत नहीं थे, तो आपको अतिरिक्त जानकारी प्राप्त करने के लिए फिर से संकलन करना होगा। आईडीई इस स्थिर अवरोध को हटाता है, जिससे आप अपनी उंगलियों पर एक गतिशील टूलकिट दे सकते हैं।

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


3
गतिशील डिबगिंग पहलू एक अच्छा बिंदु है।
बिल करविन

2
घड़ियों की तुलना में, आप कोड के माध्यम से कदम रखते हुए एक चर नाम पर भी हॉवर कर सकते हैं और आपको मूल्य का टूलटिप मिलता है। आप टूलटिप में क्लिक करके भी उस मान को बदल सकते हैं। वह ruxx0rs।
जॉन डेविस

इनमें से अधिकांश एक आईडीई के साथ या उसके बिना इंटरैक्टिव डिबगर्स के गुण हैं। यानी, GDB के साथ उस सूची में सब कुछ (परिवर्तन कोड के संभावित अपवाद के साथ) संभव है।
dmckee --- पूर्व-मध्यस्थ ने बिल्ली का बच्चा

1
हां, लेकिन ओपी ने पूछा कि "क्या आईडीई डिबगिंग टूल नैदानिक ​​प्रिंट स्टेटमेंट के विचारशील उपयोग की तुलना में बहुत अधिक प्रभावी है?"। मैं आईडीई डिबगिंग टूल बनाम प्रिंट स्टेटमेंट की तुलना कर रहा था, न कि आईडीई डीबगिंग बनाम कंसोल डीबगिंग।
तेंदुआस्किलपबॉक्सहैट

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

34
  • एक आईडीई डिबगर आपको रन-टाइम पर चर के मूल्यों को बदलने देता है।

  • एक आईडीई डिबगर आपको उन चर का मूल्य देखने देता है जिन्हें आप नहीं जानते थे कि आप निष्पादन कब शुरू करना चाहते थे।

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

  • एक आईडीई डिबगर आपको एक शर्त के आधार पर कोड के किसी भी बिंदु पर सशर्त रूप से निष्पादन को तोड़ने देता है, न कि एक लाइन नंबर के आधार पर।

  • एक आईडीई डिबगर आपको केवल बाहर निकलने के बजाय एक अखंड अपवाद के मामले में कार्यक्रम की स्थिति की जांच करने देगा।


1
@Joe, बिल के सवाल के संदर्भ में, मुझे लगता है कि वे कर रहे हैं बराबर। बिल की छपाई के बारे में बात कर रहे हैं क्या डीबगर संपादक के साथ एकीकृत है और कंपाइलर उस बिंदु पर स्थिर है।
रोब केनेडी

बात यह है कि gdb, जो एक IDE डिबगर नहीं है, में ये सभी विशेषताएं हैं
Tamas Czinege

सवाल आईडीई डिबगर्स बनाम प्रिंट स्टाइल डिबगिंग के बारे में था, इसलिए मैं इसे वैसे ही छोड़ दूँगा।
पुनरावर्ती

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

16

यहां एक बात यह है कि आप निश्चित रूप से "प्रिंट" स्टेटमेंट के साथ डिबग नहीं कर सकते हैं, जो तब होता है जब कोई ग्राहक आपको मेमोरी डंप लाता है और कहता है "आपका प्रोग्राम क्रैश हो गया है, क्या आप मुझे बता सकते हैं?"


5
मैं अंतर्विरोधी हूं, एक डीबगर इसे कैसे हल करता है? अजीब और छिद्रपूर्ण बिंदु हालांकि :)
TheIronKnuckle

14
  • आपके कोड के माध्यम से सभी स्टेटमेंट को प्रिंट करना पठनीयता को कम करता है।
  • डीबग उद्देश्यों के लिए उन्हें जोड़ना और निकालना केवल समय लेने वाला है
  • डीबगर्स कॉल स्टैक को ट्रैक करना आसान बनाते हैं कि आप कहां हैं
  • चर को मक्खी पर संशोधित किया जा सकता है
  • निदान की सहायता के लिए तदर्थ आदेशों को निष्पादन के दौरान रोक दिया जा सकता है
  • प्रिंट विवरणों के साथ संयोजन में उपयोग किया जा सकता है: Debug.Write ("...")

1
उस सूची के लिए धन्यवाद। उन सभी बिंदुओं पर दृश्य डिबगिंग के फायदे नहीं हैं। उदाहरण के लिए, मैं कई भाषाओं के वातावरण में बहुत आसानी से स्टैक ट्रेस प्रिंट कर सकता हूं।
बिल करविन

1
# 2 के लिए: एक डिबगर को सर्वर से कनेक्ट करना और भी अधिक समय लेने वाला हो सकता है :)
इंक्रेडिबल

9

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

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


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

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

2
इसके अलावा, प्रिंट का उपयोग करना जरूरी है, यदि आप मल्टीथ्रेडेड दौड़ की स्थितियों से लड़ रहे हैं। ब्रेकपॉइंट आईडीई डीबगर का उपयोग करके इन बगों को ढूंढना व्यावहारिक रूप से असंभव है।
रादु ०

1
मेरे अनुभव में, प्रिंट स्टेटमेंट को जोड़ने से बहुपरत स्थितियों में मदद नहीं मिलती है क्योंकि प्रिंट ही कुछ प्रकार के थ्रेड सिंक्रोनाइज़ेशन का कारण बन सकता है जो बग की प्रकृति को बदल देता है।
the_mandrill

मैंने पहला वाक्य पढ़ने के बाद
अप

6

मेरे सर के ऊपर से चला गया:

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

लेकिन मैं इन दोनों चीजों को अब "मैनुअल" डिबगिंग का उपयोग करके कर सकता हूं ... चाहे कोड को इंजेक्ट करके या आईडीई मेनू विकल्पों की भूलभुलैया जैसी श्रृंखला का पता लगाकर।
बिल करविन

हाँ तुम कर सकते हो। लेकिन क्या आप वास्तव में चाहते हैं? आपने ऐसे कारणों के लिए पूछा कि आईडीई को डिबग का उपयोग करना बेहतर क्यों है, उन चीजों के लिए नहीं जो केवल आईडीई द्वारा प्रदान की जाती हैं।
केविन पैंग

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

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

युक्तियाँ @GranPeters के लिए धन्यवाद!
बिल करविन

4

आईडीई में डिबग के विकल्प के रूप में आप महान Google Chrome एक्सटेंशन PHP कंसोल के साथ php लाइब्रेरी की कोशिश कर सकते हैं जो इसके लिए अनुमति देता है:

  • Chrome जावास्क्रिप्ट कंसोल और सूचना पॉपअप में त्रुटियां और अपवाद देखें।
  • किसी भी प्रकार का डंप।
  • दूरस्थ PHP कोड निष्पादित करें।
  • पासवर्ड द्वारा पहुंच की सुरक्षा करें।
  • समूह कंसोल अनुरोध द्वारा लॉग करता है।
  • त्रुटि फ़ाइल पर जाएं: अपने पाठ संपादक में पंक्ति।
  • कॉपी त्रुटि / डिबग डेटा को क्लिपबोर्ड पर (परीक्षकों के लिए)।

3

मैं लगभग 20 वर्षों से विकास नहीं कर रहा हूं, लेकिन मुझे लगता है कि मैं आईडीई / डिबगर का उपयोग कर सकता हूं:

  • उन सभी प्रकार की चीजों को देखें जिन्हें मैंने प्रिंट स्टेटमेंट में शामिल करने के लिए नहीं सोचा होगा
  • कोड के माध्यम से यह देखने के लिए कि क्या यह मेरे द्वारा लिए गए पथ से मेल खाता है
  • कोड बनाने के लिए कुछ मूल्यों के चर निर्धारित करें

अच्छे अंक! निश्चित रूप से ये "पुनरावृत्ति, पुन: संपादन, भागो" की पुनरावृत्ति को कम कर सकते हैं।
बिल करविन

2

आईडीई का उपयोग करने का एक कारण यह हो सकता है कि आधुनिक आईडीई साधारण ब्रेकप्वाइंट से अधिक का समर्थन करता है। उदाहरण के लिए, Visual Studio निम्नलिखित डीबगिंग सुविधाएँ प्रदान करता है:

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

डीबगर का उपयोग करते समय, आपको डीबगिंग समाप्त करने के बाद अपने सभी प्रिंट स्टेटमेंट को हटाने की आवश्यकता नहीं होगी।


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

डिबग कोड को हटाने की मान्यता मान्य है, हालांकि मैं इससे छुटकारा पाने के लिए अक्सर "svn revert" कर सकता हूं।
बिल करविन

#ifdef DEBUG प्रिंटफ ("वेरिएबल जो अब% d \ n" है, var); fflush (stdout); #endif
आर्थर कल्लीकोस्की

@ M4N, बस एक संस्करण को पुनर्स्थापित करना बहुत आसान है।
पचेरियर

2

एक बात जो मुझे आश्चर्यचकित करती है कि मैंने दूसरे उत्तर में नहीं देखा है कि 2 डिबगिंग के तरीके परस्पर अनन्य नहीं हैं ।

printfडिबगिंग काफी अच्छी तरह से काम कर सकती है, भले ही आप एक मानक डिबगर का उपयोग कर रहे हों (चाहे आईडीई आधारित हो या नहीं)। विशेष रूप से एक लॉगिंग ढांचे के साथ ताकि आप ग्राहक की समस्याओं का निदान करने में मदद करने के लिए जारी उत्पाद में सभी या अधिकांश को छोड़ सकें।

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


एक अन्य उत्तर में परस्पर-अनन्य बिंदु शामिल नहीं था, लेकिन यह अच्छी तरह से लिया गया है।
बिल करविन

2

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

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

इसके विपरीत, प्रिंटआउट / लॉगिंग की एक चयनित श्रृंखला आपको "लौकिक घटनाओं का स्थानिक प्रक्षेपण" देती है। यह आपको पूरी कहानी देता है कि क्या हुआ था, और आप केवल ऊपर और नीचे स्क्रॉल करके बहुत आसानी से कई बार वापस जा सकते हैं। इससे "बी होने से पहले क्या हुआ" जैसे सवालों का जवाब देना आसान हो जाता है। यह आपको ऐसे पैटर्न दिखा सकता है जिन्हें आप खोज रहे हैं।

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

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

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

हाइब्रिड दृष्टिकोण भी हैं। उदाहरण के लिए, जब आप कंसोल.लॉग (ऑब्जेक्ट) करते हैं, तो आपको लॉग में एक डेटा-स्ट्रक्चर विजेट मिलता है जिसे आप विस्तार से और अधिक विस्तार से देख सकते हैं। यह "मृत" टेक्स्ट लॉग पर कई बार स्पष्ट लाभ है।


1

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

मानव मस्तिष्क केवल दुर्भाग्य से एकल-पिरोया हुआ है।


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

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

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

1

चूँकि आपने किताबों की ओर संकेत किया है ... जहाँ तक विंडोज डिबगिंग की बात है, जॉन रोबिन्स के पास विंडोज डीबगिंग पर एक अच्छी किताब के कई संस्करण हैं:

Microsoft .NET और Microsoft Windows के लिए अनुप्रयोग डीबग करना

ध्यान दें कि सबसे हाल का संस्करण ( Microsoft .NET 2.0 अनुप्रयोग डीबग करना ) केवल .NET है, इसलिए यदि आप मूल कोड डीबगिंग चाहते हैं, तो यह एक पुराना (पहले लिंक की तरह) हो सकता है (यह .NET और नेटिव दोनों को शामिल करता है)।


पुस्तक के लिए धन्यवाद! मैं शायद ही कभी Microsoft प्लेटफ़ॉर्म के साथ विकास का उपयोग करता हूं, लेकिन मैं संदर्भों की सराहना करता हूं।
बिल कार्विन

1

मुझे व्यक्तिगत रूप से लगता है कि इसका उत्तर उतना ही सरल है जितना कि "एक एकीकृत डिबगर / आईडीई आपको आदेशों में छिद्रण की आवश्यकता के बिना जल्दी से अलग-अलग सूचनाओं का खजाना देता है। जानकारी आपके सामने होने के लिए आपके बिना होती है। तुम्हें दिखाने।

आसानी से जानकारी प्राप्त की जा सकती है, वह केवल कमांड-लाइन डिबगिंग या "प्रिंटफ़" डीबगिंग से बेहतर है।


यह एक अच्छा सारांश या सामान्य कथन है, जो विशिष्ट उदाहरणों द्वारा प्रदान किए गए कई अन्य उत्तरों से मेल खाता है।
बिल करविन

चीयर्स बिल। मुझे लगता है कि बहस करने की सुविधा बनाम सुविधा व्यर्थ है क्योंकि आप ज्यादातर समय दोनों प्रकार के डिबगर में कर सकते हैं। एकीकृत लोग प्रक्रिया को बहुत सरल बनाते हैं (यदि वे अच्छी तरह से कर रहे हैं, जैसा कि वीएस के मामले में है)।
ओ जे।

1

एक प्रिंट पर डिबगर के लाभ ( आईडीई डिबगर नहीं, लेकिन किसी भी डीबगर पर ध्यान दें )

  1. चौकीदार सेट कर सकते हैं। यह मेमोरी करप्शन खोजने के मेरे पसंदीदा तरीकों में से एक है

  2. एक द्विआधारी को डीबग कर सकते हैं जिसे आप इस समय फिर से नहीं जोड़ सकते हैं

  3. एक द्विआधारी को डीबग कर सकता है जिसे पुन: व्यवस्थित करने में लंबा समय लगता है

  4. मक्खी पर चर बदल सकते हैं

  5. मक्खी पर कार्यों को कॉल कर सकते हैं

  6. समस्या नहीं है जहाँ डिबग राज्यमेन फ़्लश नहीं होते हैं और इसलिए समय समस्या को डीबग नहीं किया जा सकता है

  7. डीबगर्स कोर डंप के साथ मदद करते हैं, प्रिंट स्टेटमेंट न '


1

यह वही है जो मैं VS.NET डीबगिंग विंडो पर सबसे अधिक उपयोग करता हूं:

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

सारांश में, यह मुझे मेरे निष्पादन कोड की स्थिति का एक 360 डिग्री दृश्य देता है, न कि केवल एक छोटी सी खिड़की।

इस तरह के सामान को पढ़ाने वाली किताब कभी नहीं मिली, लेकिन फिर से, यह काफी सरल लग रहा है, यह बहुत WYSIWYG है।


अधिक जानने के लिए संसाधनों के संबंध में मेरे प्रश्न के भाग को कम से कम संबोधित करने के लिए +1।
बिल करविन

0
  • डिबगर एक रनिंग प्रक्रिया से जुड़ सकता है

  • अक्सर डिबगर से थ्रेडेड कोड को डीबग करना आसान होता है


0

IDE डिबगर के साथ जब भी आप निष्पादन रोकते हैं, तो आप वर्तमान स्कोप के सभी वैरिएबल (कॉल स्टैक के सभी तरह) के मूल्यों को देख सकते हैं।

प्रिंट स्टेटमेंट बहुत बढ़िया हो सकते हैं लेकिन किसी भी जगह पर स्क्रीन पर इतनी जानकारी डंप करने से एक संपूर्ण उत्पादन हो सकता है प्रिंट बयान की बहुत।

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

मुझे लगता है कि डिबगर्स कुछ भाषाओं के लिए दूसरों की तुलना में बेहतर हैं, लेकिन ...

मेरी सामान्य राय है कि IDE डिबगर्स बिल्कुल, आश्चर्यजनक रूप से प्रबंधित भाषाओं जैसे कि Java या C # के लिए अद्भुत हैं, C ++ के लिए काफी उपयोगी हैं, और पायथन जैसी भाषाओं की स्क्रिप्टिंग के लिए बहुत उपयोगी नहीं हैं (लेकिन यह हो सकता है कि मैंने अभी एक अच्छा प्रयास नहीं किया है किसी भी स्क्रिप्टिंग भाषाओं के लिए डिबगर अभी तक)।

जब मैं जावा विकास करता हूं, तो मैं IntelliJ IDEA में डिबगर से बिल्कुल प्यार करता हूं। जब मैं अजगर का उपयोग करता हूं तो मैं सिर्फ प्रिंट स्टेटमेंट का उपयोग करता हूं।


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

0

जैसा कि ऊपर किसी ने कहा: डीबगर! = आईडीई।

gdb और (दिन में वापस) TurboDebugger (स्टैंड-अलोन) उन भाषाओं के लिए ठीक काम करते हैं, जिनका वे समर्थन करते हैं [ed], धन्यवाद। (या इससे भी पुरानी तकनीक: क्लिपर डिबगर xBase निष्पादन योग्य में ही जुड़ा हुआ है) - इनमें से किसी को भी IDE की आवश्यकता नहीं है

हालांकि, C / ++ कोडिंग अधिक दुर्लभ है, फिर भी प्रिंटफ स्टेटमेंट कभी-कभी आपके द्वारा खोजे जा रहे बहुत बग से बाहर निकल जाते हैं! (उदाहरण के लिए, या स्मृति आवंटन / संरेखण के लिए स्टैक पर ऑटो वैरिएशन में समस्याएँ शुरू करना)

अंत में, जैसा कि दूसरों ने कहा है, आप दोनों का उपयोग कर सकते हैं। कुछ वास्तविक-समय-ईश समस्याओं में लगभग एक प्रिंट की आवश्यकता होती है, या कम से कम एक विवेकपूर्ण "* वीडियो_डबग = (=_गूड? '+': '-');" वीडियो मेमोरी में कहीं। मेरी उम्र दिख रही है, यह डॉस :-) के तहत था

TMTOWTDI


0

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

जहाँ तक सीखने के संसाधन जाते हैं, मैंने कोई उपयोग नहीं किया है - मैं बस सभी मेनू और विकल्प तलाशता हूँ।


0

क्या यह वास्तविक प्रोग्रामर से भी वास्तविक प्रश्न है?

जो कोई भी 5 मिनट खर्च करता है वह प्रिंट स्टेटमेंट के साथ डिबगिंग करता है और आईडीई के साथ डिबगिंग करता है - यह उसके बिना पूछे भी उसके साथ OCCUR होगा!


यह एक मजेदार सवाल है जो किसी "अन्नोन" के एक मोनिकर के साथ आ रहा है।
बिल करविन

वह आपके बीच सबसे बुद्धिमान है जो जानता है कि उसकी बुद्धि वास्तव में कुछ भी नहीं लायक है। (सुकरात)
जैक्स डे होगे

0

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


0

बस एक आईडीई में कंसोल डिबगर बनाम प्रिंटफ और बनाम डीबगर की एक उपयोगी विशेषता का उल्लेख करना चाहता था।

आप दूरस्थ अनुप्रयोग (obvioustly, संकलित DEBUG मोड) में संलग्न कर सकते हैं और POSIX teeउपयोगिता का उपयोग करते हुए डिबगर आउटपुट को फ़ाइल में डंप करते हुए उसके राज्य का निरीक्षण कर सकते हैं । प्रिंटफ की तुलना में, आप चुन सकते हैं कि रन-टाइम में राज्य को कहां आउटपुट करना है।

जब मैंने एग्रेसिव वातावरण में तैनात एडोब फ्लैश एप्लिकेशन को डीबग कर रहा था, तो इससे मुझे बहुत मदद मिली । आपको बस कुछ कार्यों को परिभाषित करने की आवश्यकता है जो प्रत्येक ब्रेकपॉइंट में आवश्यक स्थिति प्रिंट करते हैं, कंसोल डिबगर को शुरू करते हैं fdb | tee output.log, और कुछ ब्रेकपॉइंट के माध्यम से चलते हैं। उसके बाद आप लॉग को प्रिंट कर सकते हैं और विभिन्न ब्रेकप्वाइंट में राज्य की पूरी तरह से तुलना करके जानकारी का विश्लेषण कर सकते हैं।

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

वैसे, मेरी राय यह है कि एक डिबगर को घूरने से पहले कहां और क्या डिबग करना चाहिए, इसकी योजना बनानी चाहिए।


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

@ बिल कार्विन: मेरा मतलब किसी फ़ाइल में लॉग इन करने की क्षमता =) है
newtover

0

अच्छी तरह से एक और बात यह है कि यदि आप एक नई पुरानी परियोजना में शामिल होते हैं और कोई भी वास्तव में नहीं जानता है कि कोड क्या कर रहा है, तो आप चर / ऑब्जेक्ट्स गूंज कर डीबग नहीं कर सकते ... / b / c आपको पता नहीं है कि कोड क्या है बिल्कुल निष्पादित।

अपनी नौकरी पर मैं बिल्कुल उसी तरह की स्थिति का सामना कर रहा हूं और दृश्य XDebuging मुझे इस बात का अंदाजा लगाने में मदद करता है कि क्या चल रहा है और कहां, बिल्कुल भी।

सादर

Raffael


0

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

इसके अलावा, एक सभ्य डीबगर आपको ब्रेकपॉइंट्स की शर्तों और कार्यों को जोड़कर प्रिंटफ-स्टाइल डिबगिंग करने देगा, ताकि आप अभी भी प्रिंटफ डीबगिंग के लाभों को बनाए रखें, लेकिन कोड को संशोधित किए बिना।


0

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


0

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


0

वाउ, मुझे यह सवाल पसंद है। मैंने कभी इसे पोज देने की हिम्मत नहीं की ...

ऐसा लगता है कि लोगों के पास काम करने के अलग तरीके हैं। मेरे लिए सबसे अच्छा काम क्या है:

  • स्मृति प्रबंधन सहित मेरे कोड का एक ठोस माइंड मॉडल होना
  • इंस्ट्रूमेंटेशन (प्रिंट स्टेटमेंट की तरह) का उपयोग करके जो हो रहा है उसका पालन करें।

मैंने 40 से अधिक वर्षों के लिए अपनी लाइव प्रोग्रामिंग अर्जित की है, सी ++ और पायथन दैनिक में गैर-तुच्छ तकनीकी और वैज्ञानिक अनुप्रयोगों में काम कर रहा हूं, और मेरे पास व्यक्तिगत अनुभव है कि एक डिबगर मुझे कुछ मदद नहीं करता है।

मैं नहीं कहता कि यह अच्छा है। मैं नहीं कहता कि यह बुरा है। मैं इसे साझा करना चाहता हूं।


1
आपको क्यों लगता है कि यह एक अच्छा जवाब है? और क्या आपको लगता है कि यह Stackoverflow के लिए एक अच्छा सवाल है?
डेविड जी

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

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

क्या आप किसी भी (उच्च गुणवत्ता) फोरा (या शायद एसओ में टैग) के बारे में जानते हैं, जहां इस तरह के प्रश्न को अच्छी तरह से रखा जाएगा?
जैक्स डे होगे

एसओ नेटवर्क में कहीं नहीं है जहां एक राय प्रश्न की अनुमति दी जाती है मैं डरता हूं।
डेविड

-2

यह सिर्फ डिबगिंग नहीं है। एक आईडीई आपको कई तरह से तेजी से बेहतर सॉफ्टवेयर बनाने में मदद करता है:

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

मैं जा सकता था।


2
इर्र ... यह सवाल नहीं था।
वमर्केज

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

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