Code Review सिर्फ़ बग ढूँढ़ने के लिए नहीं है
\n\nसोचिए: आपने परफेक्ट कोड लिखा है। वह काम कर रहा है, टेस्ट पास कर रहा है, क्लाइंट भी खुश है। लेकिन code review पर कलीग आता है और... शुरू हो जाता है। "यहाँ == क्यों है, === क्यों नहीं?", "यह मेथड एक साथ 5 काम कर रहा है", "Exception handling कहाँ है?". परिचित लग रहा है?
असल में, PHP पर code review सिर्फ़ बग ढूँढ़ने का खेल नहीं है (हालाँकि यह भी है)। यह कोड को पढ़ने योग्य, सुरक्षित और मेंटेन करने योग्य बनाने का तरीका है। खासकर PHP में, जहाँ 25 सालों के विकास में बहुत सारे "पिटफॉल" जमा हो गए हैं।
\n\nइस आर्टिकल में हम जानेंगे कि code review में PHP कोड की क्या जाँच करें ताकि कोड सिर्फ़ काम न करे, बल्कि क्वालिटी का मानक बने। तैयार हैं? चलिए शुरू करते हैं!
\n\n1. टाइपिंग और सख्त मोड
\n\nPHP 7+ और 8 ने हमें टाइप कंट्रोल के लिए शक्तिशाली टूल दिए हैं। लेकिन कई प्रोजेक्ट आज भी "अराजकता मोड" में जी रहे हैं।
\n\nक्या जाँचें:
\n\n- \n
- क्या आर्गुमेंट्स और रिटर्न वैल्यू के टाइप घोषित हैं? अगर मेथड
intलेता है और आपstringभेज रहे हैं — यह बातचीत का मौका है। \n - क्या फ़ाइल की शुरुआत में
declare(strict_types=1);है? इसके बिना PHP इम्प्लिसिटली टाइप कन्वर्ट करेगा, जो अक्सर छिपी हुई गलतियों का कारण बनता है। \n
<?php\ndeclare(strict_types=1);\n\n// बुरा: टाइप नहीं हैं\nfunction calculate($a, $b) {\n return $a + $b;\n}\n\n// अच्छा: सख्त टाइपिंग\nfunction calculate(int $a, int $b): int {\n return $a + $b;\n}\n?>\n\n\nCode review के लिए सलाह: अगर mixed या बिना स्पेसिफिकेशन के array दिखे — सवाल पूछें "यहाँ वास्तव में क्या अपेक्षित है?"।
2. सुरक्षा: SQL इंजेक्शन और XSS
\n\nPHP — स्विस आर्मी नाइफ़ की तरह: बहुत सारे फंक्शन, और उनमें से कई खतरनाक हैं। खासकर legacy कोड में।
\n\nशीर्ष 3 लाल झंडे:
\n\n- \n
- SQL क्वेरी में कॉन्केटनेशन। अगर
"SELECT * FROM users WHERE id = ".$_GET['id']दिखे — यह मदद की चीख है। \n - बिना एस्केपिंग के डेटा आउटपुट करना।
echo $userInput;— XSS को नमस्ते। \n - पासवर्ड को plain text में स्टोर करना। गंभीरता से, यह आज भी होता है। \n
<?php\n// खतरनाक!\n$sql = "SELECT * FROM users WHERE email = '" . $email . "'";\n\n// सुरक्षित (PDO)\n$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");\n$stmt->execute(['email' => $email]);\n?>\n\n\nPHP code review में हमेशा बाहरी डेटा के साथ काम करने की जाँच करें। कोई भी $_GET, $_POST, $_COOKIE फ़िल्टरेशन से गुज़रना चाहिए।
3. PSR मानकों का पालन
\n\nPHP समुदाय ने PSR (PHP Standards Recommendations) सिर्फ़ दिखावे के लिए नहीं बनाए। यह वह भाषा है जो सभी PHP डेवलपर बोलते हैं।
\n\nहर PR में क्या होना चाहिए:
\n\n- \n
- PSR-12 (कोडिंग स्टाइल): 4 स्पेस का इंडेंटेशन, क्लासेस के लिए नई लाइन पर कर्ली ब्रेसेस, ऑपरेटर्स के आसपास स्पेस। \n
- PSR-4 (ऑटोलोडिंग): नेमस्पेस फ़ाइल पथ से मेल खाना चाहिए। \n
- क्लास के नाम —
StudlyCaps, मेथड —camelCase, कॉन्स्टेंट —UPPER_CASE। \n
<?php\nnamespace App\\Service;\n\nclass UserService // PSR-4: फ़ाइल src/Service/UserService.php में होनी चाहिए\n{\n public function getUserById(int $id): ?User // camelCase\n {\n // ...\n }\n}\n?>\n\n\nटिप: अगर प्रोजेक्ट में ऑटोमैटिक फ़ॉर्मेटिंग (PHP CS Fixer, PHP_CodeSniffer) नहीं है — यह सुधार का पहला पॉइंट है।
\n\n4. जटिलता और आर्किटेक्चर
\n\nअच्छा कोड वह है जिसे किताब की तरह पढ़ा जा सके। और बुरा कोड — प्राचीन पांडुलिपि को समझने जैसा।
\n\nक्या ध्यान दें:
\n\n- \n
- मेथड की लंबाई। अगर मेथड 20-30 लाइनों से ज़्यादा है — तो शायद