C++ पर कोड रिव्यू: क्या जाँचें ताकि कोड 'फट' न जाए

परिचय: C++ पर code review कमज़ोर दिल वालों के लिए क्यों नहीं है

C++ एक ऐसी भाषा है जो प्रोग्रामर को अविश्वसनीय शक्ति देती है। लेकिन, जैसा कि 'स्पाइडर-मैन' के अंकल बेन ने कहा था: "बड़ी शक्ति के साथ बड़ी जिम्मेदारी आती है"। और अगर Python में आप गलती से int और str मिला सकते हैं और केवल एक अपवाद प्राप्त कर सकते हैं, तो C++ में वही लापरवाही अनिर्धारित व्यवहार (UB) का कारण बन सकती है, जो एक महीने बाद ग्राहक के सर्वर पर रात के 3 बजे प्रकट होगा।

C++ पर Code review Jira में एक टिक नहीं है। यह segmentation fault, मेमोरी लीक और घोंघे की तरह धीमे कोड से आपकी ढाल है। कई डेवलपर्स (विशेषकर जो Java या Python से आए हैं) सोचते हैं कि कोड-रिव्यू शैली और वेरिएबल नामों की जाँच है। C++ में यह और गहरा है। यहाँ प्रोग्राम की आत्मा में देखना होता है: मेमोरी प्रबंधन, RAII, const-correctness और यह कि क्या यह स्मार्ट पॉइंटर आपके पैर में गोली नहीं मारेगा।

इस लेख में मैंने C++ कोड जाँच के लिए एक वास्तविक चेक-लिस्ट एकत्र की है। जब आप अगला code review करें तो इसे अपनाएँ। चलिए शुरू करते हैं!

1. मेमोरी लीक और संसाधन प्रबंधन (RAII)

यह C++ का परम पवित्र है। यदि आप delete के बिना new देखते हैं - यह एक लाल झंडा है। लेकिन आधुनिक C++ (C++11 और उससे नए) में हमें मैन्युअल रूप से new नहीं लिखना चाहिए। स्मार्ट पॉइंटर्स का उपयोग करें: std::unique_ptr, std::shared_ptr। यदि डेवलपर संसाधन के स्वामित्व के लिए रॉ पॉइंटर्स (int*) का उपयोग करता है - यह प्रश्न पूछने का कारण है।

खराब कोड का उदाहरण (लाल झंडा):

void process() {\n    int* data = new int[1000];\n    // ... कुछ कोड ...\n    if (error) {\n        return; // लीक! delete कॉल नहीं हुआ\n    }\n    delete[] data;\n}\n

अच्छे कोड का उदाहरण (RAII):

void process() {\n    std::vector<int> data(1000);\n    // ... कोड ...\n    if (error) {\n        return; // सब ठीक है, वेक्टर स्वयं मेमोरी साफ़ करेगा\n    }\n}\n

C++ पर code review में क्या जाँचें:

\n
• क्या कोड में new/delete है? यदि हाँ - क्यों? std::make_unique क्यों नहीं?
\n
• क्या विशिष्ट स्वामित्व के लिए std::unique_ptr का उपयोग किया गया है?
\n
• क्या std::shared_ptr को वहाँ मान द्वारा पास किया गया है जहाँ संदर्भ पर्याप्त है (यह atomic counter के कारण महँगा है)?
\n
• क्या अपवादों (exception safety) के दौरान लीक हैं?
\n

2. अनिर्धारित व्यवहार (Undefined Behavior)

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

\n
• ऐरे की सीमा से बाहर जाना: 10 तत्वों वाले ऐरे के लिए arr[10]।
\n
• मूव के बाद वेरिएबल का उपयोग: std::move कोई जादू नहीं है, मूव के बाद ऑब्जेक्ट वैध लेकिन अनिर्धारित अवस्था में होता है।
\n
• Signed integer overflow: INT_MAX + 1 - यह UB है! (Java के विपरीत, जहाँ यह केवल रैपिंग है)।
• Dangling reference: स्थानीय वेरिएबल का संदर्भ लौटाना।

UB का उदाहरण (code review पर इसे खोजें):

int& getValue() {\n    int x = 42;\n    return x; // UB! फ़ंक्शन से बाहर निकलने के बाद x नष्ट हो गया\n}\n\nvoid example() {\n    int& ref = getValue();\n    std::cout << ref; // 42 प्रिंट हो सकता है, या कचरा या क्रैश हो सकता है\n}\n

रिव्यूअर के लिए सुझाव: यदि int के साथ अंकगणित देखते हैं, विशेषकर लूप में या आकारों के साथ काम करते समय - जाँचें कि क्या ओवरफ्लो होगा। इंडेक्स के लिए size_t और सुरक्षित तुलना के लिए std::ssize() का उपयोग करना बेहतर है।

3. Const-correctness: सब कुछ cons