संकलक चेतावनी

Question

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

आप अक्षम्य चेतावनियों से कैसे निपटते हैं? क्या आप कोड के एक हिस्से को फिर से लिखते हैं, या इसे "लंबे, हैकलेस तरीके" में फिर से लिखते हैं या सभी को एक साथ चेतावनी अक्षम करते हैं? सबसे अच्छा अभ्यास क्या होना चाहिए?

क्या होगा यदि आप किसी और के कोड को संपादित कर रहे हैं और उसके कोड में चेतावनी है?

यहाँ एक अच्छा उदाहरण है: jQuery के पास बहुत सारे जावास्क्रिप्ट चेतावनियाँ हैं जैसा कि एक मोज़िला-वर्ग ब्राउज़र का पता चला है, क्यों jQ डेवलपर्स उन्हें ठीक नहीं करते हैं? यदि आप jQuery में योगदान करते हैं, तो क्या आप उन्हें ठीक करने जा रहे हैं?

Comments

क्या आप एक अक्षम्य चेतावनी का उदाहरण दे सकते हैं?

— स्वयं पर ध्यान दें -

परिभाषा द्वारा चेतावनी एक चेतावनी है। इसलिए इसे "निश्चित" होना जरूरी नहीं है। तो एक अक्षम्य चेतावनी क्या है?

— Rook

जावा में सामान्य प्रकार का उपयोग करना अक्सर एक चेतावनी उत्पन्न करता है। "फिक्स" करने का एकमात्र तरीका @ सप्रेस को जोड़ना है, जो बहुत साफ नहीं है, आईएमओ।

— माइकल के

Answer 1

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

चेतावनी को तुरंत ठीक करें (जिसमें व्यक्तिगत नियमों को अक्षम करना शामिल हो सकता है यदि आपको लगता है कि यह आपके संदर्भ के लिए प्रासंगिक नहीं है)।

Comments

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

— कार्सन63000

Answer 2

मेरी राय है कि आपको खुद से सख्त होना चाहिए। संकलक को भाषा में कुल विशेषज्ञों द्वारा लिखा गया है। यदि वे रिपोर्ट कर रहे हैं कि कुछ थोड़ा सा है (कोड गंध लगता है) तो कोड की समीक्षा की जानी चाहिए।

कोड लिखना पूरी तरह से संभव है जो त्रुटियों के बिना और चेतावनी के बिना संकलित करता है।

Comments

मैं निश्चित रूप से सहमत हूँ!

— को टिन मैन

मैं सहमत हूँ। ओपी: आपको 'टूटी हुई खिड़कियों' के बारे में पढ़ना चाहिए जैसा कि प्रोगैमैटिक प्रोग्रामर में डिक्रिप्ट किया गया है।

— कोई भी

Media.pragprog.com/articles/sep_02_zerotol.pdf

Answer 3

जब मैं सी और सी ++ में लिख रहा था तो मैं सबसे सख्त सेटिंग्स को सक्षम कर सकता था क्योंकि मैं जानना चाहता था कि कब कुछ संकलक के लिए समझ में नहीं आ रहा था। जब मुझे कास्टिंग मूल्यों की कास्टिंग और जाँच की गई तो मुझे खुशी होगी क्योंकि कोड उतना ही सही था जितना मैं इसे बना सकता था।

मुझे कभी-कभी किसी और से कोड मिल जाता था जो चेतावनी देता था। स्रोत की जाँच से पता चलता है कि वे उन चीज़ों की अनदेखी कर रहे थे जो C में अच्छी प्रोग्रामिंग प्रथा थी, जिससे उनका कोड नाजुक हो गया था।

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

Answer 4

मैं किसी भी चेतावनी को ठीक करूंगा। यदि आप उन्हें अनदेखा करते हैं और उन्हें जमा करते हैं, तो आप वास्तव में कुछ महत्वपूर्ण याद कर सकते हैं।

Answer 5

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

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

अपने बॉस से पूछें, और उसके अनुसार कार्य करें।

Answer 6

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

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

Answer 7

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

कहा जाता है कि, कभी-कभी कंपाइलरों में चेतावनी हो सकती है जो थोड़ा समझ में आता है और जिसे आसानी से तय नहीं किया जा सकता है। मैं हर दिन इस स्थिति का सामना टीआई कोडकंपोजर के साथ करता हूं, जो टीआई डीएसपी के लिए विकास का माहौल है। मेरे पास C ++ कोड है जो विज़ुअल स्टूडियो के तहत कोई चेतावनी के साथ संकलित करता है, लेकिन जिसके परिणामस्वरूप CodeComposer में अजीब चेतावनी मिलती है, बस इसलिए कि मानक C ++ के लिए TI का समर्थन बेहतर हो सकता है। सौभाग्य से, CodeComposer आपको व्यक्तिगत रूप से विशिष्ट चेतावनियों को अक्षम करने देता है, जो कि हमें करना होता है जब चेतावनी बनाने वाले कोड को ठीक करने का कोई तरीका नहीं होता है।

Answer 8

मेरे मामले में चेतावनी PyLint टूल से आती है और मैं टिप्पणियों में विशेष पाठ जोड़कर एक विशेष पंक्ति पर चेतावनी को अक्षम कर सकता हूं।

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

तो: लगभग सभी मामलों में, हैक से छुटकारा पाएं। जब हैक वास्तव में उचित हो, तो एक टिप्पणी जोड़ें जिसमें PyLint को ठीक बताया जाए।

Answer 9

सख्ती के कुछ लाभों को अन्य उत्तरों में स्पष्ट रूप से नहीं बताया गया है:

1. जब सभी आसानी से तय किए गए चेतावनियाँ तय हो गई हैं, तो शेष महत्वपूर्ण / प्रासंगिक चेतावनियाँ दिखाई देने की अधिक संभावना है।
2. यदि प्रासंगिक चेतावनी मिलती है और समय से पहले निपटा जाता है (रिलीज से पहले), तो कीड़े से बचा जा सकता है, इस प्रकार बेहतर उपयोगकर्ता संतुष्टि को जन्म देता है।
3. चेतावनी को हल करने से आमतौर पर अधिक रखरखाव योग्य और सरल कोड होता है (उदाहरण के लिए, हमेशा सही होने वाली स्थितियों को समाप्त करना)
4. जब चेतावनियों की मात्रा 0 के करीब होती है, तो टीम में जीरो चेतावन नीति पर सहमत होना आसान होता है, यानी CI सिस्टम में स्वचालित करना बहुत आसान है।
5. कंपाइलर चेतावनियों को हल करते समय, प्रोग्राम कोड की समझ गहरी हो जाती है, जिससे कार्यान्वयन के बारे में उपयोगी जानकारी प्राप्त हो सकती है (उदाहरण के लिए अन्य बग्स की खोज करें या विचार प्राप्त करें कि कोड को और कैसे विकसित किया जाए)
6. बिल्ड तेज हो जाता है, दैनिक उत्पादकता बढ़ जाती है: आईडीई / कंपाइलर के पास प्रबंधन और रिपोर्ट करने के लिए कम मुद्दे हैं, इस प्रकार संकलन तेज है (यह केवल हजारों चेतावनियों के संदर्भ में प्रासंगिक है)।

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

Answer 10

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

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

एक समाजशास्त्रीय दृष्टिकोण से, कई चेतावनी संदेश वाले प्रोग्राम ब्रोकन विंडोज हैं ।

Comments

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

— jmoreno