जावा के लिए पीवीएस-स्टूडियो सड़क को हिट करता है। अगला पड़ाव है एलीटेसर्च

PVS- स्टूडियो टीम कई वर्षों से एक ही नाम वाले स्थिर कोड विश्लेषक द्वारा ओपन-सोर्स प्रोजेक्ट्स के चेक के बारे में ब्लॉग को रख रही है। आज तक, 300 से अधिक परियोजनाओं की जाँच की गई है, त्रुटियों के आधार में 12000 से अधिक मामले हैं। प्रारंभ में C और C ++ कोड की जाँच के लिए विश्लेषक को लागू किया गया था, बाद में C # का समर्थन जोड़ा गया था। इसलिए, सभी चेक किए गए प्रोजेक्ट्स में C और C ++ के बहुमत (> 80%) खाते हैं। हाल ही में जावा को समर्थित भाषाओं की सूची में जोड़ा गया था, जिसका अर्थ है कि पीवीएस-स्टूडियो के लिए अब एक पूरी नई खुली दुनिया है, इसलिए यह जावा परियोजनाओं से त्रुटियों के साथ आधार को पूरक करने का समय है।

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

संक्षेप में इलास्टिक्सर्च के बारे में

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

एलास्टिक्सखोज का उपयोग करने वाले प्रमुख स्थलों में विकिमीडिया, स्टम्बलअप, क्वोरा, फोरस्क्वेयर, साउंडक्लाउड, गिटहब, नेटफ्लिक्स, अमेज़ॅन, आईबीएम, क्यूबॉक्स हैं।

ठीक है, पर्याप्त परिचय।

चीजें कैसी थीं, इसकी पूरी कहानी

चेक से ही कोई समस्या नहीं थी। क्रियाओं का क्रम सरल है और इसमें अधिक समय नहीं लगा है:

• GitHub से डाउनलोड की गई इलास्टिक्स खोज;
• जावा विश्लेषक को चलाने के लिए निर्देशों का पालन ​​किया और विश्लेषण चलाया;
• विश्लेषक की रिपोर्ट को प्राप्त किया, इसमें विलंब किया और दिलचस्प मामलों को इंगित किया।

अब मुख्य बिंदु पर चलते हैं।

बाहर देखो! संभव NullPointerException

V6008 'लाइन ’का अशांतिकरण । GoogleCloudStorageFixture.java (451)

private static PathTrie<RequestHandler> defaultHandlers(....) { .... handlers.insert("POST /batch/storage/v1", (request) -> { .... // Reads the body line = reader.readLine(); byte[] batchedBody = new byte[0]; if ((line != null) || (line.startsWith("--" + boundary) == false)) // <= { batchedBody = line.getBytes(StandardCharsets.UTF_8); } .... }); .... } 

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

V6008 ' अनुवर्ती IndexexMetadata ' की संभावित अशक्तता । TransportResumeFollowAction.java (171), TransportResumeFollowAction.java (170), TransportResumeFollowAction.java (194)

 void start( ResumeFollowAction.Request request, String clusterNameAlias, IndexMetaData leaderIndexMetadata, IndexMetaData followIndexMetadata, ....) throws IOException { MapperService mapperService = followIndexMetadata != null // <= ? .... : null; validate(request, leaderIndexMetadata, followIndexMetadata, // <= leaderIndexHistoryUUIDs, mapperService); .... } 

V6008 नैदानिक ​​से एक और चेतावनी। ऑब्जेक्ट followIndexMetadata ने मेरी रुचि को बढ़ा दिया । प्रारंभ विधि इनपुट के रूप में कई तर्कों को स्वीकार करती है, हमारा संदेह उनके बीच सही है। उसके बाद, नल के लिए हमारी वस्तु की जांच के आधार पर , एक नई वस्तु बनाई जाती है, जो आगे विधि तर्क में शामिल होती है। अशक्त के लिए जाँच करें हमें पता चलता है कि followIndexMetadata अभी भी एक अशक्त वस्तु के रूप में बाहर से आ सकता है। खैर, आगे देखते हैं।

फिर कई तर्कों को वैध विधि पर धकेल दिया जाता है (फिर से, हमारे बीच उन पर विचार किया जाता है)। यदि हम सत्यापन विधि के कार्यान्वयन को देखते हैं, तो यह सभी जगह गिर जाता है। हमारी संभावित अशक्त वस्तु को तीसरे तर्क के रूप में मान्य विधि से पारित किया जाता है, जहां यह बिना शर्त के निष्क्रिय हो जाता है। परिणामस्वरूप संभावित NullPointerException ।

 static void validate( final ResumeFollowAction.Request request, final IndexMetaData leaderIndex, final IndexMetaData followIndex, // <= ....) { .... Map<String, String> ccrIndexMetadata = followIndex.getCustomData(....); // <= if (ccrIndexMetadata == null) { throw new IllegalArgumentException(....); } .... }} 

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

N60 के विरुद्ध सत्यापित होने से पहले V6060 'नोड' संदर्भ का उपयोग किया गया था। RestTasksAction.java (152), RestTasksAction.java (151)

 private void buildRow(Table table, boolean fullId, boolean detailed, DiscoveryNodes discoveryNodes, TaskInfo taskInfo) { .... DiscoveryNode node = discoveryNodes.get(nodeId); .... // Node information. Note that the node may be null because it has // left the cluster between when we got this response and now. table.addCell(fullId ? nodeId : Strings.substring(nodeId, 0, 4)); table.addCell(node == null ? "-" : node.getHostAddress()); table.addCell(node.getAddress().address().getPort()); table.addCell(node == null ? "-" : node.getName()); table.addCell(node == null ? "-" : node.getVersion().toString()); .... } 

इसी समस्या के साथ एक और नैदानिक ​​नियम यहां शुरू हुआ। NullPointerException । नियम डेवलपर्स के लिए रोता है: "दोस्तों, आप क्या कर रहे हैं? आप ऐसा कैसे कर सकते हैं? ओह, यह भयानक है! आप पहली बार ऑब्जेक्ट का उपयोग क्यों करते हैं और अगली पंक्ति में नल के लिए जाँच करते हैं? यहाँ बताया गया है कि अशक्त वस्तु कैसे होती है। काश, यहां तक ​​कि एक डेवलपर की टिप्पणी से भी मदद नहीं मिली।

N60 के विरुद्ध सत्यापित होने से पहले V6060 'कारण' संदर्भ का उपयोग किया गया था। StartupException.java (76), StartupException.java (73)

 private void printStackTrace(Consumer<String> consumer) { Throwable originalCause = getCause(); Throwable cause = originalCause; if (cause instanceof CreationException) { cause = getFirstGuiceCause((CreationException)cause); } String message = cause.toString(); // <= consumer.accept(message); if (cause != null) { // <= // walk to the root cause while (cause.getCause() != null) { cause = cause.getCause(); } .... } .... } 

इस मामले में हमें इस बात का ध्यान रखना चाहिए कि थ्रॉलेबल क्लास का गेटकॉज मेथड अशक्त हो सकता है। उपरोक्त समस्या आगे दोहराई जाती है, इसलिए इसकी व्याख्या अनावश्यक है।

अर्थहीन स्थिति

V6007 अभिव्यक्ति 's.charAt (i)! =' \ T '' हमेशा सत्य होता है। क्रोन.जावा (1223)

 private static int findNextWhiteSpace(int i, String s) { for (; i < s.length() && (s.charAt(i) != ' ' || s.charAt(i) != '\t'); i++) { // intentionally empty } return i; } 

माना गया फ़ंक्शन i इंडेक्स से शुरू होकर पहले स्पेस कैरेक्टर के इंडेक्स को लौटाता है। क्या गलत है? हमारे पास विश्लेषक चेतावनी है कि s.charAt (i)! = '\ T' हमेशा सत्य होता है, जिसका अर्थ है अभिव्यक्ति (s.charAt (i)! = '' '|| s.charAt (i)! =' \ _ T !! ') हमेशा की तरह सच भी होगा। क्या यह सच है? मुझे लगता है, आप किसी भी चरित्र को प्रतिस्थापित करके आसानी से यह सुनिश्चित कर सकते हैं।

परिणामस्वरूप, यह विधि हमेशा s.length () के बराबर सूचकांक को लौटाएगी , जो गलत है। मैं यह सुझाव देने के लिए उद्यम करूंगा कि उपरोक्त विधि यहां दोष देने के लिए है:

 private static int skipWhiteSpace(int i, String s) { for (; i < s.length() && (s.charAt(i) == ' ' || s.charAt(i) == '\t'); i++) { // intentionally empty } return i; } 

डेवलपर्स ने इस पद्धति को लागू किया, फिर कॉपी किया और हमारी गलत विधि को ढूंढा गया NNNWWiteSpace, कुछ संपादन किए। वे विधि को ठीक करते रहे और ठीक करते रहे लेकिन इसे ठीक नहीं किया। यह अधिकार प्राप्त करने के लिए, एक के बजाय && ऑपरेटर का उपयोग करना चाहिए || ।

V6007 अभिव्यक्ति 'शेष == 0' हमेशा झूठी होती है। पेमुलेट्स.जावा (439)

 private static byte[] generateOpenSslKey(char[] password, byte[] salt, int keyLength) { .... int copied = 0; int remaining; while (copied < keyLength) { remaining = keyLength - copied; .... copied += bytesToCopy; if (remaining == 0) { // <= break; } .... } .... } 

कॉपी किए गए <keyLength लूप की स्थिति से हम ध्यान दे सकते हैं कि कॉपी हमेशा KeyLength से कम होगी । इसलिए, शेष चर की तुलना 0 के साथ करना व्यर्थ है, और यह हमेशा गलत होगा, जिस बिंदु पर लूप एक शर्त से बाहर नहीं निकलेगा। कोड निकालें या व्यवहार तर्क पर पुनर्विचार करें? मुझे लगता है, केवल डेवलपर्स ही सभी डॉट्स को i के ऊपर रख पाएंगे।

V6007 अभिव्यक्ति 'HealthCheckDn.indexOf (' = ')> 0' हमेशा गलत है। ActiveDirectorySessionFactory.java (73)

 ActiveDirectorySessionFactory(RealmConfig config, SSLService sslService, ThreadPool threadPool) throws LDAPException { super(...., () -> { if (....) { final String healthCheckDn = ....; if (healthCheckDn.isEmpty() && healthCheckDn.indexOf('=') > 0) { return healthCheckDn; } } return ....; }, ....); .... } 

व्यर्थ की अभिव्यक्ति फिर से। स्थिति के अनुसार, HealthCheckDn स्ट्रिंग को दोनों खाली होना चाहिए और पहले ही स्थिति में '=' ​​अक्षर नहीं होना चाहिए, ताकि लैम्ब्डा अभिव्यक्ति स्ट्रिंग चर healthCheckDn को वापस कर दे । काहे, यह तो सब है! जैसा कि आप शायद समझ गए हैं, यह असंभव है। हम कोड में गहरे नहीं जा रहे हैं, इसे डेवलपर्स के विवेक पर छोड़ दें।

मैंने केवल कुछ गलत उदाहरणों का हवाला दिया, लेकिन इससे परे V6007 नैदानिक ​​ट्रिगर बहुत था, जिसे प्रासंगिक निष्कर्ष बनाते हुए एक-एक करके विचार किया जाना चाहिए।

छोटी विधि एक लंबा रास्ता तय कर सकती है

 private static byte char64(char x) { if ((int)x < 0 || (int)x > index_64.length) return -1; return index_64[(int)x]; } 

तो यहाँ हमारे पास कई पंक्तियों की एक नन्हा-नन्ही विधि है। लेकिन कीड़े घड़ी पर हैं! इस पद्धति के विश्लेषण ने निम्नलिखित परिणाम दिए:

1. V6007 अभिव्यक्ति '(int) x <0' हमेशा गलत है। BCrypt.java (429)
2. V6025 संभवतः सूचकांक '(int) x' सीमा से बाहर है। BCrypt.java (431)

अंक N १। एक्सप्रेशन (int) x <0 हमेशा गलत होता है (हाँ, V6007 फिर से)। X चर नकारात्मक नहीं हो सकता है, क्योंकि यह चार प्रकार का है। चार प्रकार एक अहस्ताक्षरित पूर्णांक है। इसे वास्तविक त्रुटि नहीं कहा जा सकता है, लेकिन फिर भी, चेक बेमानी है और इसे हटाया जा सकता है।

अंक N2 सीमाओं से बाहर संभव सरणी सूचकांक, जिसके परिणामस्वरूप ArrayIndexOutOfBoundsException अपवाद है । फिर यह प्रश्न को जन्म देता है, जो सतह पर है: "प्रतीक्षा करें, सूचकांक जांच के बारे में कैसे?"

इसलिए, हमारे पास 128 तत्वों का एक निश्चित आकार का सरणी है:

 private static final byte index_64[] = { -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, 0, 1, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, -1, -1, -1, -1, -1, -1, -1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, -1, -1, -1, -1, -1, -1, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, -1, -1, -1, -1, -1 }; 

जब चर 64 विधि x चर प्राप्त करती है, तो सूचकांक वैधता की जाँच हो जाती है। दोष कहाँ है? क्यों सरणी सूचकांक सीमा से बाहर अभी भी संभव है?

चेक (int) x> index_64.length काफी सही नहीं है। यदि char64 विधि मान मान के साथ x प्राप्त करता है, तो चेक ArrayIndexOutOfBoundsException के विरुद्ध सुरक्षा नहीं करेगा। शायद हकीकत में ऐसा कभी नहीं होता। हालाँकि, चेक को गलत तरीके से लिखा गया है, और किसी को "ऑपरेटर" (>) से "अधिक" या (> =) के बराबर या उससे अधिक बदलना होगा।

तुलना, जिन्होंने अपना सर्वश्रेष्ठ प्रदर्शन किया

V6013 नंबर 'डिस्प्लेसाइज़' और 'that.displaySize' की तुलना संदर्भ से की जाती है। संभवतः एक समानता तुलना का इरादा था। ColumnInfo.java (122)

 .... private final String table; private final String name; private final String esType; private final Integer displaySize; .... @Override public boolean equals(Object o) { if (this == o) { return true; } if (o == null || getClass() != o.getClass()) { return false; } ColumnInfo that = (ColumnInfo) o; return displaySize == that.displaySize && // <= Objects.equals(table, that.table) && Objects.equals(name, that.name) && Objects.equals(esType, that.esType); } 

यहां जो गलत है वह यह है कि इंटेगर टाइप की डिस्प्ले ऑब्जेक्ट्स की तुलना == ऑपरेटर के संदर्भ में की जाती है। यह बहुत संभव है कि ColumnInfo ऑब्जेक्ट्स, जिनके डिस्प्ले फ़ील्ड्स के अलग-अलग संदर्भ हैं, लेकिन एक ही सामग्री, की तुलना की जाएगी। इस मामले में, तुलना हमें नकारात्मक परिणाम देगी, जब हम सच होने की उम्मीद करेंगे।

मैं यह अनुमान लगाने के लिए उद्यम करूंगा कि इस तरह की तुलना एक असफल रीफैक्टरिंग का नतीजा हो सकती है और शुरू में डिस्प्लेसाइज़ फ़ील्ड इंट प्रकार का था।

V6058 'बराबर' फ़ंक्शन असंगत प्रकार की वस्तुओं की तुलना करता है: इंटेगर, टाइमवैल्यू। डेटाफीडअपडेट। जावा (375)

 .... private final TimeValue queryDelay; private final TimeValue frequency; .... private final Integer scrollSize; .... boolean isNoop(DatafeedConfig datafeed) { return (frequency == null || Objects.equals(frequency, datafeed.getFrequency())) && (queryDelay == null || Objects.equals(queryDelay, datafeed.getQueryDelay())) && (scrollSize == null || Objects.equals(scrollSize, datafeed.getQueryDelay())) // <= && ....) } 

गलत वस्तुएं फिर से तुलना करती हैं। इस बार असंगत प्रकारों वाली वस्तुओं की तुलना की जाती है ( Integer and TimeValue )। इस तुलना का परिणाम स्पष्ट है, और यह हमेशा गलत है। आप देख सकते हैं कि वर्ग के खेतों की एक-दूसरे के साथ तुलना की जाती है, केवल खेतों के नाम बदलने पड़ते हैं। यहां बिंदु है - एक डेवलपर ने कॉपी-पेस्ट का उपयोग करके प्रक्रिया को गति देने का फैसला किया और सौदेबाजी में एक बग मिला। क्लास स्क्रॉलस्लाइज़ फ़ील्ड के लिए एक गेटर लागू करता है, इसलिए त्रुटि को ठीक करने के लिए किसी को डेटाफ़ीड विधि का उपयोग करना चाहिए .getScrollSize ()।

आइए बिना किसी स्पष्टीकरण के गलत उदाहरणों के एक जोड़े को देखें। समस्याएं काफी स्पष्ट हैं।

V6001 बायीं और '==' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ 'takeInMillis' हैं। टर्मवेक्टर्सप्रिंस.जावा (152)

 @Override public boolean equals(Object obj) { .... return index.equals(other.index) && type.equals(other.type) && Objects.equals(id, other.id) && docVersion == other.docVersion && found == other.found && tookInMillis == tookInMillis // <= && Objects.equals(termVectorList, other.termVectorList); } 

V6009 फ़ंक्शन 'बराबर' एक विषम तर्क प्राप्त करता है। एक ऑब्जेक्ट 'shardId.getIndexName ()' का उपयोग अपनी स्वयं की पद्धति के तर्क के रूप में किया जाता है। स्नैपशॉटशेयरफेल.जवा (208)

 @Override public boolean equals(Object o) { .... return shardId.id() == that.shardId.id() && shardId.getIndexName().equals(shardId.getIndexName()) && // <= Objects.equals(reason, that.reason) && Objects.equals(nodeId, that.nodeId) && status.getStatus() == that.status.getStatus(); } 

विविध

V6006 ऑब्जेक्ट बनाया गया था, लेकिन इसका उपयोग नहीं किया जा रहा है। 'थ्रो' कीवर्ड गायब हो सकता है। JdbcConnection.java (88)

 @Override public void setAutoCommit(boolean autoCommit) throws SQLException { checkOpen(); if (!autoCommit) { new SQLFeatureNotSupportedException(....); } } 

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

V6003 'if (A) {....} का उपयोग if (A) {....}' पैटर्न का पता चला। तार्किक त्रुटि उपस्थिति की संभावना है। MockScriptEngine.java (94), MockScriptEngine.java (105)

 @Override public <T> T compile(....) { .... if (context.instanceClazz.equals(FieldScript.class)) { .... } else if (context.instanceClazz.equals(FieldScript.class)) { .... } else if(context.instanceClazz.equals(TermsSetQueryScript.class)) { .... } else if (context.instanceClazz.equals(NumberSortScript.class)) .... } 

एकाधिक में यदि- और किसी एक स्थिति को दो बार दोहराया जाता है, तो स्थिति को सक्षम कोड समीक्षा की आवश्यकता होती है।

V6039 समान सशर्त अभिव्यक्तियों के साथ दो 'यदि' कथन हैं। पहले 'if' स्टेटमेंट में मेथड रिटर्न होता है। इसका मतलब यह है कि दूसरा 'अगर' कथन संवेदनहीन है। SearchAfterBuilder.java (94), SearchAfterBuilder.java (93)

 public SearchAfterBuilder setSortValues(Object[] values) { .... for (int i = 0; i < values.length; i++) { if (values[i] == null) continue; if (values[i] instanceof String) continue; if (values[i] instanceof Text) continue; if (values[i] instanceof Long) continue; if (values[i] instanceof Integer) continue; if (values[i] instanceof Short) continue; if (values[i] instanceof Byte) continue; if (values[i] instanceof Double) continue; if (values[i] instanceof Float) continue; if (values[i] instanceof Boolean) continue; // <= if (values[i] instanceof Boolean) continue; // <= throw new IllegalArgumentException(....); } .... } 

एक ही स्थिति का उपयोग पंक्ति में दो बार किया जाता है। क्या बूलियन के बजाय दूसरी स्थिति का उपयोग करना अधिक कठिन है या किसी अन्य प्रकार का उपयोग किया जाना चाहिए?

V6009 फ़ंक्शन 'सबस्ट्रिंग' एक विषम तर्क प्राप्त करता है। 'QueryStringIndex + 1' तर्क 'queryStringLength' से अधिक नहीं होना चाहिए। लॉगिंगऑडिटट्रिल.जावा (660)

 LogEntryBuilder withRestUriAndMethod(RestRequest request) { final int queryStringIndex = request.uri().indexOf('?'); int queryStringLength = request.uri().indexOf('#'); if (queryStringLength < 0) { queryStringLength = request.uri().length(); } if (queryStringIndex < 0) { logEntry.with(....); } else { logEntry.with(....); } if (queryStringIndex > -1) { logEntry.with(...., request.uri().substring(queryStringIndex + 1,// <= queryStringLength)); // <= } .... } 

आइए यहां पर गलत परिदृश्य पर विचार करें जिससे अपवाद StringIndexOutOfBoundsException हो सकता है। अपवाद तब होगा जब request.uri () एक स्ट्रिंग देता है जिसमें वर्ण '#' से पहले '?' होता है। विधि में कोई जांच नहीं होती है, इसलिए यदि ऐसा होता है, तो परेशानी बढ़ जाती है। शायद, विधि के बाहर वस्तु की विभिन्न जांचों के कारण ऐसा कभी नहीं होगा, लेकिन इस पर आशाएं स्थापित करना सबसे अच्छा विचार नहीं है।

निष्कर्ष

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

जावा के लिए पीवीएस-स्टूडियो को नई दुनिया के लिए जल्दी से अनुकूलित करने के लिए नई चुनौतियों, नए उपयोगकर्ताओं, सक्रिय प्रतिक्रिया और ग्राहकों की आवश्यकता है :)। इसलिए मैं आपको तुरंत अपने कार्य प्रोजेक्ट पर हमारे विश्लेषक को डाउनलोड करने और प्रयास करने के लिए आमंत्रित करता हूं!