Java के लिए PVS-Studio को पथ पर भेजा जाता है। अगला पड़ाव है एलीटेसर्च

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

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

एलीटसर्च के साथ सतही परिचित

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

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

मुझे लगता है कि परिचित के साथ पर्याप्त है।

कैसा था

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

• 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); } .... }); .... } 

इस कोड के टुकड़े में त्रुटि यह है कि यदि आप बफर से लाइन नहीं पढ़ सकते हैं, तो इस कथन की स्थिति में स्टार्ट विधि के साथ कॉल करने पर 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 ऑब्जेक्ट को riveted किया है। प्रारंभ विधि हमारे संदेह सहित कई इनपुट तर्क लेती है। फिर, नल के लिए हमारी वस्तु की जांच के आधार पर, एक नई वस्तु बनती है, जो विधि के आगे तर्क में भाग लेती है। नल के लिए जाँच हमें बताता है कि 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 । नियम कहता है: “दोस्तों, तुम क्या कर रहे हो? ऐसा कैसे? अरे मुसीबत! आप पहले ऑब्जेक्ट का उपयोग क्यों करते हैं, और फिर कोड की अगली पंक्ति में इसे शून्य के लिए जांचें! " तो यह यहाँ एक अशक्त वस्तु dereferencing निकलता है। काश, यहां तक ​​कि डेवलपर्स में से एक की टिप्पणी ने भी मदद नहीं की।

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; } 

हमने इस पद्धति को लागू किया, फिर इसे कॉपी किया और हमारी गलत खोज को खोजने के लिए कुछ छोटे सुधार किए। विधि समायोजित, समायोजित की गई, लेकिन समायोजित नहीं हुई। स्थिति को मापने के लिए, आपको इसके बजाय && ऑपरेटर का उपयोग करना होगा || ।

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 के साथ शेष चर की समानता पर एक तुलना व्यर्थ है और हमेशा एक गलत परिणाम देगा, और इसलिए हालत लूप से बाहर नहीं निकलेगी। क्या यह कोड हटाने योग्य है, या क्या आपको व्यवहार के तर्क पर पुनर्विचार करने की आवश्यकता है? मुझे लगता है कि केवल डेवलपर्स मैं सभी को डॉट कर पाएंगे।

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 डायग्नोस्टिक्स को ट्रिगर किया गया था , जिसे अलग से माना जाना चाहिए और निष्कर्ष निकाला जाना चाहिए।

विधि छोटी है, लेकिन udalenky

 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 }; 

जब चर x char64 विधि के इनपुट में प्रवेश करता है, तो यह सूचकांक की वैधता की जांच करता है। अंतर कहां है? सरणी से बाहर जाने का मामला अभी भी क्यों संभव है?

जाँच (int) x> index_64.length पूरी तरह से सही नहीं है। यदि x का मान 128 के साथ char64 विधि के इनपुट पर आता है , तो चेक 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())) // <= && ....) } 

और फिर से वस्तुओं की गलत तुलना। अब उन वस्तुओं की तुलना करें जिनके प्रकार असंगत ( पूर्णांक और टाइमवैल्यू ) हैं। इस तुलना का परिणाम स्पष्ट है, और यह हमेशा गलत है। यह देखा जा सकता है कि वर्ग के खेतों की तुलना एक दूसरे से उसी तरह की जाती है, यह केवल खेतों के नाम बदलने के लिए आवश्यक है। इसलिए, डेवलपर ने कॉपी-पेस्ट के साथ कोड लिखने की प्रक्रिया को तेज करने का फैसला किया, लेकिन उसने खुद को उसी बग से सम्मानित किया। क्लास स्क्रॉलसाइज़ फ़ील्ड के लिए एक गेटर लागू करता है, इसलिए त्रुटि को ठीक करने के लिए, सही समाधान उपयुक्त विधि का उपयोग करना होगा: डेटाफ़ीड .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 () एक स्ट्रिंग देता है जिसमें वर्ण '' 'पहले से'? '' होता है। ऐसे मामले के लिए, विधि में कोई जांच नहीं होती है, और यदि यह अभी भी होता है, तो आपदा से बचा नहीं जाएगा। शायद विधि के बाहर अनुरोध ऑब्जेक्ट के विभिन्न चेक के कारण ऐसा कभी नहीं होगा, लेकिन मेरी राय में, इसके लिए उम्मीद करना सबसे अच्छा विचार नहीं है।

निष्कर्ष

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

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

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