IntelliJ IDEA स्टेटिक एनालाइज़र के साथ CDK प्रोजेक्ट का सत्यापन

मैंने IntelliJ IDEA स्थिर जावा कोड विश्लेषक का परीक्षण करने का निर्णय लिया और इसके साथ, द केमिस्ट्री डेवलपमेंट किट प्रोजेक्ट का परीक्षण किया। यहां मैं कुछ त्रुटियां दूंगा जो मुझे मिलीं। मुझे लगता है कि उनमें से कुछ समग्र रूप से जावा कार्यक्रमों के लिए विशिष्ट हैं, इसलिए वे दिलचस्प हो सकते हैं।

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

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

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

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

मैं आपको केवल कुछ दिलचस्प चेतावनियों के बारे में बताऊंगा।

1. यूनरी प्लस

परियोजना में पहले से ही 66 संयुक्त प्लस थे। केवल 1 बजाय +1 लिखने के लिए कभी-कभी मैं सुंदर होना चाहता हूं। हालाँकि, कुछ मामलों में, यूनरी प्लस += बजाय बाहर आता है, तो += लिखा =+ :

 int totalCharge1 = 0; while (atoms1.hasNext()) { totalCharge1 = +((IAtom) atoms1.next()).getFormalCharge(); } Iterator<IAtom> atoms2 = products.atoms().iterator(); int totalCharge2 = 0; while (atoms2.hasNext()) { totalCharge2 = +((IAtom) atoms2.next()).getFormalCharge(); } 

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

2. पूर्णांक विभाजन के कारण अग्रणी

एक बल्कि कष्टप्रद गलती, लेकिन स्थैतिक विश्लेषक इसे अच्छी तरह से पाते हैं। यहाँ एक उदाहरण है :

 angle = 1 / 180 * Math.PI; 

दुर्भाग्य से, कोण एक डिग्री नहीं, बल्कि शून्य हो गया। इसी तरह की त्रुटि :

 Integer c1 = features1.get(key); Integer c2 = features2.get(key); c1 = c1 == null ? 0 : c1; c2 = c2 == null ? 0 : c2; sum += 1.0 - Math.abs(c1 - c2) / (c1 + c2); // integer division in floating-point context 

ऐसा लगता है कि दोनों संख्याएँ c1 और c2 गैर-ऋणात्मक हैं, जिसका अर्थ है कि अंतर मापांक कभी भी योग से अधिक नहीं होगा। इसलिए, परिणाम 0 होगा यदि दोनों संख्याएँ नॉनज़रो हैं, या 1 यदि उनमें से कोई एक 0 है।

3. कॉल Class.getClass ()

कभी-कभी लोग टाइप Class ऑब्जेक्ट पर getClass() विधि कहते हैं। परिणाम फिर से Class का एक ऑब्जेक्ट है जिसमें निरंतर मान Class.class । यह आमतौर पर एक गलती है: getClass() बुलाया नहीं जाना चाहिए। उदाहरण के लिए, यहां :

 public <T extends ICDKObject> T ofClass(Class<T> intf, Object... objects) { try { if (!intf.isInterface()) throw new IllegalArgumentException("expected interface, got " + intf.getClass()); ... 

यदि कोई अपवाद होता है, तो रिपोर्ट करना पूरी तरह से बेकार हो जाएगा। वैसे, त्रुटि हैंडलिंग प्रक्रिया में त्रुटियां अक्सर पुरानी परियोजनाओं में स्थिर विश्लेषण द्वारा पाई जाती हैं: एक नियम के रूप में, त्रुटि हैंडलिंग प्रक्रियाओं का सबसे खराब परीक्षण किया जाता है।

एक सरणी पर 4.String () को कॉल करें

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

 int[] dim = {0, 0, 0}; ... return "Dim:" + dim + " SizeX:" + grid.length + " SizeY:" + grid[0].length + " SizeZ:"... 

अपनी आँखों से समस्या को नोटिस करना मुश्किल है, क्योंकि यहाँ dim.toString() निहित है, लेकिन स्ट्रिंग dim.toString() है। एक फिक्स तुरंत सुझाव दिया गया है - Arrays.toString(dim) में लपेटो।

5. संग्रह पढ़ा है, लेकिन भरा नहीं है

यह भी, अक्सर एक कोड बेस में पाया जाता है जो स्थिर विश्लेषक द्वारा निरंतर परीक्षण से नहीं गुजरता है। यहाँ एक सरल उदाहरण है :

 final Set<IBond> bondsToHydrogens = new HashSet<IBond>(); // ... 220  ,  bondsToHydrogens   ! for (IBond bondToHydrogen : bondsToHydrogens) //     sgroup.removeBond(bondToHydrogen); 

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

6. इसके विपरीत: हम भरते हैं, लेकिन पढ़ते नहीं हैं

उल्टे मामले भी संभव हैं। यहाँ एक सरणी के साथ एक उदाहरण है :

 int[] tmp = new int[trueBits.length - 1]; System.arraycopy(trueBits, 0, tmp, 0, i); System.arraycopy(trueBits, i + 1, tmp, i, trueBits.length - i - 1); 

निरीक्षण से पता चलता है कि अरैस्कोपी पद्धति का तीसरा तर्क केवल सरणी लिखने के लिए उपयोग किया जाता है, और उसके बाद सरणी का उपयोग बिल्कुल नहीं किया जाता है। कोड के तर्क से देखते हुए, लाइन trueBits = tmp; छोड़ दिया गया है trueBits = tmp; ।

7. == द्वारा पूर्णांक की तुलना

यह एक कपटी बग है, क्योंकि इंटीगर ऑब्जेक्ट्स के छोटे मूल्य कैश किए जाते हैं, और एक दिन की संख्या 127 से अधिक होने तक सब कुछ अच्छी तरह से काम कर सकता है। ऐसी समस्या बिल्कुल स्पष्ट नहीं हो सकती है :

 for (int a = 0; a < cliqueSize; a++) { for (int b = 0; b < vecSize; b += 3) { if (cliqueList.get(a) == compGraphNodes.get(b + 2)) { cliqueMapping.add(compGraphNodes.get(b)); cliqueMapping.add(compGraphNodes.get(b + 1)); } } } 

खैर, ऐसा लगता है कि कुछ सूचियों में कुछ वस्तुओं की तुलना की जाती है, शायद सब कुछ ठीक है। यह देखने के लिए सावधान रहना चाहिए कि इन सूचियों में प्रकार की वस्तुएं हैं।

8. मानचित्र में डुप्लिकेट

इस निरीक्षण में, एक तस्वीर एक हजार शब्दों के लायक है। गलती देखिए ?

9. विधि के परिणाम का उपयोग नहीं किया जाता है।

कुछ तरीकों का परिणाम मूर्खतापूर्ण नहीं है, जो आईडीईए आसानी से रिपोर्ट करता है :

 currentChars.trim(); 

शायद, इसका मतलब था currentChars = currentChars.trim(); । चूंकि जावा में तार अपरिवर्तनीय हैं, यदि परिणाम फिर से नहीं दिया गया है, तो कुछ भी नहीं होगा। यह भी पाया जाता है, उदाहरण के लिए , str.substring(2) ।

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

10. पहुंच से बाहर स्विच शाखाओं

 // if character is out of scope don't if (c > 128) return 0; switch (c) { case '\u002d': // hyphen case '\u2012': // figure dash case '\u2013': // en-dash case '\u2014': // em-dash case '\u2212': // minus return '-'; // 002d default: return c; } 

चूंकि हमने वर्णों को 128 से अधिक कोड के साथ बाहर रखा है, इसलिए शाखाएँ \u2012-\u2212 पहुंच \u2012-\u2212 बाहर हैं। ऐसा लगता है कि यह बाहर करने के लायक नहीं था।

11. अप्राप्य दशा

स्थितियों की श्रृंखला में एक बिल्कुल अद्भुत समस्या:

 if (oxNum == 0) { if (hybrid.equals("sp3")) { ... } else if (hybrid.equals("sp2")) return 47; } else if (oxNum == 1 && hybrid.equals("sp3")) return 47; else if ((oxNum == 2 && hybrid.equals("sp3")) || (oxNum == 1 && hybrid.equals("sp2")) || (oxNum == 0 && hybrid.equals("sp"))) //     return 48; else if ((oxNum == 3 && hybrid.equals("sp3")) || (oxNum >= 2 && hybrid.equals("sp2")) || (oxNum >= 1 && hybrid.equals("sp"))) return 49; 

जटिल सशर्त तर्क में, यह असामान्य नहीं है: हम एक ऐसी स्थिति की जांच करते हैं जो सच नहीं हो सकती, क्योंकि इसका टुकड़ा पहले ही ऊपर जांचा जा चुका है। यहां हमारे पास एक अलग शाखा oxNum == 0 , अन्यथा हम oxNum == 0 && hybrid.equals("sp") , जो निश्चित रूप से नहीं हो सकता है।

12. हम शून्य लंबाई की एक सरणी के लिए लिखते हैं

कभी-कभी IntelliJ IDEA नोटिस करेगा यदि आप इसके आकार के बाहर किसी सरणी में लिखते हैं:

 Point3d points[] = new Point3d[0]; //    0  if (nwanted == 1) { points = new Point3d[1]; points[0] = new Point3d(aPoint); points[0].add(new Vector3d(length, 0.0, 0.0)); } else if (nwanted == 2) { //       —   points[0] = new Point3d(aPoint); points[0].add(new Vector3d(length, 0.0, 0.0)); points[1] = new Point3d(aPoint); points[1].add(new Vector3d(-length, 0.0, 0.0)); } 

13. इंडेक्स तक पहुंचने के बाद लंबाई की जाँच करना

प्रक्रिया के साथ एक और आम समस्या और फिर त्रुटि से निपटने के दौरान :

 public void setParameters(Object[] params) throws CDKException { if (params.length > 1) { throw new CDKException("..."); } if (!(params[0] instanceof Integer)) { //     throw new CDKException("The parameter must be of type Integer"); } if (params.length == 0) return; //      maxIterations = (Integer) params[0]; } 

एक खाली सरणी के मामले में, कोड का लेखक चुपचाप बाहर निकलना चाहता था, लेकिन सत्यापन के कारण, यह बाहर निकल जाएगा, जोर से बैठा हुआ ArrayIndexOutOfBoundsException। जाहिर है, चेक का ऑर्डर आउट ऑफ ऑर्डर है।

14. पहुँच के बाद अशक्त के लिए जाँच करें

और फिर, कार्यों के क्रम का उल्लंघन किया जाता है, इस बार अशक्त के साथ :

 while (!line.startsWith("frame:") && input.ready() && line != null) { line = input.readLine(); logger.debug(lineNumber++ + ": ", line); } 

IDEA उस line != null लिखती है line != null हमेशा सच होता है। ऐसा होता है कि चेक वास्तव में बेमानी है, लेकिन यहां कोड ऐसा दिखता है जैसे कि नल वास्तव में हो सकता है।

15. सम्मिश्रण के बजाय अव्यवस्था

लोग अक्सर तार्किक ऑपरेटरों और OR को भ्रमित करते हैं। CDK प्रोजेक्ट कोई अपवाद नहीं है :

 if (rStereo != 4 || pStereo != 4 || rStereo != 3 || pStereo != 3) { ... } 

जो भी rStereo और pStereo बराबर हैं, यह स्पष्ट है कि वे एक ही समय में चार और तीन के बराबर नहीं हो सकते हैं, इसलिए यह स्थिति हमेशा सही होती है।

16. संयोजन के बजाय फिर से अव्यवस्था

एक समान त्रुटि , लेकिन दूसरे संदेश द्वारा पकड़ा गया:

 if (getFirstMapping() != null || !getFirstMapping().isEmpty()) { ... } 

हम केवल तभी दाईं ओर पहुंच सकते हैं जब getFirstMapping() वापस लौट आए, लेकिन इस मामले में हमें NullPointerException की गारंटी दी जाती है, जिसके बारे में IDEA चेतावनी देता है। वैसे, यहां हम getFirstMapping() विधि के परिणामों की स्थिरता पर भरोसा करते हैं। कभी-कभी हम उत्तराधिकार का उपयोग करते हैं, लेकिन यहां स्थिरता का सीधे विश्लेषण किया जाता है। चूंकि वर्ग अंतिम है, इसलिए विधि को ओवरराइड नहीं किया जा सकता है। return firstSolution.isEmpty() ? null : firstSolution IDEA अपने बॉडी return firstSolution.isEmpty() ? null : firstSolution return firstSolution.isEmpty() ? null : firstSolution और यह निर्धारित करता है कि स्थिरता Map#isEmpty विधि की स्थिरता के लिए नीचे आती है, जिसे पहले स्थिर रूप में एनोटेट किया गया है।

17. इंटरफेस और इन्स्टॉफ़ की पदानुक्रम

किसी भी इंटरफ़ेस से संबंधित ऑब्जेक्ट की जांच करते समय, यह मत भूलो कि इंटरफेस एक दूसरे से विरासत में मिल सकते हैं:

 if (object instanceof IAtomContainer) { root = convertor.cdkAtomContainerToCMLMolecule((IAtomContainer) object); } else if (object instanceof ICrystal) { root = convertor.cdkCrystalToCMLMolecule((ICrystal) object); } ... 

ICrystal इंटरफ़ेस ICrystal इंटरफ़ेस का विस्तार करता है, इसलिए दूसरी शाखा स्पष्ट रूप से अप्राप्य है: यदि कोई क्रिस्टल यहाँ आता है, तो यह पहली शाखा में आएगा।

18. एक खाली सूची का पता लगाना

इस कोड के लेखक शायद जावा भाषा से बहुत परिचित नहीं हैं:

 List<Integer> posNumList = new ArrayList<Integer>(size); for (int i = 0; i < posNumList.size(); i++) { posNumList.add(i, 0); } 

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

19. खेतों को आरम्भ करना मत भूलना

विश्लेषक एक विशेष तरीके से फ़ील्ड इनिशियलाइज़र्स को ध्यान में रखते हुए, कंस्ट्रक्टरों की जाँच करता है। इसके लिए धन्यवाद, ऐसी त्रुटि पाई गई:

 public class IMatrix { public double[][] realmatrix; public double[][] imagmatrix; public int rows; public int columns; public IMatrix(Matrix m) { rows = m.rows; columns = m.columns; int i, j; for (i = 0; i < rows; i++) for (j = 0; j < columns; j++) { realmatrix[i][j] = m.matrix[i][j]; // NullPointerException  imagmatrix[i][j] = 0d; } } } 

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

20. दो बार दोहराएं नहीं

बार-बार स्थितियां भी होती हैं। यहाँ एक उदाहरण है :

 if (commonAtomCount > vfMCSSize && commonAtomCount > vfMCSSize) { return true; } 

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

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