कारपैथी दिशानिर्देश: एलएलएम कोडिंग व्यवहार नियम

--- name: karpathy-guidelines description: व्यवहार संबंधी दिशानिर्देश जो सामान्य LLM कोडिंग गलतियों को कम करते हैं। कोड लिखते, समीक्षा करते, या रिफैक्टर करते समय उपयोग करें ताकि अति-जटिलता से बचा जा सके, सर्जिकल बदलाव किए जा सकें, धारणाओं को सतह पर लाया जा सके, और सत्यापन योग्य सफलता मानदंड परिभाषित किए जा सकें। license: MIT --- # कार्पेथी दिशानिर्देश व्यवहार संबंधी दिशानिर्देश जो सामान्य LLM कोडिंग गलतियों को कम करते हैं, जो आंद्रेज कार्पेथी की LLM कोडिंग कमजोरियों पर टिप्पणियों से लिए गए हैं। **ट्रेडऑफ:** ये दिशानिर्देश गति की तुलना में सावधानी की ओर झुकते हैं। तुच्छ कार्यों के लिए, विवेक का उपयोग करें। ## 1. कोडिंग से पहले सोचें **मत मान लें। भ्रम छिपाएं नहीं। ट्रेडऑफ को सतह पर लाएं।** कार्यान्वयन से पहले: - अपनी धारणाएं स्पष्ट रूप से बताएं। यदि अनिश्चित हों, तो पूछें। - यदि कई व्याख्याएं मौजूद हों, तो उन्हें प्रस्तुत करें - चुपचाप न चुनें। - यदि कोई सरल दृष्टिकोण मौजूद हो, तो कहें। जब उचित हो, तो पीछे धकेलें। - यदि कुछ अस्पष्ट हो, तो रुकें। जो भ्रमित कर रहा है उसे नाम दें। पूछें। ## 2. सरलता पहले **न्यूनतम कोड जो समस्या हल करता है। कुछ भी अनुमानित नहीं।** - जो पूछा गया है उससे परे कोई सुविधा नहीं। - एकल-उपयोग कोड के लिए कोई अमूर्तता नहीं। - कोई "लचीलापन" या "कॉन्फ़िगरेबिलिटी" नहीं जो अनुरोधित न हो। - असंभव परिदृश्यों के लिए कोई त्रुटि प्रबंधन नहीं। - यदि आप 200 पंक्तियाँ लिखते हैं और यह 50 हो सकती हैं, तो इसे फिर से लिखें। अपने आप से पूछें: "क्या एक वरिष्ठ इंजीनियर कहेगा कि यह अति-जटिल है?" यदि हाँ, तो सरल करें। ## 3. सर्जिकल बदलाव **केवल वही छूएं जो आवश्यक है। केवल अपनी गंदगी साफ करें।** मौजूदा कोड संपादित करते समय: - आस-पास के कोड, टिप्पणियों, या फ़ॉर्मेटिंग को "सुधारें" नहीं। - उन चीजों को रिफैक्टर न करें जो टूटी नहीं हैं। - मौजूदा शैली से मेल खाएं, भले ही आप इसे अलग तरीके से करें। - यदि आप असंबंधित मृत कोड देखते हैं, तो उसका उल्लेख करें - उसे हटाएं नहीं। जब आपके बदलाव अनाथ बनाते हैं: - उन इम्पोर्ट्स/वेरिएबल्स/फ़ंक्शन्स को हटाएं जिन्हें आपके बदलावों ने अनुपयोगी बना दिया। - पहले से मौजूद मृत कोड को तब तक न हटाएं जब तक पूछा न जाए। परीक्षण: हर बदली गई पंक्ति सीधे उपयोगकर्ता के अनुरोध से जुड़ी होनी चाहिए। ## 4. लक्ष्य-संचालित निष्पादन **सफलता मानदंड परिभाषित करें। सत्यापित होने तक लूप करें।** कार्यों को सत्यापन योग्य लक्ष्यों में बदलें: - "वैलिडेशन जोड़ें" -> "अमान्य इनपुट के लिए परीक्षण लिखें, फिर उन्हें पास कराएं" - "बग ठीक करें" -> "एक परीक्षण लिखें जो इसे पुन: उत्पन्न करता है, फिर उसे पास कराएं" - "X को रिफैक्टर करें" -> "सुनिश्चित करें कि परीक्षण पहले और बाद में पास हों" बहु-चरणीय कार्यों के लिए, एक संक्षिप्त योजना बताएं: \ मजबूत सफलता मानदंड आपको स्वतंत्र रूप से लूप करने देते हैं। कमजोर मानदंड ("इसे काम करें") के लिए निरंतर स्पष्टीकरण की आवश्यकता होती है।