सीडीके बनाम फाइंडबग्स

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

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



डिफ़ॉल्ट सेटिंग्स के साथ FindBugs ने 338 समस्याओं का पता लगाया। बेशक, मैं उन सभी का वर्णन नहीं करूंगा, मैं दिलचस्प लोगों पर ध्यान केंद्रित करूंगा।

1. एक यादृच्छिक सकारात्मक संख्या प्राप्त करने का असफल प्रयास

वर्ग में org.openscience.cdk.math.RandomNumbersTool:

public static int randomInt(int lo, int hi) { return (Math.abs(random.nextInt()) % (hi - lo + 1)) + lo; } 

Random.nextInt () विधि इंट में मान्य किसी भी संख्या को लौटाती है। Math.abs पद्धति को संख्या का मॉड्यूल मिलता है। समस्या यह है कि Math.abs Integer.MIN_VALUE के लिए काम नहीं करता है, क्योंकि, जैसा कि आप जानते हैं, इसके विपरीत संख्या इंट में फिट नहीं होती है। हालांकि, रैंडम.नेक्स्टइंट () अच्छी तरह से इस संख्या (लगभग हर 4 बिलियन) का उत्पादन कर सकती है, फिर पूरी विधि गलत तरीके से काम करेगी।

2. अशक्त के लिए BufferedReader.readLine () के परिणाम की जाँच नहीं की जाती है

यह कई बार होता है, उदाहरण के लिए, इस रूप में (org.openscience.cdk.io.CIFReader):

 private void skipUntilEmptyOrCommentLine(String line) throws IOException { // skip everything until empty line, or comment line while (line != null && line.length() > 0 && line.charAt(0) != '#') { line = input.readLine().trim(); } } 

रेडी () विधि द्वारा तत्परता के लिए इनपुट स्ट्रीम की जांच नहीं की जाती है, और रीडलाइन () के परिणाम को शून्य के लिए चेक नहीं किया जाता है। नतीजतन, एक विकृत इनपुट फ़ाइल NullPointerException को फेंक देगी।

3. प्रयुक्त और के बजाय &&

इस तरह की एक तुच्छ त्रुटि (org.openscience.cdk.atomtype.CDKAtomTypeMatcher):

 if (atom.getFormalCharge() != null & atom.getFormalCharge().intValue() == 1) {...} 

यदि पहला चेक विफल हो जाता है, तो दूसरा किसी भी तरह से विफल हो जाएगा और परिणामस्वरूप NullPointerException होगा।

4. स्ट्रिंग की तुलना, पूर्णांक या डबल ऑब्जेक्ट्स == द्वारा

ऐसा कई बार होता है। उदाहरण के लिए, यहाँ (org.openscience.cdk.AtomType.compare):

 return (getAtomTypeName() == type.getAtomTypeName()) && (maxBondOrder == type.maxBondOrder) && (bondOrderSum == type.bondOrderSum); 

getAtomTypeName () एक स्ट्रिंग लौटाता है, और bonOrderSum टाइप डबल का होता है। आवेदन तर्क पूरी तरह से मानता है कि यहां अलग-अलग होंगे, लेकिन समान वस्तुओं में बराबर और तुलना गलत तरीके से काम करेगी।

जब तक आपके पास उनका उपयोग करने का एक अच्छा कारण न हो, तब तक इंटेगर, डबल और इसी तरह का उपयोग करना अवांछनीय है।

5. प्रोग्रामर यह भूल गया कि लाइनें स्थिर हैं

स्ट्रिंग क्लास के तरीकों के लिए कॉल हैं जो एक नया स्ट्रिंग बनाते हैं। उदाहरण के लिए (net.sf.cdk.tools.MakeJavafilesFiles.readBlackList):

 while (line != null) { line.trim(); if (line.length() > 0) blacklist.add(line); line = reader.readLine(); } 

कॉलिंग लाइन। ट्रिम () बेकार है, क्योंकि यह लाइन को स्वयं लाइन नहीं बदलता है, और कोई भी परिणाम का उपयोग नहीं करता है। लेखक के मन में स्पष्ट रूप से लाइन = line.trim () थी। इसी तरह, String.substring कॉल परिणाम को सहेजे बिना सामना किया जाता है।

6. विभिन्न प्रकार की वस्तुओं की तुलना

if( atom.equals("H") ) की भावना में अक्सर तुलना होती है, जहां परमाणु टाइप IAom है। जाहिर है, if( atom.getSymbol().equals("H") ) निहित है। सामान्य तौर पर, यह एक रहस्यमय जगह है, क्योंकि इस तरह की एक दर्जन से अधिक त्रुटियां हैं, और, मेरी राय में, उन्हें शब्दार्थ को दृढ़ता से प्रभावित करना चाहिए और परिणाम को विकृत करना चाहिए।

7. एक असिंचित क्षेत्र का उपयोग करना

org.openscience.cdk.dict.EntryReact:

 public void setReactionMetadata(String metadata) { this.reactionInfo.add( metadata ); } 

फाइंडबग्स यह निर्धारित करता है कि निजी प्रतिक्रियाइन्फो फ़ील्ड को किसी अन्य विधि में प्रारंभ नहीं किया गया है, इसलिए यह विधि हमेशा NullPointerException को फेंक देगी।

8. एक स्थिर क्षेत्र की गलत शुरुआत

उदाहरण के लिए, वर्ग org.openscience.cdk.qsar.AtomValenceTool:

 public class AtomValenceTool { private static Map<String,Integer> valencesTable = null; public static int getValence(IAtom atom) { if (valencesTable == null) { valencesTable = new HashMap<String, Integer>(); valencesTable.put("H", 1); valencesTable.put("He", 8); valencesTable.put("Ne", 8); ... } return valencesTable.get(atom.getSymbol()); } } 

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

9. अनुबंधों का उल्लंघन

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

10. नियमित अभिव्यक्ति का गलत उपयोग

net.sf.cdk.tools.doclets.CDKIOOptionsTaglet.getClassName:

 String path = file.getPath().replaceAll(File.separator, "."); 

रिप्लेसमेंट विधि एक तर्क के रूप में एक नियमित अभिव्यक्ति लेती है। विंडोज के तहत, File.separator एक बैकस्लैश है जिसे विशेष रूप से नियमित अभिव्यक्तियों में व्याख्या किया गया है, इसलिए यह कोड PatternSyntaxException के साथ क्रैश हो जाएगा।

11. पैरेंट कंस्ट्रक्टर की एक ओवरराइड विधि, एक uninitialized चर का उपयोग करती है

कक्षा में एक दिलचस्प स्थिति। org.openscience.cdk.debug.DebugAtomContainer। एक क्षेत्र घोषित है

 ILoggingTool logger = LoggingToolFactory.createLoggingTool(DebugAtomContainer.class); 

और एक विधि है:

 public void addStereoElement(IStereoElement parity) { logger.debug("Adding stereo element: ", parity); super.addStereoElement(parity); } 

समस्या यह है कि इस विधि को बेस क्लास के कंस्ट्रक्टरों में से एक में कहा जाता है जब लॉगर वैरिएबल के लिए कोई मान असाइन नहीं किया गया है। नतीजतन, ज़ाहिर है, एक NullPointerException उत्पन्न होगी।

निष्कर्ष

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