खेल 0 ईस्वी के लेखक - अच्छी तरह से किए गए

0 AD वास्तविक समय में ऐतिहासिक रणनीति की शैली में एक त्रि-आयामी खेल है, जिसे स्वयंसेवकों के समुदाय द्वारा विकसित किया गया है। कोड आधार का आकार छोटा है और मैंने एंड्रॉइड और XNU कर्नेल जैसी बड़ी परियोजनाओं से ब्रेक के रूप में खेल की जांच करने का फैसला किया। इसलिए, हमारे सामने C ++ में कोड की 165,000 लाइनें हैं। आइए देखें कि पीवीएस-स्टूडियो स्थिर विश्लेषक का उपयोग करके इसमें क्या दिलचस्प है, पाया जा सकता है।

0 ई

0 AD (0 A.D.) वास्तविक समय में ऐतिहासिक रणनीति की शैली में एक नि: शुल्क त्रि-आयामी खेल है, जिसे स्वयंसेवकों के एक समुदाय द्वारा विकसित किया गया है (मुख्य डेवलपर्स वाइल्डफेयर गेम्स टीम में एकजुट हैं)। खेल आपको 500 ईसा पूर्व की अवधि में मौजूद सभ्यताओं को नियंत्रित करने की अनुमति देता है। ई। - 1 वर्ष ई.पू. ई। 2018 की गर्मियों तक, परियोजना अल्फा संस्करण में है। [ विवरण विकिपीडिया से लिया गया है]।

क्यों वास्तव में 0 ईस्वी?

मैंने Egor Bredikhin ( EgorBredikhin ) के एक सहयोगी को मेरे लिए कुछ छोटे खुले प्रोजेक्ट चुनने और जांचने के लिए कहा, जिनके साथ मैं अन्य कार्यों के बीच काम कर सकता था। उन्होंने मुझे 0 विज्ञापन परियोजना के लिए एक लॉग भेजा। प्रश्न: "यह परियोजना क्यों?" - एक उत्तर था: "हां, मैंने अभी यह खेल खेला है, एक अच्छी रीयल-टाइम रणनीति।" ठीक है, तो यह 0 ईस्वी :) होगा।

घनत्व में त्रुटि

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

कुछ संख्या। कोड की गैर-खाली लाइनों की कुल संख्या 231270 है। इनमें से, 28.7% टिप्पणियां हैं। कुल में, शुद्ध C ++ कोड की 165,000 लाइनें।

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

इसलिए, मुझे कोड की 165,000 लाइनों पर 19 त्रुटियां मिलीं। हम त्रुटि घनत्व की गणना करते हैं: 19 * 1000/165000 = 0.115।

सादगी के लिए, हम राउंड ऑफ करते हैं और मानते हैं कि पीवीएस-स्टूडियो विश्लेषक गेम कोड में प्रति 1000 लाइनों की 0.1 त्रुटियों का पता लगाता है।

महान परिणाम! तुलना के लिए, एंड्रॉइड के बारे में मेरे हाल के लेख में, मैंने गणना की कि मुझे कोड की प्रति 1000 लाइनों में कम से कम 0.25 त्रुटियां मिलीं। वास्तव में, त्रुटियों का घनत्व और भी अधिक है, मुझे पूरी रिपोर्ट का सावधानीपूर्वक विश्लेषण करने की शक्ति नहीं मिली।

या उदाहरण के रूप में EFL कोर लाइब्रेरीज़ को लें, जिसका मैंने ध्यान से अध्ययन किया और दोषों की संख्या की गणना की। इसमें, पीवीएस-स्टूडियो कोड की प्रति 1000 लाइनों में 0.71 त्रुटियों का पता लगाता है।

इसलिए, 0 ईस्वी के लेखक अच्छे फैलो हैं, हालांकि, निष्पक्षता के लिए, यह ध्यान दिया जाना चाहिए कि C ++ में लिखा गया एक छोटा कोड उनकी मदद करता है। दुर्भाग्य से, बड़ी परियोजना, तेजी से इसकी जटिलता बढ़ती है, और त्रुटि घनत्व गैर-रैखिक ( अधिक ) बढ़ जाती है।

त्रुटियों

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

नोट। हम पीवीएस-स्टूडियो को बी 2 बी समाधान के रूप में रखते हैं। छोटी परियोजनाओं और व्यक्तिगत डेवलपर्स के लिए, हमारे पास एक मुफ्त लाइसेंस विकल्प है: " पीवीएस-स्टूडियो का उपयोग कैसे करें "।

त्रुटि N १

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

void WaterManager::CreateWaveMeshes() { .... int nbNeighb = 0; .... bool found = false; nbNeighb = 0; for (int p = 0; p < 8; ++p) { if (CoastalPointsSet.count(xx+around[p][0] + (yy + around[p][1])*SideSize)) { if (nbNeighb >= 2) { CoastalPointsSet.erase(xx + yy*SideSize); continue; } ++nbNeighb; // We've found a new point around us. // Move there xx = xx + around[p][0]; yy = yy + around[p][1]; indexx = xx + yy*SideSize; if (i == 0) Chain.push_back(CoastalPoint(indexx,CVector2D(xx*2,yy*2))); else Chain.push_front(CoastalPoint(indexx,CVector2D(xx*2,yy*2))); CoastalPointsSet.erase(xx + yy*SideSize); found = true; break; } } if (!found) endedChain = true; .... } 

PVS-Studio चेतावनी : V547 CWE-570 एक्सप्रेशन 'nbNeighb> = 2' हमेशा गलत होता है। वाटरमैनगर .सीपीसी 581

पहली नज़र में, विश्लेषक संदेश अजीब लगता है। क्यों हालत nbNeighb> = 2 हमेशा झूठी है? दरअसल, लूप के शरीर में चर nbNeighb की वृद्धि होती है !

नीचे देखें और आप एक ब्रेक स्टेटमेंट देखेंगे जो लूप के निष्पादन को बाधित करता है। इसलिए, यदि चर nbNeighb बढ़ा है, तो चक्र बंद कर दिया जाएगा। इस प्रकार, चर nbNeighb का मान 1 से अधिक मूल्य तक कभी नहीं पहुंचेगा।

कोड में स्पष्ट रूप से किसी प्रकार की तार्किक त्रुटि है।

त्रुटि N2

 void CmpRallyPointRenderer::MergeVisibilitySegments( std::deque<SVisibilitySegment>& segments) { .... segments.erase(segments.end()); .... } 

PVS-Studio चेतावनी: V783 CWE-119 अवैध itter 'सेगमेंट की Dereferencing' () () हो सकता है। CCmpRallyPointRenderer.cpp 1290

बहुत, बहुत अजीब कोड। शायद प्रोग्रामर कंटेनर से अंतिम तत्व को निकालना चाहता था। इस स्थिति में, कोड इस तरह होना चाहिए:

 segments.erase(segments.end() - 1); 

हालाँकि, तब यह लिखना आसान होगा:

 segments.pop_back(); 

ईमानदार होने के लिए, यह मेरे लिए पूरी तरह से स्पष्ट नहीं है कि यहाँ क्या लिखा जाना चाहिए था।

त्रुटि N3, N4

मैंने दो त्रुटियों पर एक साथ विचार करने का फैसला किया, क्योंकि वे संसाधन रिसाव से संबंधित हैं और पहले यह दिखाने की आवश्यकता है कि WARN_RETURL मैक्रो क्या है ।

 #define WARN_RETURN(status)\ do\ {\ DEBUG_WARN_ERR(status);\ return status;\ }\ while(0) 

तो, जैसा कि आप देख सकते हैं, WARN_RETURN मैक्रो फ़ंक्शन को शरीर से बाहर निकलने का कारण बनता है। अब इस मैक्रो का उपयोग करने के गलत तरीकों को देखें।

पहला टुकड़ा।

 Status sys_generate_random_bytes(u8* buf, size_t count) { FILE* f = fopen("/dev/urandom", "rb"); if (!f) WARN_RETURN(ERR::FAIL); while (count) { size_t numread = fread(buf, 1, count, f); if (numread == 0) WARN_RETURN(ERR::FAIL); buf += numread; count -= numread; } fclose(f); return INFO::OK; } 

PVS-Studio चेतावनी: V773 CWE-401 समारोह 'f' हैंडल जारी किए बिना बाहर किया गया था। एक संसाधन रिसाव संभव है। unix.cpp 332

यदि फ़्रेड फ़ंक्शन डेटा को नहीं पढ़ सकता है, तो sys_generate_random_bytes फ़ंक्शन फ़ाइल डिस्क्रिप्टर को रिलीज़ किए बिना बाहर निकल जाएगा। व्यवहार में, यह शायद ही संभव है। यह संदेहास्पद है कि आप "/ देव / यूरेनियम" से डेटा नहीं पढ़ पाएंगे। हालाँकि, कोड मैला है।

दूसरा टुकड़ा।

 Status sys_cursor_create(....) { .... sys_cursor_impl* impl = new sys_cursor_impl; impl->image = image; impl->cursor = XcursorImageLoadCursor(wminfo.info.x11.display, image); if(impl->cursor == None) WARN_RETURN(ERR::FAIL); *cursor = static_cast<sys_cursor>(impl); return INFO::OK; } 

PVS-Studio चेतावनी: V773 CWE-401 समारोह 'निहित' सूचक जारी किए बिना बाहर किया गया था। एक स्मृति रिसाव संभव है। x.cpp 421

यदि कर्सर लोड करने में विफल रहता है, तो मेमोरी रिसाव होता है।

त्रुटि N5

 Status LoadHeightmapImageOs(....) { .... shared_ptr<u8> fileData = shared_ptr<u8>(new u8[fileSize]); .... } 

PVS-Studio चेतावनी: V554 CWE-762 साझा_प्र का गलत उपयोग। 'नई []' के साथ आवंटित की गई मेमोरी को 'डिलीट' का उपयोग करके साफ किया जाएगा। MapIO.cpp 54

सही विकल्प:

 shared_ptr<u8[]> fileData = shared_ptr<u8>(new u8[fileSize]); 

त्रुटि N6

 FUTrackedPtr(ObjectClass* _ptr = NULL) : ptr(_ptr) { if (ptr != NULL) FUTracker::TrackObject((FUTrackable*) ptr); ptr = ptr; } 

PVS-Studio चेतावनी: V570 'ptr' चर अपने आप को सौंपा गया है। FUTracker.h 122

त्रुटि N7, N8

 std::wstring TraceEntry::EncodeAsText() const { const wchar_t action = (wchar_t)m_action; wchar_t buf[1000]; swprintf_s(buf, ARRAY_SIZE(buf), L"%#010f: %c \"%ls\" %lu\n", m_timestamp, action, m_pathname.string().c_str(), (unsigned long)m_size); return buf; } 

PVS-Studio चेतावनी: V576 CWE-628 गलत प्रारूप। 'Swprintf_s' फ़ंक्शन के पांचवें वास्तविक तर्क की जाँच करने पर विचार करें। चार प्रकार का तर्क अपेक्षित है। ट्रेसकैप 93

यहाँ हम विज़ुअल सी ++ में स्वैर्फ़ फ़ंक्शन के वैकल्पिक कार्यान्वयन के भ्रमित और अविवेकी इतिहास के बारे में जानते हैं । मैं इसे रिटेल नहीं करूंगा, लेकिन V576 डायग्नोस्टिक्स के लिए प्रलेखन देखें (अनुभाग "वाइड लाइन्स" देखें)।

इस स्थिति में, सबसे अधिक संभावना है, यह कोड विंडोज के लिए विजुअल सी ++ में संकलन करते समय और लिनक्स या मैकओएस के लिए गलत तरीके से काम करते समय सही ढंग से काम करेगा।

इसी तरह की त्रुटि: V576 CWE-628 गलत प्रारूप। 'Swprintf_s' फ़ंक्शन के चौथे वास्तविक तर्क की जाँच करने पर विचार करें। चार प्रकार का तर्क अपेक्षित है। vfs_tree.cpp 211

त्रुटि N9, N10, N11

क्लासिक । शुरुआत में, सूचक का उपयोग किया जाता है, और उसके बाद ही जाँच की जाती है।

 static void TEST_CAT2(char* dst, ....) { strcpy(dst, dst_val); // <= int ret = strcat_s(dst, max_dst_chars, src); TS_ASSERT_EQUALS(ret, expected_ret); if(dst != 0) // <= TS_ASSERT(!strcmp(dst, expected_dst)); } 

PVS-Studio चेतावनी: V595 CWE-476 'dst' पॉइंटर का उपयोग करने से पहले इसे nullptr के खिलाफ सत्यापित किया गया था। जाँच रेखाएँ: 140, 143. test_secure_crt.h 140

मुझे लगता है कि त्रुटि के स्पष्टीकरण की आवश्यकता नहीं है। इसी तरह की चेतावनी:

• V595 CWE-476 'dst' पॉइंटर को nullptr के खिलाफ सत्यापित होने से पहले उपयोग किया गया था। जाँच रेखाएँ: 150, 153. test_secure_crt.h 150
• V595 CWE-476 'dst' पॉइंटर को nullptr के खिलाफ सत्यापित होने से पहले उपयोग किया गया था। जाँच रेखाएँ: 314, 317. test_secure_crt.h 314

त्रुटि N12

 typedef int tbool; void MikkTSpace::setTSpace(...., const tbool bIsOrientationPreserving, ....) { .... m_NewVertices.push_back(bIsOrientationPreserving > 0.5 ? 1.0f : (-1.0f)); .... } 

V674 CWE-682 'डबल' प्रकार के '0.5' शाब्दिक की तुलना 'int' प्रकार के मान से की जाती है। 'BIsOrientationPreserves> 0.5' अभिव्यक्ति का निरीक्षण करने पर विचार करें। मिककट्सस्पेसवक्रॉप। 137

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

त्रुटि N13

 virtual Status ReplaceFile(const VfsPath& pathname, const shared_ptr<u8>& fileContents, size_t size) { ScopedLock s; VfsDirectory* directory; VfsFile* file; Status st; st = vfs_Lookup(pathname, &m_rootDirectory, directory, &file, VFS_LOOKUP_ADD|VFS_LOOKUP_CREATE); // There is no such file, create it. if (st == ERR::VFS_FILE_NOT_FOUND) { s.~ScopedLock(); return CreateFile(pathname, fileContents, size); } .... } 

PVS-Studio चेतावनी: V749 CWE-675 's' ऑब्जेक्ट का विनाशकर्ता दूसरी बार ऑब्जेक्ट के स्कोप को छोड़ने के बाद मंगाया जाएगा। vfs.cpp 165

फ़ाइल बनाने से पहले, यह आवश्यक है कि एक वस्तु ScopedLock "ऑब्जेक्ट" अनलॉक करें। इसके लिए, एक विध्वंसक को स्पष्ट रूप से कहा जाता है। मुसीबत यह है कि फ़ंक्शन के बाहर निकलने पर s ऑब्जेक्ट के लिए विध्वंसक स्वचालित रूप से फिर से कॉल किया जाएगा। यानी विध्वंसक दो बार कहा जाएगा। मैंने स्कोपेलॉक वर्ग के उपकरण का अध्ययन नहीं किया है, लेकिन किसी भी मामले में, आपको ऐसा नहीं करना चाहिए। अक्सर, विध्वंसक को ऐसी दोहरी कॉल अपरिभाषित व्यवहार या अन्य अप्रिय त्रुटियों की ओर ले जाती है। यहां तक ​​कि अगर कोड अब ठीक काम कर रहा है, तो स्कोप्लॉक वर्ग के कार्यान्वयन को बदलकर सब कुछ तोड़ना बहुत आसान है।

N14, N15, N16, N17 त्रुटि

 CFsmEvent* CFsm::AddEvent( unsigned int eventType ) { .... pEvent = new CFsmEvent( eventType ); if ( !pEvent ) return NULL; .... } 

PVS- स्टूडियो चेतावनी: V668 CWE-570 'न्यू' ऑपरेटर के उपयोग से स्मृति आवंटित किए जाने के कारण, अशक्त के खिलाफ 'pEvent' पॉइंटर के परीक्षण में कोई समझदारी नहीं है। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। fsm.cpp 259

पॉइंटर को चेक करने का कोई मतलब नहीं है, क्योंकि मेमोरी आवंटन त्रुटि के मामले में, एक अपवाद std :: bad_alloc फेंका जाएगा।

तो, जाँच बहुत ही शानदार है, लेकिन त्रुटि गंभीर नहीं है। हालांकि, सब कुछ बहुत खराब है जब कुछ तर्क को इफ स्टेटमेंट के शरीर में निष्पादित किया जाता है। निम्नलिखित मामले पर विचार करें:

 CFsmTransition* CFsm::AddTransition(....) { .... CFsmEvent* pEvent = AddEvent( eventType ); if ( !pEvent ) return NULL; // Create new transition CFsmTransition* pNewTransition = new CFsmTransition( state ); if ( !pNewTransition ) { delete pEvent; return NULL; } .... } 

विश्लेषक चेतावनी: V668 CWE-570 'pNewTransition' पॉइंटर को अशक्त करने के लिए परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। fsm.cpp 289

स्मृति को मुक्त करने का प्रयास किया जाता है जिसका पता पाइवेंट पॉइंटर में संग्रहीत होता है। स्वाभाविक रूप से, यह नहीं होगा और एक स्मृति रिसाव होगा।

वास्तव में, जब मैंने इस कोड से निपटना शुरू किया, तो यह पता चला कि सब कुछ अधिक जटिल था और शायद एक गलती नहीं थी, लेकिन दो। अब मैं समझाता हूं कि इस कोड में क्या गलत है। ऐसा करने के लिए, हमें AddEvent फ़ंक्शन डिवाइस के साथ खुद को परिचित करना होगा।

 CFsmEvent* CFsm::AddEvent( unsigned int eventType ) { CFsmEvent* pEvent = NULL; // Lookup event by type EventMap::iterator it = m_Events.find( eventType ); if ( it != m_Events.end() ) { pEvent = it->second; } else { pEvent = new CFsmEvent( eventType ); if ( !pEvent ) return NULL; // Store new event into internal map m_Events[ eventType ] = pEvent; } return pEvent; } 

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

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

मुझे यह आभास हुआ कि आप निम्नलिखित कोड के टुकड़े को हटा सकते हैं:

 if ( !pNewTransition ) { delete pEvent; return NULL; } 

अन्य त्रुटियां:

• V668 CWE-571 शून्य के खिलाफ 'रिट' पॉइंटर के परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। TerrainTextureEntry.cpp 120
• V668 CWE-571 शून्य के खिलाफ 'उत्तर' सूचक के परीक्षण में कोई मतलब नहीं है, क्योंकि स्मृति को 'नए' ऑपरेटर का उपयोग करके आवंटित किया गया था। मेमोरी आवंटन त्रुटि के मामले में अपवाद उत्पन्न होगा। SoundManager.cpp 542

त्रुटि N18, N19

 static void dir_scan_callback(struct de *de, void *data) { struct dir_scan_data *dsd = (struct dir_scan_data *) data; if (dsd->entries == NULL || dsd->num_entries >= dsd->arr_size) { dsd->arr_size *= 2; dsd->entries = (struct de *) realloc(dsd->entries, dsd->arr_size * sizeof(dsd->entries[0])); } if (dsd->entries == NULL) { // TODO(lsm): propagate an error to the caller dsd->num_entries = 0; } else { dsd->entries[dsd->num_entries].file_name = mg_strdup(de->file_name); dsd->entries[dsd->num_entries].st = de->st; dsd->entries[dsd->num_entries].conn = de->conn; dsd->num_entries++; } } 

PVS-Studio चेतावनी : V701 CWE-401 realloc () संभावित रिसाव: जब realloc () मेमोरी आवंटित करने में विफल रहता है, तो मूल सूचक 'dsd-> प्रविष्टियां' खो जाता है। एक अस्थायी पॉइंटर को realloc () असाइन करने पर विचार करें। mongoose.cpp 2462

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

यदि स्मृति आबंटन विफल रहता है, तो realloc फ़ंक्शन NULL लौटेगा, और यह NULL dsd-> प्रविष्टियों चर में लिखा जाएगा। जिसके बाद मेमोरी ब्लॉक को मुक्त करना असंभव होगा जिसका पता पहले dsd-> प्रविष्टियों में संग्रहीत किया गया था। स्मृति रिसाव होगा।

एक और गलती: V701 CWE-401 realloc () संभव रिसाव: जब realloc () स्मृति को आवंटित करने में विफल रहता है, तो मूल सूचक 'बफर' खो जाता है। एक अस्थायी पॉइंटर को realloc () असाइन करने पर विचार करें। Preprocessor.cpp 84

निष्कर्ष

मैं यह नहीं कह सकता कि इस बार लेख आकर्षक निकला, या कि मैं बहुत सी भयानक गलतियों को दिखाने में कामयाब रहा। एक बार में एक बार क्या करना जरूरी नहीं है। मैं जो देखता हूं, फिर लिखता हूं ।

आपका ध्यान के लिए धन्यवाद। एक बदलाव के लिए, मैं Instagram @pvs_studio_unicorn और Twitter @Code_Analysis पर मेरे अनुसरण करने के निमंत्रण के साथ लेख को समाप्त करूंगा ।

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