मैं अपने साथियों को कैसे मनाऊं कि हम संकलक की चेतावनी को नजरअंदाज न करें।

Question

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

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

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

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

धन्यवाद

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

Comments

सभी प्रकार: कच्चा माल, अप्रयुक्त आयात, अप्रयुक्त चर, अप्रयुक्त निजी तरीके, अनावश्यक सुप्रीत, अनियंत्रित, अनावश्यक कास्ट, अनावश्यक स्थिति (हमेशा सही या गलत), अघोषित ओवररिडेन विधियाँ, डिप्रेस्ड क्लास (विधियों) के संदर्भ में

«मैं खेल के नक्शे पर स्थिर" कोड "विश्लेषण लागू करना शुरू करना चाहता हूं, और चेतावनी को त्रुटियों के रूप में मानता हूं। »हाल ही में उद्धरण जॉन जॉन कार्मैक। अगर तुम पागल हो, तुम हो। दरअसल, हम तीन हम हैं।

— deadalnix

@ ब्रे: ये ग्रहण के कोड विश्लेषण से चेतावनी हैं, मुझे यकीन नहीं है कि आप वेनिला से इन सभी को प्राप्त कर सकते हैं javac।

— yatima2975

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

— JSB JS

@deadalnix: एक C ++ पुरुष होने के नाते, मेरे पास केवल एक ही काम है -Wall -Wextra -Werror(अर्थात, उपलब्ध अधिकांश चेतावनियों को सक्रिय करें, उन सभी को त्रुटियों के रूप में समझें)। ग्रहण C ++ हालांकि व्यर्थ है: /

— Matthieu M.

Answer 1

आप दो काम कर सकते हैं।

1. बताते हैं कि चेतावनी एक कारण के लिए है। कंपाइलर लेखक उन्हें नहीं डालते क्योंकि वे मतलबी होते हैं। हमारे उद्योग के लोग आमतौर पर सहायक होते हैं। कई चेतावनी सहायक हैं।

2. अनदेखी चेतावनियों से उत्पन्न होने वाली शानदार विफलताओं का इतिहास इकट्ठा करें। "कंपाइलर चेतावनियों पर ध्यान दें" के लिए एक वेब खोज कुछ उपाख्यानों को लौटाती है।

आपका जुनून @Overrideएक "जुनून" नहीं है। वह अच्छी बात है। कभी एक विधि नाम याद किया?

Comments

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

— डेनियल वर्नर

@ डैनियल: उदास, लेकिन सच है। यदि वे परवाह नहीं करते हैं, भले ही वे जानते हों (या कम से कम विश्वास करते हैं ) कि आप सही हैं, तो यह एक रोज़ी दृष्टिकोण के साथ एक काम नहीं है।

— जोकिम सॉर

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

— घीस

मुझे लगता है कि ओपी को बर्खास्त होने से रोकने के लिए सहकर्मियों की तलाश है। दी गई कई चेतावनियों को संबोधित नहीं किया जाना चाहिए और न ही उन सभी को होना चाहिए! लेकिन ब्लेज़ होना और उनमें से 10,000 को कोडबेस में रेंगने देना अच्छी बात नहीं है। चेतावनियों पर गौर किया जाना चाहिए, विचार किया जाना चाहिए, और यदि लागू नहीं होता है, तो उन्हें बंद कर दिया जा सकता है या लागू किया जा सकता है।

मैंने हाल ही में एक ओपन सोर्स प्रोजेक्ट में कुछ चेतावनियों के बारे में बताया और एक स्पष्ट बग पाया जो एक चेतावनी के माध्यम से रिपोर्ट किया गया था: के if (error = 0)बजाय if (error == 0)। इसके अलावा, बहुत सी चेतावनियाँ भी संकलक त्रुटियों को खोजने में आसान बनाती हैं, बिना चेतावनियों के चेतावनी के माध्यम से।

— ह्यूगो

Answer 2

यहां प्रासंगिक रीडिंग । सी ++, लेकिन अभी भी प्रासंगिक है। मैं विशेष रूप से इस उदाहरण को पसंद करता हूं (कोड टिप्पणी मेरी है):

int searchArray(int to_search[], int len, int to_find)
{
    int i;
    for( i = 0; i < len; ++i )
    {       
        if ( to_search[i] == to_find )
        {
            return i;
        }
    }
    // should be returning designated 'not found' value (0, -1, etc)
}

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

इसलिए, चेतावनी को ठीक करने के लिए (कम से कम) प्रबंधन के कई फायदे हैं:

1. उपयोगकर्ता-इनपुट डेटा के साथ अनुचित व्यवहार करने वाले कोड का कम मौका जो कि कंपनी की छवि के बारे में चिंतित उच्च-अप करने के लिए और यह अपने ग्राहकों के डेटा को कैसे संभालता है, एक बिग डील (tm) होना चाहिए। किसी उपयोगकर्ता को मूर्खतापूर्ण तरीके से कुछ करने से रोकने के लिए क्रैश करना बेहतर है कि दुर्घटना न करें और उन्हें ऐसा करने दें।
2. यदि वे कर्मियों में फेरबदल करना चाहते हैं, तो लोग एक चेतावनी-मुक्त कोडबेस में आ सकते हैं (और बाहर की तरह शिकायत नहीं करते हैं)। हो सकता है कि यह बड़बड़ा की मात्रा को कम कर देगा, या प्रोजेक्ट वाई को टीम एक्स के योगदान की स्थिरता या गुणवत्ता पर राय देगा।
3. कंपाइलर चेतावनियों को हटाकर कोड ऑप्टिमाइज़ करना, जबकि रनिंग टाइम में कोई महत्वपूर्ण सुधार नहीं करना, यह परीक्षण करने पर कई अंकों में सुधार करने वाला है:
   • किसी भी कोड कवरेज स्कोर में वृद्धि की संभावना होगी।
   • परीक्षण सीमा और अमान्य परीक्षण मामले अधिक बार सफल होंगे (उपरोक्त सुरक्षित टाइपकास्टिंग के कारण, अन्य बातों के अलावा)।
   • जब एक परीक्षण मामला विफल हो जाता है, तो आपको यह सोचने की ज़रूरत नहीं है कि क्या यह उस स्रोत फ़ाइल में संकलक चेतावनी के कारण है।
   • यह आसानी से यकीन है कि शून्य संकलक चेतावनी हजारों से बेहतर है। कोई चेतावनी या त्रुटियां कोड की गुणवत्ता के बारे में नहीं बोलती हैं, इसलिए आप तर्क दे सकते हैं कि कोड की गुणवत्ता कम चेतावनी को बेहतर बनाती है।
4. यदि आपके पास कोई संकलक चेतावनी नहीं है, और एक या एक से अधिक परिचय हैं, तो यह जानना बहुत आसान है कि किन लोगों ने कोडबेस में दिखाई दिया। यदि आपके पास "कोई चेतावनी नहीं" नीति है, तो यह उन लोगों की पहचान करने में मदद करेगा जो अपना काम ठीक से नहीं कर रहे हैं, शायद? कोड लिखना केवल कुछ काम बनाने के बारे में नहीं है, यह इसे अच्छी तरह से काम करने के बारे में है ।

ध्यान दें कि मैं अभी भी एक जूनियर देव हूं, जो परियोजना प्रबंधन के बारे में बहुत कम जानता है, इसलिए अगर मैंने कुछ गलत कहा है तो कृपया मेरी सोच को सुधारें और मुझे अस्तित्व से बाहर करने से पहले मुझे संपादित करने का मौका दें :)

Comments

प्रतिक्रिया के माध्यम से बहुत अच्छी तरह से सोचा। धन्यवाद। उदाहरण जो आप देते हैं वह जावा में एक चेतावनी के बजाय एक त्रुटि होगी। :)

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

— darvids0n

जब से मैंने C ++ किया है तब से यह एक समय है। यदि आप टिप्पणी पर अंत तक पहुँचते हैं तो वह क्या करता है? क्या यह 0 है? अपरिभाषित व्यवहार?

— मेट्रिक्सफ्रॉग

@ मेट्रिक्सफ्रॉग: अनिर्धारित। एक मनमाना इंट हो सकता है, जो सभी प्रकार की नाड़ियों का कारण बनेगा। इस उत्तर से उद्धरण : " C ++ 03 this6.6.3 / 2: किसी फ़ंक्शन का अंत फ़्लॉइंग करना बिना किसी मूल्य के रिटर्न के बराबर है; इससे मान-लौटाने वाले फ़ंक्शन में अपरिभाषित व्यवहार होता है। "

— darvids09

Answer 3

मैंने पिछले दिनों इसी तरह की विशेषताओं वाली परियोजना पर काम किया है। यह विशेष रूप से मूल रूप से जावा 1.4 में लिखा गया था। एक बार जब जेनेरिक के साथ जावा 5 बाहर आ गया, तो संग्रहकर्ता एपीआई के हर उपयोग के लिए कंपाइलर द्वारा फेंकी गई चेतावनियों की संख्या की कल्पना कर सकता है।

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

विरासत या गैर-मानक अनुपालन कोड (मानक आपके प्रोजेक्ट की कोडिंग मानक है) में बग्स पर बिताया गया समय बचा जा सकता था।

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

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

Comments

हाँ बिल्कुल। मुझे लगता है कि अपवादों की संख्या का प्रारंभिक विस्फोट 1.4-> 1.5 संक्रमण के दौरान हुआ था, और तब से, किसी ने भी अब और चेतावनियों पर ध्यान नहीं दिया क्योंकि अभी बहुत सारे हैं ...

Answer 4

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

Comments

या जब आप कोड को देखते हैं तो चेतावनी को ठीक करने पर ध्यान केंद्रित करें (नई कक्षाओं में कोई चेतावनी नहीं होनी चाहिए, आपके द्वारा संशोधित किसी भी वर्ग को कम चेतावनी होनी चाहिए)।

— मोनिका

गंभीर सवाल: आप कैसे जानते हैं कि वास्तविक कीड़े के परिणामस्वरूप कौन से सबसे अधिक हैं?

— MatrixFrog

Answer 5

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

1. अपने प्रत्येक जावा प्रोजेक्ट के लिए 'सेव एक्शन' को परिभाषित करें, जैसे कि कोडिंग कोड, अप्रयुक्त स्थानीय चर, आयात को व्यवस्थित करना (मुझे लगता है कि इस तरह की सफाई पर किसी को आपत्ति नहीं है)।
2. प्रत्येक परियोजना के लिए परियोजना विशिष्ट संकलन विकल्प परिभाषित करें। उदाहरण के लिए, संकलन स्तर (यदि आपके कोड को जेनेरिक से संबंधित चेतावनियों को साफ करने के लिए 1.4 के साथ संगत होना चाहिए), असाइनमेंट का कोई प्रभाव नहीं है (जैसे 'x = x') और इसी तरह। आप और आपकी टीम के साथी उन वस्तुओं के लिए एक अनुबंध कर सकते हैं, और संकलन त्रुटि के लिए समझौते के बाद ग्रहण आपको अपने विकास के चरण में 'त्रुटि' के रूप में रिपोर्ट करेगा।

ग्रहण उन वरीयताओं के लिए कुछ गुण फ़ाइलें बना देगा .settings फ़ोल्डर के तहत, आप उन्हें अन्य जावा परियोजनाओं पर कॉपी कर सकते हैं और स्रोत कोड के हिस्से के रूप में SCM में उनकी जांच कर सकते हैं।

आप ग्रहण के कोड को देख सकते हैं कि ग्रहण डेवलपर्स कैसे करते हैं।

Answer 6

आपके पास सभी चेतावनियों से छुटकारा पाने के दो तरीके हैं (और मैं मानता हूं कि यह एक सूक्ष्म बग को छिपा सकता है):

1. पूरी टीम को समझाएं कि यह सबसे अच्छा काम है, और उन्हें इसे ठीक करना है।
2. अपने बॉस को समझाएं कि यह सबसे अच्छा काम है, और इसे अनिवार्य बनाएं। फिर उन्हें इसे ठीक करने की आवश्यकता है।

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

तो, मेरा सुझाव है: इसे बॉस के साथ उठाएं, उसे समझाएं कि यह एक टिक बम है, और इसने आधिकारिक नीति बनाई है।

Answer 7

मैं उनसे बस इतना ही कहूंगा कि इनमें से अधिकांश महत्वहीन चेतावनी हैं और यह जरूरी है कि हम उन्हें सूची से हटा दें। ताकि हम भीड़ में वास्तविक महत्वपूर्ण चेतावनी को याद न करें, जैसा कि ऐसा होता है!

Comments

ठीक ठीक। यह उनसे छुटकारा पाने के लिए महत्वपूर्ण है क्योंकि वे महत्वहीन हैं।

— MatrixFrog

Answer 8

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

Answer 9

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

1. कॉनविंस प्रबंधन / टीम ऐसा करने के लाभों की ओर जाता है (खराब बिल्ड को तैनात होने से रोकना, कीड़े को जल्दी से ढूंढना, विशेष रूप से वे जो गलती से सॉफ़्टवेयर के अन्य हिस्सों को प्रभावित करते हैं, प्रतिगमन परीक्षण बनाए रखते हैं, जल्दी और अक्सर परीक्षण करते हैं, आदि)

2. सभी परीक्षण पासिंग के साथ CI सर्वर स्थापित करें (यदि आपके पास परीक्षण नहीं हैं, तो एक त्वरित लिखें जो पास हो, ताकि हर कोई देखे कि यह हरा है)।

3. प्रत्येक बिल्ड की स्थिति के बारे में ईमेल या अन्य सूचनाएं सेट करें। यहां यह जानना महत्वपूर्ण है कि किसने कोड में जांच की, क्या बदलाव हुआ (या कमिट का एक लिंक), और बिल्ड का स्टेटस + आउटपुट। यह एक महत्वपूर्ण कदम है, क्योंकि यह सफलताओं के लिए और विफलताओं के लिए टीम-वाइड दृश्यता का कारण बनता है।

4. यदि कोई चेतावनी हो तो परीक्षण विफल करने के लिए CI सर्वर को अपडेट करें। यह प्रबंधन द्वारा देखा जाएगा और टीम एक व्यवस्थित तरीके से टीम के अनुशासन को बढ़ाती है, और कोई भी सभी असफल ईमेल के लिए जिम्मेदार नहीं होना चाहता है।

5. (वैकल्पिक) इस के साथ अच्छा और geeky मिलता है, कुछ दृश्य डैशबोर्ड, लावा लैंप, चमकती रोशनी आदि को जोड़कर, निर्माण की स्थिति को इंगित करने के लिए और जिसने इसे तोड़ दिया / तय किया।