camelCase कन्वर्टर: JavaScript वेरिएबल नेम जेनरेटर
किसी भी टेक्स्ट को तुरंत साफ़ camelCase फ़ॉर्मैट में बदलें। चाहे आप JavaScript कोड लिख रहे हों, React कंपोनेंट्स का नाम रख रहे हों, या वेरिएबल के नाम रखने के एक जैसे नियम अपना रहे हों, हमारा टूल प्रोग्रामिंग के सबसे अच्छे तरीकों का पालन करते हुए आपके टेक्स्ट को अपने-आप सही camelCase फ़ॉर्मैट में बदल देता है।
यह किसी भी टेक्स्ट को रियल-टाइम में सही camelCase में बदल देता है, ताकि आप फ़ील्ड लेबल या पूरा वाक्य पेस्ट कर सकें और बिना किसी मैनुअल एडिटिंग के तुरंत कोड-रेडी आइडेंटिफ़ायर पा सकें।
यह स्पेशल कैरेक्टर — जैसे हाइफ़न, अंडरस्कोर, स्लैश और पंक्चुएशन — को हटा देता है या नॉर्मलाइज़ कर देता है, ताकि आउटपुट हमेशा सिंटैक्स के हिसाब से सही JavaScript या TypeScript आइडेंटिफ़ायर हो।
यह स्पेस, हाइफ़न, अंडरस्कोर और मिक्स-केस इनपुट से शब्दों की सीमा का पता लगाता है और एक ही बार में सभी आम सेपरेटर स्टाइल को संभालता है।
इससे ऐसा आउटपुट मिलता है जिसे आप बिना किसी अतिरिक्त प्रोसेसिंग के सीधे अपने एडिटर में पेस्ट कर सकते हैं — इसमें न तो आखिर में फालतू स्पेस होते हैं, न ही कोई गलत पंक्चुएशन और न ही कोई छिपी हुई एन्कोडिंग की समस्या।
यह किसी भी लंबाई वाले कई शब्दों वाले वाक्यांशों को संभाल सकता है, इसलिए 'user shipping address line one' जैसे लंबे API रिस्पॉन्स फ़ील्ड का नाम बदलकर इस्तेमाल लायक आइडेंटिफ़ायर रखने के लिए मैन्युअल रूप से 'कैमल-केसिंग' करने के बजाय बस एक बार 'पेस्ट' करना पड़ता है।
यह पूरी तरह से ब्राउज़र में चलता है और इसमें सर्वर के साथ कोई राउंड-ट्रिप नहीं होती, इसलिए बड़ी संख्या में आइडेंटिफ़ायर्स का कन्वर्ज़न भी तुरंत हो जाता है।
कैसे इस्तेमाल करें
अपना टेक्स्ट या वेरिएबल का नाम डालें
अपने camelCase रिज़ल्ट का प्रीव्यू देखें
कोड-रेडी टेक्स्ट कॉपी करें
जावास्क्रिप्ट डेवलपमेंट
- वेरिएबल के नाम
- फ़ंक्शन के नाम
- ऑब्जेक्ट की विशेषताएँ
- मेथड के नाम
React/Vue डेवलपमेंट
- कंपोनेंट प्रॉप्स
- अवस्था चर
- इवेंट हैंडलर्स
- कस्टम हुक्स
सामान्य प्रोग्रामिंग
- API पैरामीटर
- डेटाबेस फ़ील्ड
- कॉन्फ़िगरेशन कीज़
- क्लास के नाम
| मूल पाठ | परिणाम |
|---|---|
user name | userName |
first-last-name | firstLastName |
background_color | backgroundColor |
API response data | apiResponseData |
प्रोग्रामिंग भाषाएँ
- जावास्क्रिप्ट
- टाइपस्क्रिप्ट
- जावा
- C#
फ़्रेमवर्क
- प्रतिक्रिया दें
- व्यू
- एंगुलर
- Node.js
किसी प्रोजेक्ट में सभी वेरिएबल के नामों के लिए एक जैसा camelCase इस्तेमाल करें — अलग-अलग तरह के नेमिंग कन्वेंशन का इस्तेमाल करने से बड़े JavaScript कोडबेस में ऐसे बग आ सकते हैं जिन्हें पकड़ना मुश्किल होता है, खासकर तब जब ऑब्जेक्ट की कीज़ (keys) पर इटरेशन किया जा रहा हो।
जब आप ऐसी REST API का इस्तेमाल कर रहे हों जो snake_case फ़ील्ड नाम देती है (जो Python/Django और Rails में आम तौर पर इस्तेमाल होने वाला पैटर्न है), तो रिस्पॉन्स कीज़ की पूरी लिस्ट यहाँ पेस्ट करें और अपना TypeScript इंटरफ़ेस लिखने से पहले उन्हें एक साथ बदल लें।
रीफ़ैक्टरिंग सेशन के दौरान इस टूल का इस्तेमाल करें, जब आप डेटाबेस कॉलम के नामों (जो अक्सर snake_case में होते हैं) को JavaScript प्रॉपर्टी के नामों में बदल रहे हों — कन्वर्ज़न को जल्दी पकड़ने से आपके ORM लेयर और फ़्रंटएंड मॉडल के बीच मिसमैच (बेमेल) से बचा जा सकता है।
जिन GraphQL स्कीमा में स्पेसिफिकेशन के अनुसार फ़ील्ड के नाम camelCase में होने चाहिए, उनमें लिनटर (linter) द्वारा रिजेक्ट होने से बचने के लिए, अपनी स्कीमा डेफ़िनिशन में पेस्ट करने से पहले अपनी ड्राफ़्ट फ़ील्ड लिस्ट को इस कन्वर्टर से गुज़ारें।
नाम तय करने से पहले यह देख लें कि आपकी टारगेट भाषा में एक्रोनिम्स (acronyms) को कैसे लिखा जाता है — ज़्यादातर मॉडर्न JS/TS स्टाइल गाइड्स (और ESLint कॉन्फ़िग्स) ऑटोमेटेड टूल्स के साथ एक जैसा व्यवहार बनाए रखने के लिए 'APIResponse' के बजाय 'apiResponse' को प्राथमिकता देते हैं।
camelCase आइडेंटिफ़ायर को हमेशा छोटे अक्षर (lowercase letter) से शुरू करें — इसका एकमात्र स्टैंडर्ड अपवाद कंस्ट्रक्टर फ़ंक्शन और React कंपोनेंट हैं, जो PascalCase का इस्तेमाल करते हैं ताकि यह पता चल सके कि उन्हें new या JSX सिंटैक्स के साथ कॉल किया जाना चाहिए।
आइडेंटिफ़ायर को इतना साफ़-साफ़ और जानकारी देने वाला रखें कि वे खुद ही सब कुछ समझा सकें — जैसे 'userShippingAddressLine1' थोड़ा लंबा तो है लेकिन इसमें कोई कन्फ़्यूज़न नहीं है; वहीं 'uSAL1' लिखने में तो समय बचाता है, लेकिन बाद में इसे पढ़ने वाले किसी भी व्यक्ति के लिए इसे समझना मुश्किल हो जाता है।
अपने पूरे कोडबेस के लिए एक ही एक्रोनम कन्वेंशन अपनाएं और ESLint के 'camelcase' नियम के ज़रिए उसे लागू करें — एक ही प्रोजेक्ट में 'getHTTPResponse' और 'getHttpResponse' को मिलाने से अक्सर मर्ज कॉन्फ्लिक्ट होते हैं।
सिर्फ़ बहुत छोटे दायरे (tightly-scoped) वाले लूप वेरिएबल्स को छोड़कर, एक अक्षर वाले या बहुत ज़्यादा छोटे किए गए नामों का इस्तेमाल न करें — camelCase खराब नामकरण की कमी को पूरा नहीं करता, यह बस स्पेस हटा देता है।
जब बाहरी डेटा सोर्स (जैसे CSV हेडर, SQL कॉलम, API पेलोड) को JavaScript ऑब्जेक्ट्स में मैप किया जाए, तो camelCase कन्वर्ज़न बाउंड्री लेयर पर करें — अलग-अलग कॉम्पोनेंट्स में बिखरे हुए कन्वर्ज़न के मुकाबले, एक सिंगल एडॉप्टर फ़ंक्शन का ऑडिट करना आसान होता है।
कोई नया आइडेंटिफ़ायर इस्तेमाल करने से पहले अपने स्कोप में नाम के टकराव (name collisions) की जाँच कर लें, खासकर बड़े मॉड्यूल्स में जहाँ 'userData', 'userDetails', और 'userInfo' जैसे नाम जमा हो सकते हैं और उनका मतलब अस्पष्ट हो सकता है।
अक्सर पूछे जाने वाले सवाल
हमारे टूल्स और सेवाओं के बारे में आम सवालों के जवाब पाएँ।
camelCase को समझना
1970 के दशक में ऑब्जेक्ट-ओरिएंटेड और स्क्रिप्टेड भाषाओं के साथ camelCase सामने आया। जब 1995 में ब्रेंडन आइच ने जावा की परंपराओं को अपनाते हुए JavaScript भाषा बनाई, तो यह JavaScript में नाम रखने का मुख्य तरीका (de-facto convention) बन गया। ECMAScript स्पेसिफिकेशन इसे अनिवार्य नहीं बनाता है, लेकिन Airbnb, Google और StandardJS जैसी सभी प्रमुख JavaScript स्टाइल गाइड वेरिएबल और फ़ंक्शन के नामों के लिए camelCase को ही एकमात्र स्वीकार्य फ़ॉर्मेट मानती हैं। इस आम सहमति का मतलब है कि अगर इसका पालन नहीं किया जाता है, तो डिफ़ॉल्ट रूप से ESLint वॉर्निंग मिलती है और कोड रिव्यू के दौरान यह तुरंत अलग से दिखाई देता है।
यह टूल API इंटीग्रेशन जैसे आम काम में काफी समय बचाता है। Python, Ruby या Go में बनी बैकएंड सर्विस आमतौर पर snake_case कीज़ — जैसे 'user_id', 'created_at', 'shipping_address_line_1' — वाला JSON देती हैं। JavaScript में camelCase का तरीका इस्तेमाल होता है। जब आपको 30 फ़ील्ड वाला रिस्पॉन्स मिलता है और आपको TypeScript इंटरफ़ेस या Zod स्कीमा लिखना होता है, तो हर की (key) को मैन्युअली बदलना थकाऊ और गलतियों वाला काम हो सकता है। यहाँ कीज़ की पूरी लिस्ट पेस्ट करें, उन्हें एक साथ बदलें और रिज़ल्ट को सीधे अपनी टाइप डेफ़िनिशन में पेस्ट करें।
एक और ग्रुप उन डेवलपर्स का है जो बड़े पैमाने पर रीफैक्टरिंग कर रहे हैं। पुराने कोडबेस — खासकर वे जो शुरू में प्लेन HTML+jQuery प्रोजेक्ट्स थे और बाद में React या Vue में माइग्रेट किए गए — में अक्सर नाम रखने का तरीका एक जैसा नहीं होता: कुछ वेरिएबल बैकएंड कोड से कॉपी-पेस्ट किए जाने के कारण snake_case में होते हैं, तो कुछ CSS क्लास नामों के कारण kebab-case में होते हैं जिन्हें गलती से JS आइडेंटिफायर के तौर पर इस्तेमाल किया गया होता है। आइडेंटिफायर की पूरी लिस्ट को इस कन्वर्टर से गुजारने पर आपको काम शुरू करने के लिए एक एक जैसा बेसलाइन मिल जाता है, भले ही आप बाद में ऑटोमेटेड रिप्लेसमेंट के लिए jscodeshift जैसे दूसरे टूल्स का इस्तेमाल करें।
किसी खास कन्वर्टर के बिना, डेवलपर्स आमतौर पर मैन्युअल टाइपिंग, regex के साथ 'find-and-replace' (जिसके लिए सही lookahead/lookbehind सिंटैक्स याद रखना ज़रूरी है), या कस्टम स्क्रिप्ट का इस्तेमाल करते हैं। replace फ़ंक्शन के साथ /(_)([a-z])/g जैसा regex काम तो करता है — लेकिन सिर्फ़ अंडरस्कोर से अलग किए गए इनपुट के लिए। स्पेस, हाइफ़न या पहले से मौजूद मिक्स्ड केस वाले इनपुट के लिए कई बार रिप्लेसमेंट (chained replacements) करने पड़ते हैं। यह टूल एक ही बार में सभी तरह के सेपरेटर को संभाल लेता है और साफ़ आउटपुट देता है जिसे आप सीधे अपने एडिटर में पेस्ट कर सकते हैं।
camelCase का इस्तेमाल खास तौर पर इन जगहों पर ज़रूरी है या आम तौर पर किया जाता है: JavaScript और TypeScript (वेरिएबल्स, फंक्शन्स, ऑब्जेक्ट प्रॉपर्टीज़, React प्रॉप्स), Java (फ़ील्ड्स और मेथड्स), C# (लोकल वेरिएबल्स और पैरामीटर्स), Swift (प्रॉपर्टीज़ और फंक्शन्स), और Google JSON स्टाइल गाइड को फ़ॉलो करने वाली APIs में JSON कीज़। Python (जहाँ PEP 8 फंक्शन्स और वेरिएबल्स के लिए snake_case का इस्तेमाल ज़रूरी बताता है) और CSS (जो kebab-case का इस्तेमाल करता है) में इसे साफ़ तौर पर मना किया गया है। असली हुनर यह जानना है कि कब camelCase सही टूल है — और कब इसके बजाय snake_case या kebab-case कन्वर्टर्स का इस्तेमाल करना चाहिए।