Kotlin टीम में: फ़ॉर्मेटिंग पर बहस करना बंद करें और कोड लिखना शुरू करें
\n\nक्या आपने कभी कोड रिव्यू किया है जहां आधी टिप्पणियाँ "स्पेस लगाओ", "स्पेस हटाओ" या "तुम्हारे पास CamelCase क्यों है, snake_case क्यों नहीं?" तक सीमित थीं? यदि हाँ, तो क्लब में आपका स्वागत है। किसी भी टीम में देर-सबेर सवाल उठता है: कोड स्टाइल और Kotlin कन्वेंशन। और अगर पहले से सहमति नहीं बनी, तो हर कोई अपना "आदर्श" ब्रैकेट लेआउट लाएगा।
\n\nयह लेख नियमों की सूखी सूची नहीं है। यह एक व्यावहारिक मार्गदर्शिका है कि Kotlin कोड को पूरी टीम के लिए पढ़ने योग्य, एकसमान और सुविधाजनक कैसे बनाया जाए। हम प्रमुख कन्वेंशन, ऑटोमेशन टूल्स और लाइफ़हैक्स पर चर्चा करेंगे जो कॉल पर बहस के घंटों को बचाएंगे।
\n\nKotlin में कोड स्टाइल सौंदर्यशास्त्र के बारे में नहीं, बल्कि पैसे के बारे में क्यों है
\n\nआइए ईमानदार रहें: व्यवसाय को इससे कोई फर्क नहीं पड़ता कि आप कर्ली ब्रैकेट उसी लाइन पर रखते हैं या नई लाइन पर। लेकिन व्यवसाय को इससे फर्क पड़ता है कि किसी नए डेवलपर को प्रोजेक्ट में शामिल होने में कितना समय लगता है। शोध से पता चलता है कि डेवलपर्स कोड पढ़ने में 40% तक समय बिताते हैं। यदि कोड एक समान Kotlin कोड स्टाइल में लिखा गया है, तो यह प्रक्रिया कई गुना तेज हो जाती है।
\n\nजब प्रोजेक्ट में एक समान Kotlin कोड स्टाइल का उपयोग किया जाता है:
\n- \n
- टीम के नए सदस्य प्रोजेक्ट संरचना को तेजी से समझते हैं। \n
- कोड रिव्यू तेजी से होता है - समीक्षक लॉजिक त्रुटियों की तलाश करते हैं, स्पेस की नहीं। \n
- गलत फ़ॉर्मेटिंग के कारण बग की संख्या कम होती है (हाँ, ऐसा भी होता है)। \n
- Git-डिफ़ साफ़ होते हैं - रीफ़ॉर्मेटिंग से कम शोर। \n
इसलिए Kotlin कन्वेंशन लीड की सनक नहीं, बल्कि दक्षता बढ़ाने का एक उपकरण है। और अब हम देखेंगे कि उन्हें बिना दर्द के कैसे लागू किया जाए।
\n\nआधिकारिक गाइड: Kotlin कोडिंग कन्वेंशन
\n\nआइए बुनियादी बातों से शुरू करें: JetBrains के पास एक आधिकारिक दस्तावेज़ है - Kotlin कोडिंग कन्वेंशन। यह कोई कानून नहीं है, लेकिन बुद्धिमान लोग इसे शुरुआती बिंदु के रूप में सुझाते हैं। आइए प्रमुख बिंदुओं पर नज़र डालें जो अक्सर विवाद का कारण बनते हैं।
\n\nनामकरण: CamelCase हमेशा के लिए
\n\nKotlin हर चीज़ के लिए CamelCase का उपयोग करता है: क्लास - बड़े अक्षर से (MyAwesomeClass), फ़ंक्शन और वेरिएबल - छोटे अक्षर से (myAwesomeFunction)। टॉप-लेवल या ऑब्जेक्ट के अंदर कॉन्स्टेंट - SCREAMING_SNAKE_CASE। वेरिएबल नामों में कोई अंडरस्कोर नहीं - यह Python नहीं है।
// सही\nclass UserProfile\nval userName: String\nfun getUserData(): UserData\n\n// गलत\nclass user_profile\nval user_name: String\nfun get_user_data(): UserData\n\nकर्ली ब्रैकेट: उसी लाइन पर खोलें
\n\nKotlin Java परंपरा का पालन करता है: खोलने वाला ब्रैकेट घोषणा के समान लाइन पर होता है। इस पर चर्चा नहीं की जाती, जब तक कि आप विधर्मी नहीं कहलाना चाहते।
\n\n// Kotlin तरीका\nfun processData(data: List<String>) {\n data.forEach { item ->\n println(item)\n }\n}\n\n// गैर-Kotlin तरीका (लेकिन अगर पूरी टीम ऐसे लिखती है - ठीक है)\nfun processData(data: List<String>)\n{\n data.forEach { item ->\n println(item)\n }\n}\n\nस्पेस: उन पर कंजूसी न करें
\n\nकीवर्ड (if, for, when) के बाद, बाइनरी ऑपरेटरों के आसपास और कॉमा के बाद स्पेस लगाएं। इससे पठनीयता बढ़ती है।
// पढ़ने योग्य\nif (x > 0 && y < 10) {\n println("Hello, World!")\n}\n\n// आँखों के लिए भारी\nif(x>0&&y<10){\n println("Hello, World!")\n}\n\nऑटोफ़ॉर्मेटिंग: आपका सबसे अच्छा दोस्त
\n\nमैन्युअल कोड स्टाइल जाँच पुरानी बात है। Kotlin में IntelliJ IDEA में बिल्ट-इन फ़ॉर्मेटर है: Ctrl+Alt+L (या Mac पर Cmd+Option+L). लेकिन अगर आपकी टीम में कोई VS Code या कोई अन्य एडिटर का उपयोग करता है - तो समस्याएँ अपरिहार्य हैं।
समाधान: ktlint और Spotless।
\n\nktlint: सार्वभौमिक सैनिक
\n\nktlint एक उपकरण है जो जाँचता है और स्वचालित रूप से