हुआवेई क्लाउड: आज पीवीएस-स्टूडियो में बादल छाए हुए हैं

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

परिचय

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

• पीवीएस-स्टूडियो बादलों में जाता है: एज़्योर देवोपीएस
• पीवीएस-स्टूडियो बादलों में जाता है: ट्रैविस सीआई
• पीवीएस-स्टूडियो बादलों में जाता है: सर्किलसीआई
• पीवीएस-स्टूडियो बादलों में जाता है: गिटलैब सीआई / सीडी

और इसलिए, जब मैं आगामी लेख के लिए एक और दिलचस्प परियोजना उठा रहा था, तो मुझे मेल में Huawei से नौकरी का प्रस्ताव मिला। इस कंपनी के बारे में जानकारी एकत्र करते समय, यह पता चला कि उनकी अपनी क्लाउड सेवाएँ हैं, लेकिन मुख्य बात यह है कि इन सेवाओं का स्रोत कोड GitHub पर स्वतंत्र रूप से उपलब्ध है। यह इस लेख के लिए इस कंपनी को चुनने का मुख्य कारण था। जैसा कि एक चीनी ऋषि ने कहा: "दुर्घटनाएं आकस्मिक नहीं हैं।"

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

• पीवीएस-स्टूडियो विश्लेषण का एकीकरण सोनारक्यूब में हुआ
• जेनकींस में पीवीएस-स्टूडियो लॉन्च करें

परियोजना विश्लेषण

लेख के लिए जानकारी खोजने की प्रक्रिया में, मुझे पता चला कि हुआवेई का एक डेवलपर केंद्र है जहां आप उनकी क्लाउड सेवाओं के लिए जानकारी, गाइड और स्रोत कोड प्राप्त कर सकते हैं। इन सेवाओं को बनाने के लिए विभिन्न प्रकार की प्रोग्रामिंग भाषाओं का उपयोग किया गया था, लेकिन गो, जावा और पायथन जैसी भाषाएँ सबसे लोकप्रिय रहीं।

चूंकि मैं जावा में विशेषज्ञ हूं, इसलिए परियोजनाओं को उसी के अनुसार चुना गया था। लेख में विश्लेषण की गई परियोजनाओं के स्रोत GitHub रिपॉजिटरी huaweicloud में प्राप्त किए जा सकते हैं।

परियोजनाओं का विश्लेषण करने के लिए, मुझे केवल कुछ क्रियाएं करने की आवश्यकता थी:

• भंडार से परियोजनाएं प्राप्त करें;
• जावा विश्लेषक शुरू करने के लिए निर्देशों का उपयोग करें और प्रत्येक परियोजनाओं पर विश्लेषण शुरू करें।

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

परियोजना विश्लेषण परिणाम (चेतावनियों की संख्या और फाइलों की संख्या):

• हुवाइक्लाउड-एसडीके-जावा : 31 - उच्च, 2 - मध्यम और 16 - निम्न, 2700+ फाइलें।
• हुवाइक्लाउड-डिस-एजेंट : 7 - हाई, 6 - मीडियम और 6 - लो, 100+ फाइल्स।
• हुवाइक्लाउड-एसडीके-जावा-डिस : 15 - हाई, 6 - मीडियम और 16 - लो, 270+ फाइल्स।

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

परियोजनाओं के विश्लेषण की प्रक्रिया में, मैंने सबसे दिलचस्प चेतावनियों का चयन किया, जिसकी चर्चा मैं इस लेख में करूँगा।

फील्ड इनिशियलाइज़ेशन ऑर्डर

V6050 वर्ग आरंभीकरण चक्र मौजूद है। 'लॉग' के आरंभीकरण से पहले 'INSTANCE' का प्रारंभ दिखाई देता है। अनट्रस्टेडएसएसएल.जावा (32), अनट्रस्टेडएसएसएल.जावा (59), अनट्रिस्वर्डएसएसएल.जावा (33)

public class UntrustedSSL { private static final UntrustedSSL INSTANCE = new UntrustedSSL(); private static final Logger LOG = LoggerFactory.getLogger(UntrustedSSL.class); .... private UntrustedSSL() { try { .... } catch (Throwable t) { LOG.error(t.getMessage(), t); // <= } } } 

यदि कोई भी अपवाद अनट्रस्टेडएसएसएल वर्ग के निर्माता में होता है, तो इस अपवाद के बारे में जानकारी लॉग लॉगर का उपयोग करके कैच ब्लॉक में लॉग की जाती है । हालाँकि, स्थैतिक फ़ील्ड्स के आरंभीकरण क्रम के कारण, INSTANCE फ़ील्ड को आरम्भ करने के समय लॉग अभी तक आरंभीकृत नहीं हुआ है। इसलिए, जब निर्माणकर्ता में अपवाद जानकारी लॉग करते हैं, तो एक NullPointerException को फेंक दिया जाएगा। यह अपवाद किसी अन्य अपवाद का कारण है। InInitializerError अपवाद है जिसे यदि स्थैतिक फ़ील्ड को प्रारंभ करते समय कोई अपवाद हुआ, तो उसे फेंक दिया जाता है। वर्णित समस्या को हल करने के लिए आवश्यक सभी को INSTANCE आरंभीकरण से पहले लॉग इनिशियलाइज़ेशन रखना है।

अदृश्य टाइपो

V6005 चर 'this.metricSchema' खुद को सौंपा गया है। OpenTSDBSchema.java (72)

 public class OpenTSDBSchema { @JsonProperty("metric") private List<SchemaField> metricSchema; .... public void setMetricsSchema(List<SchemaField> metricsSchema) { this.metricSchema = metricSchema; // <= } public void setMetricSchema(List<SchemaField> metricSchema) { this.metricSchema = metricSchema; } .... } 

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

V6005 चर 'सस्पेंड' खुद को सौंपा गया है। SuspendTransferTaskRequest.java (77)

 public class SuspendTransferTaskRequest { .... private boolean suspend; .... public void setSuspend(boolean suspend) { suspend = suspend; } .... } 

यहां लापरवाही से संबंधित एक प्रतिबंधात्मक त्रुटि है, जिसके कारण तर्क का असाइनमेंट खुद को निलंबित करता है। नतीजतन, आर्ग्युमेंट फ़ील्ड का मान, सस्पेंड फ़ील्ड को नहीं सौंपा जाएगा, जैसा कि निहित है। सही:

 public void setSuspend(boolean suspend) { this.suspend = suspend; } 

पूर्व निर्धारित स्थिति

जैसा कि अक्सर होता है, V6007 नियम चेतावनी की संख्या के मामले में आगे टूट जाता है।

V6007 अभिव्यक्ति 'फ़ायरवॉलपॉलिशियड == नल' हमेशा गलत होता है। फ़ायरवॉलपॉलीस्कूल सेवाइम्प्ल.जावा (125)

 public FirewallPolicy removeFirewallRuleFromPolicy(String firewallPolicyId, String firewallRuleId) { checkNotNull(firewallPolicyId); checkNotNull(firewallRuleId); checkState(!(firewallPolicyId == null && firewallRuleId == null), "Either a Firewall Policy or Firewall Rule identifier must be set"); .... } 

इस विधि में, checkNotNull विधि द्वारा अशक्त के लिए तर्कों की जाँच की जाती है:

 @CanIgnoreReturnValue public static <T> T checkNotNull(T reference) { if (reference == null) { throw new NullPointerException(); } else { return reference; } } 

CheckNotNull विधि के साथ तर्क की जाँच करने के बाद, आप 100% सुनिश्चित हो सकते हैं कि इस पद्धति के लिए दिया गया तर्क शून्य नहीं है। चूंकि RemoveFirewallRuleFromPolicy विधि के दोनों तर्कों को CheckNotNull विधि द्वारा जांचा जाता है, इसलिए यह शून्य मानों के लिए तर्कों की जांच करने का कोई मतलब नहीं है। हालाँकि, पहली दलील के रूप में एक अभिव्यक्ति चेकस्टैट विधि को पास की जाती है, जहाँ तर्क फ़ायरवॉलपॉलिसिअस और फायरवालरुलेइड को फिर से जाँच के लिए शून्य कर दिया जाता है ।

फायरवॉल के लिए इसी तरह की चेतावनी जारी की जाती है।

• V6007 अभिव्यक्ति 'फ़ायरवॉलRuleId == नल' हमेशा गलत है। फ़ायरवॉलपॉलीस्कूल सेवाइम्प्ल.जावा (125)

V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। NetworkPolicyServiceImpl.java (60)

 private Invocation<NetworkServicePolicies> buildInvocation(Map<String, String> filteringParams) { .... if (filteringParams == null) { return servicePoliciesInvocation; } if (filteringParams != null) { // <= .... } return servicePoliciesInvocation; } 

इस विधि में, यदि तर्क फ़िल्टरिंगपार्ट्स शून्य है , तो विधि बाहर निकलती है और मान लौटाती है। इसलिए, विश्लेषक द्वारा इंगित किया गया परीक्षण हमेशा सच होगा, जिसका अर्थ है कि इस परीक्षण का कोई मतलब नहीं है।

13 वर्गों में ऐसा ही होता है:

• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। PolicyRuleServiceImpl.java (58)
• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। GroupServiceImpl.java (58)
• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। एक्सटर्नलशिप सेवाइम्प्ल.जावा (57)
• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। L3policyServiceImpl.java (57)
• V6007 अभिव्यक्ति 'फ़िल्टरिंगपाम! = नल' हमेशा सच होता है। PolicyRuleSetServiceImpl.java (58)
• और इसी तरह ...

अशक्त संदर्भ

V6008 'm.blockDeviceMapping' के संभावित अशक्त। नोवासेवरक्रिएट.जावा (390)

 @Override public ServerCreateBuilder blockDevice(BlockDeviceMappingCreate blockDevice) { if (blockDevice != null && m.blockDeviceMapping == null) { m.blockDeviceMapping = Lists.newArrayList(); } m.blockDeviceMapping.add(blockDevice); // <= return this; } 

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

V6008 फ़ंक्शन '<init>' में 'FileId.get (पथ)' की संभावित अशक्तता । TrackedFile.java (140), TrackedFile.java (115)

 public TrackedFile(FileFlow<?> flow, Path path) throws IOException { this(flow, path, FileId.get(path), ....); } 

स्थिर विधि FileId.get (पथ) का परिणाम तीसरे तर्क के रूप में TrackedFile वर्ग के निर्माता को दिया जाता है। लेकिन यह विधि शून्य हो सकती है :

 public static FileId get(Path file) throws IOException { if (!Files.exists(file)) { return null; } .... } 

इसके माध्यम से बुलाए गए कंस्ट्रक्टर में, आईडी का तर्क तब तक नहीं बदलता है जब तक कि इसका पहली बार उपयोग न किया जाए:

 public TrackedFile(...., ...., FileId id, ....) throws IOException { .... FileId newId = FileId.get(path); if (!id.equals(newId)) { .... } } 

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

इसी तरह की स्थिति दूसरे मामले में होती है:

• V6008 'बफर' की संभावित अशक्तता। PublishingQueue.java (518)

V6008 'डेटाटेम्पाइल' के संभावित अशक्तता। कैचेमनगर.जावा (91)

 @Override public void putToCache(PutRecordsRequest putRecordsRequest) { .... if (dataTmpFile == null || !dataTmpFile.exists()) { try { dataTmpFile.createNewFile(); // <= } catch (IOException e) { LOGGER.error("Failed to create cache tmp file, return.", e); return ; } } .... } 

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

 if (dataTmpFile != null && !dataTmpFile.exists()) 

सबस्ट्रिंग और नकारात्मक संख्या

V6009 ' प्रतिस्थापन ' फ़ंक्शन '-1' मान प्राप्त कर सकता है जबकि गैर-नकारात्मक मान अपेक्षित है। तर्क का निरीक्षण करें: 2. RemoveVersionProjectIdFromURL.java (37)

 @Override public String apply(String url) { String urlRmovePojectId = url.substring(0, url.lastIndexOf("/")); return urlRmovePojectId.substring(0, urlRmovePojectId.lastIndexOf("/")); } 

यह समझा जाता है कि URL को स्ट्रिंग के रूप में इस विधि में पारित किया गया है, जो किसी भी तरह से मान्य नहीं है। अंतिम स्ट्रिंग के बाद कई बार इस स्ट्रिंग को ट्रिम किया जाता है। अगर lastIndexOf को स्ट्रिंग में मेल नहीं मिलता है, तो यह -1 वापस आ जाएगी। यह एक StringIndexOutOfBoundsException फेंक देगा , क्योंकि प्रतिस्थापन विधि के तर्क गैर-नकारात्मक संख्या होना चाहिए। सही तरीके से काम करने की विधि के लिए, आपको इनपुट तर्क का सत्यापन जोड़ना होगा या सत्यापित करना होगा कि lastIndexOf विधियों के परिणाम नकारात्मक संख्या नहीं हैं।

यहाँ कुछ अन्य स्थान हैं जहाँ ऐसा होता है:

• V6009 'प्रतिस्थापन' फ़ंक्शन '-1' मान प्राप्त कर सकता है जबकि गैर-नकारात्मक मान अपेक्षित है। निरीक्षण तर्क: 2. RemoveProjectIdFromURL.java (37)
• V6009 'प्रतिस्थापन' फ़ंक्शन '-1' मान प्राप्त कर सकता है जबकि गैर-नकारात्मक मान अपेक्षित है। तर्क का निरीक्षण करें: 2. RemoveVersionProjectIdFromURL.java (38)

भूल गए परिणाम

V6010 फ़ंक्शन ' कॉनकैट ' के रिटर्न मान का उपयोग करने की आवश्यकता है। AKSK.java (278)

 public static String buildCanonicalHost(URL url) { String host = url.getHost(); int port = url.getPort(); if (port > -1) { host.concat(":" + Integer.toString(port)); } return host; } 

इस कोड को लिखते समय, यह ध्यान में नहीं रखा गया था कि कंक्रीटिंग विधि को कॉल करने से स्ट्रिंग के प्रकार की वस्तुओं की अपरिवर्तनीयता के कारण होस्ट स्ट्रिंग नहीं बदलेगी। सही तरीके से काम करने की विधि के लिए, आपको अगर ब्लॉक में होस्ट चर को कॉनकैट विधि का परिणाम निर्दिष्ट करना होगा। सही:

 if (port > -1) { host = host.concat(":" + Integer.toString(port)); } 

अप्रयुक्त चर

V6021 चर 'url' का उपयोग नहीं किया गया है। TriggerV2Service.java (95)

 public ActionResponse deleteAllTriggersForFunction(String functionUrn) { checkArgument(!Strings.isNullOrEmpty(functionUrn), ....); String url = ClientConstants.FGS_TRIGGERS_V2 + ClientConstants.URI_SEP + functionUrn; return deleteWithResponse(uri(triggersUrlFmt, functionUrn)).execute(); } 

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

कंस्ट्रक्टर में इस्तेमाल नहीं किया गया तर्क

V6022 पैरामीटर 'returnType' का उपयोग कंस्ट्रक्टर बॉडी के अंदर नहीं किया जाता है। HttpRequest.java (68)

 public class HttpReQuest<R> { .... Class<R> returnType; .... public HttpRequest(...., Class<R> returnType) // <= { this.endpoint = endpoint; this.path = path; this.method = method; this.entity = entity; } .... public Class<R> getReturnType() { return returnType; } .... } 

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

एक ही कार्यक्षमता

V6032 यह अजीब है कि विधि 'सक्षम' का शरीर पूरी तरह से किसी अन्य विधि 'अक्षम' के शरीर के बराबर है। ServiceAction.java (32), ServiceAction.java (36)

 public class ServiceAction implements ModelEntity { private String binary; private String host; private ServiceAction(String binary, String host) { this.binary = binary; this.host = host; } public static ServiceAction enable(String binary, String host) { // <= return new ServiceAction(binary, host); } public static ServiceAction disable(String binary, String host) { // <= return new ServiceAction(binary, host); } .... } 

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

मुख्य बात की जांच करना भूल गए

V6060 नल के खिलाफ सत्यापित होने से पहले ' परम ' संदर्भ का उपयोग किया गया था। DomainService.java (49), DomainService.java (46)

 public Domains list(Map<String, String> params) { Preconditions.checkNotNull(params.get("page_size"), ....); Preconditions.checkNotNull(params.get("page_number"), ....); Invocation<Domains> domainInvocation = get(Domains.class, uri("/domains")); if (params != null) { // <= .... } return domainInvocation.execute(this.buildExecutionOptions(Domains.class)); } 

इस पद्धति में, हमने अशक्त असमानता के लिए मैप के एक प्रकार की संरचना की सामग्री की जांच करने का निर्णय लिया। ऐसा करने के लिए, params तर्क दो बार विधि प्राप्त करता है , जिसके परिणाम को checkNotNull विधि में पास किया जाता है। सब कुछ तर्कसंगत लगता है, लेकिन कोई फर्क नहीं पड़ता! अगर , null के लिए params तर्क की जाँच की जाती है। जिसके बाद यह माना जा सकता है कि इनपुट तर्क शून्य हो सकता है, लेकिन इस जांच से पहले, गेट विधि को दो बार पहले से ही पाराम्स कहा जाता था। यदि नल को इस पद्धति के तर्क के रूप में पारित किया जाता है, तो पहली बार प्राप्त विधि को बुलाया जाता है, एक अपवाद फेंक दिया जाएगा।

इसी तरह की स्थिति तीन और स्थानों पर होती है:

• V6060 नल के खिलाफ सत्यापित होने से पहले 'परम' संदर्भ का उपयोग किया गया था। DomainService.java (389), DomainService.java (387)
• V6060 नल के खिलाफ सत्यापित होने से पहले 'परम' संदर्भ का उपयोग किया गया था। DomainService.java (372), DomainService.java (369)
• V6060 नल के खिलाफ सत्यापित होने से पहले 'परम' संदर्भ का उपयोग किया गया था। DomainService.java (353), DomainService.java (350)

निष्कर्ष

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

PVS-Studio निश्चित रूप से Huawei को अपनी क्लाउड सेवाओं की जाँच के परिणामों के बारे में सूचित करेगा ताकि इस कंपनी के डेवलपर्स उन्हें और अधिक विस्तार से अध्ययन कर सकें।

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

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