snake_case कन्वर्टर: Python वेरिएबल नेम जेनरेटर
किसी भी टेक्स्ट को तुरंत साफ़ snake_case फ़ॉर्मैट में बदलें। चाहे आप Python कोड लिख रहे हों, डेटाबेस फ़ील्ड्स के नाम रख रहे हों, या नाम रखने के एक जैसे नियम बनाए रख रहे हों, हमारा टूल प्रोग्रामिंग के सबसे अच्छे तरीकों का पालन करते हुए आपके टेक्स्ट को अपने-आप सही snake_case फ़ॉर्मैटिंग में बदल देता है।
किसी भी टेक्स्ट को तुरंत 'snake_case' में बदलता है — कॉलम हेडर, कोई वाक्य या अलग-अलग फ़ॉर्मैट वाला आइडेंटिफ़ायर पेस्ट करें और लोअरकेस (छोटे अक्षरों) और अंडरस्कोर से अलग किया हुआ रिज़ल्ट पाएँ, जिसे आप सीधे कोड में इस्तेमाल कर सकते हैं।
यह स्पेस, हाइफ़न, camelCase के उभार और पहले से मौजूद अंडरस्कोर से शब्दों की सीमा का पता लगाता है, ताकि अलग-अलग सोर्स से मिलने वाले इनपुट बिना किसी प्री-क्लीनिंग के एक जैसा आउटपुट दें।
यह उन कैरेक्टर्स को हटा देता है या बदल देता है जो Python आइडेंटिफ़ायर्स को खराब कर सकते हैं — जैसे कि पैरेंथेसिस, स्लैश, एम्परसैंड — ताकि हर रिज़ल्ट बिना किसी अतिरिक्त regex पास के तुरंत इस्तेमाल किया जा सके।
यह PEP 8 के अनुसार एक्रोनिम्स (acronyms) को पूरी तरह से लोअरकेस (छोटे अक्षरों) में बदलकर (जैसे HTTP → http, API → api) उन्हें हैंडल करता है; PEP 8 पढ़ने में आसानी के लिए एक्रोनिम्स को सामान्य शब्दों की तरह इस्तेमाल करने की सलाह देता है।
यह ऐसा आउटपुट देता है जो Python, Ruby, PHP, SQL और ऐसे किसी भी एनवायरनमेंट के साथ काम करता है जो आइडेंटिफ़ायर में शब्दों को अलग करने के लिए अंडरस्कोर (underscore) को स्टैंडर्ड तरीका मानता है।
यह पूरी तरह से ब्राउज़र में चलता है — इसमें सर्वर राउंड-ट्रिप या रेट लिमिट की ज़रूरत नहीं होती, और यह डेटाबेस कॉलम नामों की पूरी लिस्ट को एक बार में पेस्ट करने के लिए उपयुक्त है।
कैसे इस्तेमाल करें
अपना टेक्स्ट या वेरिएबल का नाम डालें
अपने snake_case रिज़ल्ट का प्रीव्यू देखें
कोड-रेडी टेक्स्ट कॉपी करें
पायथन डेवलपमेंट
- वेरिएबल के नाम
- फ़ंक्शन के नाम
- फ़ाइल के नाम
- मॉड्यूल के नाम
डेटाबेस डेवलपमेंट
- टेबल के नाम
- कॉलम के नाम
- फ़ील्ड आइडेंटिफ़ायर
- क्वेरी पैरामीटर
कॉन्फ़िगरेशन फ़ाइलें
- एनवायरनमेंट वेरिएबल्स
- कॉन्फ़िग कीज़
- सेटिंग के नाम
- फ़ाइल पाथ
| मूल पाठ | परिणाम |
|---|---|
User Name | user_name |
first Name | first_name |
background-color | background_color |
API Response Data | api_response_data |
प्रोग्रामिंग भाषाएँ
- पायथन
- रूबी
- PHP
- SQL
फ़्रेमवर्क
- जैंगो
- फ़्लास्क
- रेल्स
- PostgreSQL
Django मॉडल या SQLAlchemy स्कीमा लिखते समय, कॉलम के नाम के तौर पर इस्तेमाल करने से पहले फ़ील्ड के आसान भाषा वाले विवरण को snake_case में बदल लें — जब आइडेंटिफ़ायर शुरू से ही एक जैसे होते हैं, तो डेटाबेस माइग्रेशन को रिव्यू करना बहुत आसान हो जाता है।
PostgreSQL और MySQL दोनों ही बिना कोटेशन वाले आइडेंटिफ़ायर को केस-इनसेंसिटिव मानते हैं और उन्हें अंदरूनी तौर पर लोअरकेस में बदल देते हैं; snake_case ही एकमात्र ऐसा नेमिंग स्टाइल है जो DB द्वारा लोअरकेस में बदले जाने पर भी एक जैसा दिखता है, जिससे आपका SQL ज़्यादा पोर्टेबल बन जाता है।
Python कॉन्फ़िगरेशन फ़ाइलों और एनवायरनमेंट वेरिएबल्स के लिए, snake_case कीज़ (env vars के लिए SCREAMING_SNAKE_CASE में बदली हुई) का इस्तेमाल stdlib (os.environ) और Pydantic और Dynaconf जैसी लाइब्रेरीज़, दोनों में ही एक आम तरीका है — अपना सेटिंग्स मॉड्यूल लिखने से पहले अपनी कॉन्फ़िग की लिस्ट को इस टूल से ज़रूर चलाकर देखें।
जब आप अलग-अलग केसिंग वाले JSON पेलोड से Python dataclass या TypedDict फ़ील्ड्स को ऑटो-जेनरेट करते हैं, तो पहले सभी कीज़ (keys) को यहाँ पेस्ट करें — एक जैसा snake_case आउटपुट मिलने से क्लास की बॉडी को पढ़ना और उसमें अंतर (diff) देखना बहुत आसान हो जाता है।
Ruby on Rails मॉडल एट्रिब्यूट्स, रूट्स और हेल्पर मेथड्स के लिए Python की तरह ही snake_case कन्वेंशन का पालन करता है — एक ही प्रोजेक्ट पर इन दोनों इकोसिस्टम्स के बीच स्विच करते समय यह टूल बहुत काम आता है।
snake_case नामों को इतना साफ़-साफ़ रखें कि वे खुद ही सब कुछ बता दें — 'user_shipping_address' भले ही लंबा हो, पर उसका मतलब एकदम साफ़ है; वहीं 'u_s_addr' से कोई फ़ायदा नहीं होता, बल्कि भविष्य में पढ़ने वालों के लिए उसे समझना मुश्किल हो जाता है।
PEP 8 के इस सुझाव का पालन करें कि फ़ंक्शन और वेरिएबल के नाम लोअरकेस में और अंडरस्कोर के साथ होने चाहिए, लेकिन मॉड्यूल-लेवल के कॉन्स्टेंट के लिए SCREAMING_SNAKE_CASE का इस्तेमाल होना चाहिए — इन्हें अलग-अलग कन्वेंशन मानें, न कि एक-दूसरे की जगह इस्तेमाल होने वाले।
शुरुआत या आखिर में अंडरस्कोर (underscore) लगाने से बचें, जब तक कि आप Python के खास मतलब का इस्तेमाल न करना चाहते हों — जैसे कि एक अंडरस्कोर से प्राइवेट मेंबर का पता चलता है, और दो अंडरस्कोर लगाने से क्लास में 'नेम मैंगलिंग' (name mangling) होती है।
SQL में, अपने पूरे स्कीमा में एक जैसा तरीका अपनाएं — snake_case टेबल और camelCase कॉलम को मिलाना, प्रोजेक्ट से जुड़ने वाले डेवलपर्स के लिए सबसे ज़्यादा उलझन पैदा करने वाली चीज़ों में से एक है, और इससे हर ORM मैपिंग में दिक्कत आती है।
जब इंटरनल इस्तेमाल के लिए इम्पोर्ट किए गए डेटा (जैसे CSV एक्सपोर्ट या थर्ड-पार्टी API पेलोड) को snake_case में बदलें, तो यह कन्वर्ज़न कई हैंडलर्स में अलग-अलग करने के बजाय, बाउंड्री पर एक ही फ़ंक्शन में करें।
अक्सर पूछे जाने वाले सवाल
हमारे टूल्स और सेवाओं के बारे में आम सवालों के जवाब पाएँ।
snake_case को समझना
snake_case का नाम इसलिए पड़ा क्योंकि इसमें अंडरस्कोर (underscore) ज़मीन पर लेटे हुए साँप जैसे दिखते हैं — यानी शब्द ऊपर-नीचे या डैश के बजाय ज़मीन के स्तर पर जुड़े होते हैं। यह तरीका Python के आने से कई दशक पहले से चला आ रहा है; 1970 के दशक में C स्टैंडर्ड लाइब्रेरी फ़ंक्शंस (जैसे printf, malloc, fopen) और Unix टूल्स के नामों में इसका इस्तेमाल होता था। 2001 में पब्लिश हुए Python के PEP 8 में इसे फ़ंक्शंस, वेरिएबल्स और मॉड्यूल के नामों के लिए ज़रूरी स्टाइल के तौर पर तय किया गया। यही वजह है कि ज़्यादातर डेवलपर्स इसे Python से ही जोड़कर देखते हैं — जबकि Ruby, PHP, SQL और शेल स्क्रिप्टिंग में भी इसका इस्तेमाल उतनी ही आम बात है।
इस कन्वर्टर की सबसे आम ज़रूरत डेटाबेस-टू-कोड मैपिंग के लिए होती है। जब कोई डेटा एनालिस्ट किसी बिज़नेस इंटेलिजेंस टूल से CSV एक्सपोर्ट करता है, तो कॉलम हेडर इंसानों के पढ़ने लायक लेबल के तौर पर आते हैं, जैसे: 'Customer First Name', 'Order Shipping Date', 'Total Revenue (USD)'। इन्हें मैन्युअल रूप से सही Python या SQL आइडेंटिफायर में बदलना — जैसे छोटे अक्षरों (lowercase) में करना, स्पेस की जगह अंडरस्कोर लगाना, ब्रैकेट हटाना — एक दोहराव वाला काम है और बड़े पैमाने पर इसमें गलतियाँ हो सकती हैं। हेडर रो को यहाँ पेस्ट करें, एक ही स्टेप में कन्वर्ट करें, और नतीजे को सीधे अपने Pandas DataFrame रीनेम मैप या SQLAlchemy कॉलम डेफ़िनिशन में इस्तेमाल करें।
दूसरा आम इस्तेमाल का मामला है स्पेसिफिकेशन डॉक्यूमेंट से Django या Flask मॉडल लिखना। प्रोडक्ट की ज़रूरतों में अक्सर फ़ील्ड्स को आम अंग्रेज़ी में बताया जाता है; मॉडल क्लास लिखने से पहले डेवलपर्स को उन्हें snake_case आइडेंटिफ़ायर में बदलना होता है। फ़ील्ड लिस्ट को शुरू में ही इस कन्वर्टर से गुज़ारने पर नाम रखने में होने वाली गड़बड़ी (जैसे कुछ फ़ील्ड्स को मैन्युअली बदलना और कुछ को नहीं) से बचा जा सकता है; ऐसी गड़बड़ियाँ प्रोजेक्ट के दौरान जमा होती रहती हैं और एक बार माइग्रेशन बन जाने के बाद उन्हें ठीक करना महंगा पड़ता है।
इसका एक मैनुअल तरीका है regex सब्स्टिट्यूशन: जैसे camelCase इनपुट के लिए `re.sub(r'(?<!^)(?=[A-Z])', '_', name).lower()` या स्पेस से अलग किए गए इनपुट के लिए `name.replace(' ', '_').lower()`। ये वन-लाइनर साफ़ इनपुट के लिए तो काम करते हैं, लेकिन कुछ खास मामलों (edge cases) में ठीक से काम नहीं करते — जैसे लगातार कैपिटल अक्षर (HTMLParser का h_t_m_l_parser बन जाना), शुरुआत या आखिर में खाली जगह (whitespace), या अलग-अलग तरह के सेपरेटर का इस्तेमाल। यह टूल इन सभी मामलों को संभाल लेता है और इसके लिए आपको regex याद रखने की भी ज़रूरत नहीं पड़ती।
Python (सभी नॉन-कॉन्स्टेंट आइडेंटिफ़ायर), Ruby (मेथड्स, लोकल वेरिएबल्स, सिंबल्स), SQL (सभी मुख्य डेटाबेस में टेबल्स और कॉलम्स), शेल स्क्रिप्ट्स (वेरिएबल और फ़ंक्शन के नाम), और Rust (वेरिएबल्स और फ़ंक्शन्स — camelCase इस्तेमाल करने पर कंपाइलर वॉर्निंग देगा) में snake_case सही विकल्प है। JavaScript/TypeScript, Java, और C# में नॉन-कॉन्स्टेंट आइडेंटिफ़ायर के लिए, और CSS में किसी भी आइडेंटिफ़ायर के लिए यह साफ़ तौर पर गलत है। जब आप एक ही प्रोजेक्ट में कई भाषाओं के साथ काम कर रहे हों, तो हर संदर्भ (context) के लिए सही कन्वर्टर का इस्तेमाल करना उन छोटी-छोटी आदतों में से एक है जो कोडबेस को पढ़ने लायक बनाए रखती हैं।