संकलक त्रुटियों की शब्दावली की कमी से निराश नौसिखिया प्रोग्रामर

66

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

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

तो, एक नौसिखिया प्रोग्रामर को कंपाइलर एरर मैसेजेस को समझने की चुनौती का सामना कैसे करना चाहिए? विशेष रूप से, सी और जीसीसी के संयोजन के साथ?

— einpoklum
स्रोत

7

"तो, एक नौसिखिए प्रोग्रामर को कंपाइलर एरर मैसेज को समझने की चुनौती का सामना कैसे करना चाहिए?" / व्यंग्य 1 आवश्यक कौशल को संकलक संदेश से हर बिट को पढ़ने में सक्षम होना चाहिए, जिसमें इसे बहुत ही संदर्भ के साथ संबंधित होना चाहिए। / कटाक्ष। यह शायद ही कभी एक दोष के रूप में निकलता है, या संकलक में बग होता है।

— atν

10

@MasonWheeler: एक नौसिखिया अक्सर प्रशिक्षण के दौर से गुजरने के लिए कौन से कंपाइलर का उपयोग नहीं करता है। और जीसीसी कई, कई प्रणालियों का एक आम भाजक है ...

— ईनपोकलम

24

जब यह जीसीसी सी ++ टेम्पलेट त्रुटियों की बात आती है, तो मुझे लगता है कि क्या मैं "त्रुटि <फ़ाइल: लाइन>" के बाद पढ़ना बंद कर देता हूं और स्रोत फ़ाइल (एस) का अध्ययन करता हूं, मुझे त्रुटि जल्दी मिल जाती है, मेरी पवित्रता बनाए रखने के अतिरिक्त दुष्प्रभाव के साथ, की तुलना में अगर मैं GCC द्वारा दी गई वास्तविक त्रुटि को पढ़ता हूं .....

— मैटनज़

18

समाधान स्पष्ट है: कम भ्रामक आउटपुट के साथ एक संकलक का उपयोग करें। मैं rmcc का सुझाव देता हूं । यह प्रिंट Yes.या No.यदि आपका कोड संकलित है या नहीं पर निर्भर करता है। लंबे और व्यर्थ संदेशों को न समझने की हताशा को तुरंत दूर करता है!

— पाइप

21

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

— थियोडोरोस चटजिआनियाकिन्स

164

कुछ उपयोगी तकनीकें:

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

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

23

एक अच्छा IDE भी उदाहरण के अनुसार अनुभव में मदद कर सकता है। लाल में त्रुटियों को रेखांकित करता है।

— ब्लूराजा - डैनी पफ्लुघोटे

86

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

— पॉलीग्नोम

4

@einpoklum: तीसरे विकल्प को कम मत समझना; संकलक त्रुटि संदेशों में बहुत सुधार हुआ है। एक समान नस में, कई संकलक (जैसे जीसीसी और क्लैंग) का उपयोग करें - अधिक त्रुटियों / चेतावनियों को पकड़ता है और उनमें से एक के लिए विशिष्ट मुद्दे के लिए एक बेहतर निदान हो सकता है।

— चटाई

19

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

— डॉक्टर ब्राउन

4

एक चाल जिसने मेरी मदद की: यदि त्रुटि संदेश में लाइन एन का उल्लेख है, तो लाइन एन -1 की जांच करें। उदाहरण के लिए, यदि आपको लाइन 17 पर एक अर्धविराम याद आ रहा है, तो त्रुटि संदेश यह कहेगा कि लाइन 18 में कुछ गड़बड़ है। ऐसा इसलिए है क्योंकि कंपाइलर अर्धविराम की उम्मीद कर रहा था, लेकिन इसके बजाय अगली पंक्ति में कुछ और मिला।

— user2023861

56

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

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

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

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

— रॉबर्ट हार्वे
स्रोत

17

नहीं, यह जानने के लिए भाषा को अच्छी तरह से जानना पर्याप्त है कि आप एक संख्यात्मक अभिव्यक्ति को असाइन नहीं कर सकते हैं, लेकिन केवल एक चर के लिए। आपको यह जानने की ज़रूरत नहीं है कि एक अंतराल क्या है, यही कारण है कि वे शुरुआती पाठ्यक्रमों में यह नहीं सिखाते हैं।

— रॉबर्ट हार्वे

18

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

— रॉबर्ट हार्वे

36

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

— रॉबर्ट हार्वे

14

[श्रग] यदि आप केवल अंग्रेजी के अपने पहले से मौजूद ज्ञान को पूरक करने के लिए एक शब्दकोश का उपयोग नहीं कर रहे हैं , तो मैं सुझाव दूंगा कि आप इसे गलत कर रहे हैं। आखिरी चीज जो मैं सुझाऊंगा वह यह है कि नौसिखिए प्रोग्रामरों को शब्दावली पर लटका दिया जाता है, क्योंकि वे पहले से ही अधिक हैं। प्रोग्रामर को अधिक शब्दों की आवश्यकता नहीं है; उन्हें और अधिक कौशल की

— रॉबर्ट हार्वे

13

@einpoklum, एक शब्दकोष यहाँ मदद करने के लिए नहीं जा रहा है। 'लवल्यू' शब्द का वर्णन या तो शुरुआती के लिए या 'कि एक काम के ई-बायीं ओर क्या हो सकता है' की तर्ज पर बहुत तकनीकी होने की संभावना है।

— बार्ट वैन इनगेन शेनॉ

26

उल्लेख के लायक एक प्रासंगिक तकनीक एक दूसरे संकलक का उपयोग कर रही है। उदाहरण के लिए, क्लैंग ने बेहतर त्रुटि संदेशों में निवेश किया है, लेकिन त्रुटि को वाक्यांश करने का कोई वैकल्पिक तरीका ज्ञानवर्धक हो सकता है।

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

— MSalters
स्रोत

13

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

"चेतावनी" अनुभाग "चेतावनी" अनुभाग की तुलना में बहुत आगे है। ऐसा लगता है कि यह G ++ पर लक्षित था, लेकिन वहां अभी भी आपके मित्र के उपयोग की कुछ जानकारी होने की संभावना है।

— nBurn
स्रोत

12

उपरोक्त उत्तरों के अलावा, ध्यान दें कि अधिकांश कंपाइलरों में व्यापक त्रुटि वाले शब्द नहीं होते हैं - ये बहुत सारे काम होंगे जैसे कि संदेश अक्सर बदलते रहते हैं, और उनमें से बहुत सारे होते हैं।

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

इसके अलावा, भाषा और संकलक के साथ समय और परिचितता आपकी ज़रूरत है। कार्ल बेलेफेल्ट द्वारा दी गई अच्छी सलाह और सलाह ।

— Dúthomhas
स्रोत

1

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

— ईनपोकलम

6

@einpoklum क्या आपने कभी PHP डॉक्स देखे हैं? ऐसा तब होता है जब आप समुदाय को उस सामान का ध्यान रखने देते हैं।

— केविन

4

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

— ज़ेनिलोगिक्स

2

यहां तक कि अगर एक शब्दकोष है मौजूद हैं, खोज इंजन उन तक पहुँचने के लिए सबसे अच्छा तरीका हो सकता है। जब आप अनचाहे क्षेत्र में होते हैं, तो

— स्पॉटिंग के

2

कॉलेज में, मुझे एक बार कंपाइलर की त्रुटि मिली "डेव को नहीं लगता कि ऐसा होना चाहिए। कृपया उसे <dave@example.com> पर ईमेल करें।" मैंने उसे ईमेल किया और वास्तव में मैं उस विशेष त्रुटि को हिट करने वाला पहला व्यक्ति था!

— user1118321

6

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

— supercat
स्रोत

11

C मानक एक बहुत ही सघन और भारी पाठ है। एक शुरुआत करने वाले के पास इसे समझने का कोई मौका नहीं है।

— निएडजेककोब

4

@NieDzejkob: संकलक द्वारा इस्तेमाल की जाने वाली शब्दावली - जो ऐसा लगता है कि सवाल क्या है - मानक से लिया गया है। जब आप सही होते हैं कि मानक के हिस्से समझ से बाहर हैं (भाग में क्योंकि यह समिति द्वारा डिज़ाइन किया गया है, और लेखकों को यह समझ में नहीं आ रहा है कि इसके कुछ हिस्सों का क्या मतलब है), लेकिन कोई भी यह समझना चाहता है कि क्या "लवल्यू" जैसे शब्दों का अर्थ होना चाहिए कि वे कहाँ से आए हैं। इसके अलावा, अगर कोई यह समझना चाहता है कि कुछ x=0x1e-xत्रुटि क्यों होती है, तो मैं वास्तव में मानक के अलावा कुछ नहीं जानता ...

— सुपरकैट

3

मैं @NieDzejkob से सहमत हूं: सी मानक उस तरह का पाठ नहीं है जिसे आप एक नौसिखिया के साथ सामना करना चाहते हैं। न्यूबीज को तेजी से सकारात्मक हाथों की आवश्यकता होती है । और उन्हें एक-एक करके नई चीजें सीखने की जरूरत होती है। जानकारी के साथ एक नौसिखिया पूरी तरह से ओवरलोडिंग करते समय एक मानक या औचित्य पढ़ना बहुत अधिक समय लगता है।

— cmaster

2

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

— सुपरकैट

3

@cmaster: किसी भी मामले में, जो कोई व्यक्ति C प्रोग्रामिंग कर रहा है, उसे मानक के बारे में पता होना चाहिए, और यह जानना चाहिए कि जरूरत पड़ने पर उसकी सलाह कैसे ली जाए, भले ही वे पूरी बात पढ़ने की कोशिश न करें। यदि कोई मानक लाइब्रेरी फ़ंक्शन के लिए एक वेब खोज करता है, उदाहरण के लिए, कोई ऐसा संदर्भ पा सकता है जो किसी कोने में एक कार्यान्वयन के व्यवहार का उल्लेख किए बिना उल्लेख करता है, तो मानक के दृष्टिकोण से, उन कोने के मामले अपरिभाषित व्यवहार और अन्य कार्यान्वयन को लागू कर सकते हैं उसी तरह काम नहीं करते। यदि कोई इसके बजाय मानक खोजता है, तो कोई भी उस समस्या से बच सकता है।

— सुपरकैट

5

मुझे आश्चर्य है कि किसी ने भी स्पष्ट उत्तर नहीं दिया और मुझे संदेह है, सबसे अधिक बार अभ्यास में उपयोग किया जाता है: बस त्रुटि संदेश नहीं पढ़ें।

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

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

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

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

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

— डेरेक एल्किंस
स्रोत

4

तो, एक नौसिखिया प्रोग्रामर को कंपाइलर एरर मैसेजेस को समझने की चुनौती का सामना कैसे करना चाहिए? विशेष रूप से, सी और जीसीसी के संयोजन के साथ?

अपने दोस्त को बताएं कि जब उन्हें समझ में नहीं आता है, तो एक त्रुटि का सामना करना पड़ेगा:

अंतिम सफल बिल्ड के बाद जोड़े गए कोड को निकालें / टिप्पणी करें।
इसके छोटे हिस्सों को वापस रखें और संकलित करें
जब तक त्रुटि न हो तब तक दोहराएं

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

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

अंत में, उन्हें एक समय में एक चीज पर काम करने के लिए कहें, बीच में संकलित किए बिना कई फाइलों में काम न करें, एक बार में कई निर्भरता का परिचय न दें, आदि।

— केविन
स्रोत

4

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

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

— ओवेन
स्रोत

1

इस दस्तावेज़ में बहुत महत्वपूर्ण पक्ष लाभ है कि इसे ऑनलाइन डाला जा सकता है (भले ही इसमें केवल 5-10 प्रविष्टियां हों) और इंटर्नशिप के लिए आवेदन करते समय एक महान विभेदक होगा।

— जोश मेम्बुत