नमस्कार, हेब्र! मैं आपके ध्यान में JetBrains के कोटलिन कोडिंग कन्वेंशन डॉक्यूमेंटेशन पेज के लेखक का ध्यान आकर्षित करता हूं।

→ मूल दस्तावेज

सामग्री:

• इंटेलीज आइडिया में स्टाइल गाइड का उपयोग करना
• परियोजना की संरचना
  
  • फ़ोल्डर संरचना
  • स्रोत फ़ाइलों का नाम
  • स्रोत फ़ाइलों का आयोजन
  • वर्ग संरचना
  • इंटरफ़ेस कार्यान्वयन फ्रेमवर्क
  • ओवरराइड स्ट्रक्चर
• नामकरण नियम
  
  • कार्य का नाम
  • परीक्षण विधियों का नाम
  • संपत्ति का नामकरण
    
    • छिपे हुए गुणों का नामकरण
  • सही नाम चुनना
• स्वरूपण
  
  • क्षैतिज स्थान
  • पेट
  • वर्ग घोषणा प्रारूपण
  • संशोधक
  • प्रारूप एनोटेशन
  • फ़ाइल एनोटेशन
  • कार्य स्वरूपण
  • एकल-पंक्ति अभिव्यक्ति स्वरूपण
  • संपत्ति स्वरूपण
  • स्वरूपण नियंत्रण निर्देश
  • स्वरूपण विधि कॉल
  • एक चेन फंक्शन कॉल को फॉर्मेट करना
  • स्वरूपण लंबोदर भाव
• प्रलेखन बनाना
• अनावश्यक निर्माणों से बचना
  
  • कीवर्ड यूनिट का उपयोग करें
  • सेमीकोलन
  • स्ट्रिंग पैटर्न
• भाषा की विशेषताओं का मुहावरेदार उपयोग
  
  • अचलता
  • डिफ़ॉल्ट पैरामीटर मान
  • उपनाम बनाना [प्रकार उपनाम]
  • लंबोदर भावों में नामकरण
  • लंबोदर भावों से मान लौटाएं
  • तर्क नामकरण के साथ कॉलिंग के तरीके
  • शर्तों के साथ नियंत्रण संरचनाओं के लिए नियम
  • if बनाम
  • बूलियन मूल्यों का उपयोग करना? सशर्त बयानों में
  • छोरों का उपयोग करना
  • रेंज साइकल
  • स्ट्रिंग स्वरूपण
  • कार्य बनाम गुण
  • एक्सटेंशन सुविधाओं का उपयोग करना
  • Infix फ़ंक्शंस का उपयोग करना
  • फैक्टरी सुविधाएँ
  • मंच के प्रकार
  • apply / के with / run / also / let apply
• पुस्तकालय बनाने के नियम

इंटेलीज आइडिया में स्टाइल गाइड का उपयोग करना

वर्तमान मैनुअल के अनुसार इंटेलीज आइडिया में फॉर्मेटिंग लागू करने के लिए, आपको कोटलिन प्लगइन संस्करण 1.2.20 या बाद के संस्करण को स्थापित करने की आवश्यकता है, सेटिंग्स पर जाएं। संपादक | कोड शैली | कोटलिन, ऊपरी दाएं कोने में "सेट से ..." लिंक पर क्लिक करें और ड्रॉप-डाउन मेनू से "पूर्वनिर्धारित शैली" / कोटलिन शैली गाइड चुनें।

यह सत्यापित करने के लिए कि आपके कोड को अनुशंसित शैली के अनुसार स्वरूपित किया गया है, निरीक्षण सेटिंग पर जाएं और चेक को सक्षम करें "कोट | शैली मुद्दे | फ़ाइल परियोजना सेटिंग्स के अनुसार स्वरूपित नहीं है"। अन्य सत्यापन नियम, जैसे नामकरण परंपराएं, डिफ़ॉल्ट रूप से सक्षम हैं।

परियोजना की संरचना

फ़ोल्डर संरचना

विभिन्न भाषाओं का उपयोग करने वाली परियोजनाओं में, कोटलिन कोड वाली फ़ाइलों को अन्य भाषाओं में कोड के समान फ़ोल्डर में झूठ बोलना चाहिए और उसी फ़ाइल संरचना का उपयोग करना चाहिए जिसे मुख्य भाषा के लिए स्वीकार किया जाता है। उदाहरण के लिए, जावा के लिए, फ़ाइलों को पैकेज के नाम के अनुसार फ़ोल्डर संरचना में झूठ होना चाहिए।

केवल कोटलिन का उपयोग करने वाली परियोजनाओं में, अनुशंसित फ़ोल्डर संरचना है: फ़ोल्डर का उपयोग रूट निर्देशिका के साथ संकुल को व्यवस्थित करने के लिए छोड़ दिया गया, अर्थात। यदि परियोजना का सभी कोड पैकेज "org.example.kotlin" और उसके पैकेजों में है, तो पैकेज से संबंधित स्रोत "org.example.kotlin" परियोजना की रूट डायरेक्टरी में होना चाहिए, और पैकेज के स्रोत कोड वाली फाइलें "org।" example.kotlin.foo.bar "परियोजना की जड़ के सापेक्ष उपनिर्देशिका" फू / बार "में झूठ होना चाहिए।

स्रोत फ़ाइलों का नाम

यदि कोटलिन फ़ाइल में केवल एक वर्ग होता है (संभवतः शीर्ष-स्तरीय घोषणा से संबंधित), तो इसे नाम दिया जाना चाहिए, साथ ही विस्तार के साथ एक वर्ग। यदि फ़ाइल में कई कक्षाएं हैं या केवल शीर्ष-स्तरीय घोषणाएँ हैं, तो एक नाम चुनें जो बताता है कि फ़ाइल में क्या है और तदनुसार फ़ाइल का नाम रखें। फ़ाइलों के नाम के लिए पहले अक्षर के साथ ऊंट कूबड़ का उपयोग करें (उदा। ProcessDeclarations.kt )।

फ़ाइल नाम का वर्णन करना चाहिए कि फ़ाइल में कोड क्या है। यही है, आपको फ़ाइलों के नामकरण के लिए "यूटिल" जैसे अर्थहीन शब्दों से बचना चाहिए।

स्रोत फ़ाइलों का आयोजन

एक ही Kotlin स्रोत फ़ाइल में कई घोषणाओं (वर्गों, कार्यों या शीर्ष स्तर के गुणों) रखने का स्वागत है अगर ये घोषणाएं एक-दूसरे से शब्दार्थ से संबंधित हैं और फ़ाइल का आकार उचित रहता है (कुछ सौ लाइनों से अधिक नहीं)।

विशेष रूप से, जब इस वर्ग को लागू करने के सभी पहलुओं पर लागू होने वाले वर्ग के लिए एक्सटेंशन फ़ंक्शंस को परिभाषित करते हैं, तो उन्हें उसी फ़ाइल में डालें जहां कक्षा खुद को परिभाषित करती है। एक्सटेंशन फ़ंक्शंस को परिभाषित करते समय जो केवल इस वर्ग के उपयोग के विशिष्ट संदर्भ के लिए सार्थक होते हैं, उन्हें एक्सटेंशन फ़ंक्शन का उपयोग करने वाले कोड के बगल में रखें। केवल "सभी फू एक्सटेंशन" संग्रहीत करने के लिए फाइलें न बनाएं।

वर्ग संरचना

आमतौर पर, एक वर्ग की सामग्री को निम्न क्रम में क्रमबद्ध किया जाता है:

• संपत्ति घोषणाएं और प्रारंभिक ब्लॉक
• माध्यमिक कंस्ट्रक्टर
• विधि घोषणाएँ
• साथी वस्तुओं

विधि घोषणाओं को वर्णानुक्रम या नेत्रहीन रूप से क्रमबद्ध न करें, और सामान्य विधियों को विस्तार विधियों से अलग न करें। इसके बजाय, तार्किक रूप से जुड़े कोड को एक साथ रखें ताकि जो कोई भी ऊपर से नीचे तक कक्षा को पढ़ता है वह क्या होता है के तर्क का पालन कर सकता है। एक प्रकार का क्रम चुनें (उच्च स्तर का कोड पहले [उच्च-स्तरीय सामान पहले] और बाद में या इसके विपरीत विवरण) और उस पर चिपके रहें।

इन वर्गों का उपयोग करने वाले कोड के आगे नेस्टेड कक्षाएं रखें। यदि कक्षाएं बाहरी उपयोग के लिए अभिप्रेत हैं और वर्ग के भीतर संदर्भित नहीं हैं, तो उन्हें साथी ऑब्जेक्ट के बाद अंत में डाल दें।

इंटरफ़ेस कार्यान्वयन फ्रेमवर्क

इंटरफ़ेस लागू करते समय, जिस संरचना को लागू किया जा रहा है, उसी संरचना को रखें (यदि आवश्यक हो, तो इसे लागू करने के लिए उपयोग किए गए अतिरिक्त निजी तरीकों के साथ वैकल्पिक करें)

ओवरराइड स्ट्रक्चर

Redefinitions हमेशा एक साथ, एक के बाद एक डालते हैं।

नामकरण नियम

कोटलिन जावा के समान नामकरण सम्मेलनों का अनुसरण करता है। विशेष रूप से:

लोअरकेस पैकेज नाम और अंडरस्कोर (org.example.myproject) का उपयोग न करें। बहु-शब्द नामों का उपयोग करना आमतौर पर अनुशंसित नहीं है, लेकिन यदि आपको कई शब्दों का उपयोग करने की आवश्यकता है, तो आप या तो उन्हें एक साथ जोड़ सकते हैं या ऊंट कूबड़ (org.examle.myProject) का उपयोग कर सकते हैं।

कैपिटल और ऑब्जेक्ट नाम एक कैपिटल लेटर से शुरू होते हैं और ऊंट कूबड़ का उपयोग करते हैं:

 open class DeclarationProcessor { ... } object EmptyDeclarationProcessor : DeclarationProcessor() { ... } 

कार्य का नाम

फ़ंक्शन, गुण और स्थानीय चर के नाम एक लोअरकेस अक्षर से शुरू होते हैं और इसमें अंडरस्कोर नहीं होते हैं:

 fun processDeclarations() { ... } var declarationCount = ... 

अपवाद: फैक्ट्री क्लास के लिए उपयोग किए जाने वाले फ़ैक्ट्री फ़ंक्शंस का एक ही नाम हो सकता है जैसे क्लास बनाया जा रहा है:

 abstract class Foo { ... } class FooImpl : Foo { ... } fun Foo(): Foo { return FooImpl(...) } 

परीक्षण विधियों का नाम

परीक्षणों में (और केवल परीक्षणों में) उल्टे अल्पविरामों में संलग्न स्थानों के साथ विधि के नाम का उपयोग करने की अनुमति है। (ध्यान दें कि ऐसे विधि नाम वर्तमान में एंड्रॉइड रनटाइम द्वारा समर्थित नहीं हैं।) टेस्ट कोड में विधि नामों में अंडरस्कोर की भी अनुमति है।

 class MyTestCase { @Test fun `ensure everything works`() { ... } @Test fun ensureEverythingWorks_onAndroid() { ... } } 

संपत्ति का नामकरण

लगातार नाम (गुण लेबल const , या शीर्ष स्तर के गुण या कस्टम ऑब्जेक्ट के बिना एक val ऑब्जेक्ट जो अपरिवर्तनीय डेटा शामिल है) को कैपिटल किया जाना चाहिए, अंडरस्कोर द्वारा अलग किया गया है:

 const val MAX_COUNT = 8 val USER_NAME_FIELD = "UserName" 

शीर्ष-स्तरीय नाम या ऑब्जेक्ट गुण जिसमें व्यवहार या उत्परिवर्तित डेटा वाली वस्तुएं होती हैं उन्हें ऊंट कूबड़ में सामान्य नामों का उपयोग करना चाहिए:

 val mutableCollection: MutableSet<String> = HashSet() 

संपत्ति के नाम जो सिंग्लटन ऑब्जेक्ट्स को संदर्भित करते हैं, वर्ग घोषणा के रूप में उसी नामकरण शैली का उपयोग कर सकते हैं:

 val PersonComparator: Comparator<Person> = ... 

गणना के लिए, आप उपयोग के आधार पर, बड़े अक्षरों में अलग किए गए कैपिटल अक्षरों में लिखे गए नामों का उपयोग कर सकते हैं या ऊंट कूबड़ शैली में, कैपिटल लेटर से शुरू कर सकते हैं।

 enum class Color { RED, GREEN } 

 enum class Color { RedColor, GreenColor } 

अनुवादक का नोट: बस अलग-अलग शैलियों का मिश्रण न करें। एक शैली चुनें और इसे अपने डिजाइन में चिपका दें।

छिपे हुए गुणों का नामकरण

यदि किसी वर्ग में दो गुण होते हैं जो वैचारिक रूप से समान होते हैं, लेकिन एक सार्वजनिक एपीआई का हिस्सा है और दूसरा कार्यान्वयन का हिस्सा है, छिपी हुई संपत्ति के नाम के लिए उपसर्ग के रूप में अंडरस्कोर का उपयोग करें:

 class C { private val _elementList = mutableListOf<Element>() val elementList: List<Element> get() = _elementList } 

सही नाम चुनना

कक्षा का नाम आमतौर पर एक संज्ञा या वाक्यांश होता है जो बताता है कि कक्षा क्या है:

 List, PersonReader 

विधि का नाम आमतौर पर एक क्रिया या वाक्यांश क्रिया है जो बताती है कि विधि क्या करती है:

 close, readPersons 

नाम को यह भी इंगित करना चाहिए कि क्या विधि ऑब्जेक्ट को बदलती है या एक नया रिटर्न देती है। उदाहरण के लिए, sort एक ऐसा सॉर्ट है जो संग्रह को बदलता है, और sorted गया संग्रह की नई सॉर्ट की गई प्रतिलिपि की वापसी है।

नामों को इकाई के उद्देश्य को स्पष्ट रूप से इंगित करना चाहिए, इसलिए नामों में अर्थहीन शब्दों ( Manager , Wrapper , आदि) के उपयोग से बचना बेहतर है।

जब विज्ञापन नाम के हिस्से के रूप में संक्षिप्त नाम का उपयोग करते हैं, तो कैपिटल अक्षरों का उपयोग करें यदि इसमें दो अक्षर ( IOStream ) शामिल हैं; या केवल पहला अक्षर अपरकेस, अगर यह लंबा है ( XmlFormatter , HttpInputStream )।

स्वरूपण

ज्यादातर मामलों में, कोटलिन जावा प्रारूपण सम्मेलनों का अनुसरण करता है।

इंडेंट करने के लिए 4 रिक्त स्थान का उपयोग करें। टैब का उपयोग न करें।

ब्रेसिज़ के लिए, उद्घाटन ब्रेस को उस पंक्ति के अंत में रखें जहाँ संरचना शुरू होती है और एक अलग लाइन पर ब्रेसिंग ब्रेस, क्षैतिज रूप से उद्घाटन संरचना के साथ संरेखित होती है।

 if (elements != null) { for (element in elements) { // ... } } 

(नोट: कोटलिन में, एक अर्धविराम वैकल्पिक है, इसलिए लाइन रैपिंग महत्वपूर्ण है। भाषा शैली में जावा शैली में घुंघराले ब्रेसिज़ शामिल हैं, और यदि आप एक अलग स्वरूपण शैली का उपयोग करने का प्रयास करते हैं तो आप अप्रत्याशित कोड निष्पादन व्यवहार का सामना कर सकते हैं।)

क्षैतिज स्थान

बाइनरी ऑपरेटरों (a + b) आसपास रिक्त स्थान रखें। अपवाद: "ऑपरेटर" (0..i) लिए "सीमा" के आसपास रिक्त स्थान न (0..i)

अपर संचालकों के आसपास स्थान न रखें (a++)

कुंजी नियंत्रण शब्दों के बीच रिक्त स्थान रखें ( if , when , के for और while ) और संबंधित शुरुआती कोष्ठक।

एक कंस्ट्रक्टर, विधि या विधि की प्राथमिक घोषणा में ब्रैकेट खोलने से पहले एक स्थान न रखें।

 class A(val x: Int) fun foo(x: Int) { ... } fun bar() { foo(1) } 

( , [ या पहले ] , ) बाद कभी भी एक जगह न रखें।

एक बिंदु के आसपास कभी भी जगह न रखें . या ऑपरेटर ?. :

 foo.bar().filter { it > 2 }.joinToString() foo?.() 

टिप्पणी के लिए डबल स्लैश के बाद एक स्थान रखें // :

 //   

प्रकार के मापदंडों को इंगित करने के लिए उपयोग किए जाने वाले कोण कोष्ठक के चारों ओर रिक्त स्थान न रखें:

 Class Map<K, V> { ... } 

डबल क्लास के आसपास रिक्त स्थान न डालें: संदर्भ के लिए :: वर्ग विधि:

 Foo::class String::length 

पहले एक जगह नहीं है ? एक null को चिह्नित करने के लिए उपयोग किया जाता है:

 String? 

आम तौर पर, किसी भी प्रकार के क्षैतिज संरेखण से बचें। एक अलग लंबाई के नाम के लिए एक पहचानकर्ता का नाम बदलना कोड के स्वरूपण को प्रभावित नहीं करना चाहिए।

पेट

बृहदान्त्र से पहले एक जगह रखो : निम्नलिखित मामलों में:

• जब इसे सुपर प्रकार से अलग करने के लिए उपयोग किया जाता है;

 abstract class Foo<out T : Any> 

• जब एक सुपरक्लास कंस्ट्रक्टर या उसी क्लास के दूसरे कंस्ट्रक्टर को सौंपना;

 constructor(x: String) : super(x) { ... } constructor(x: String) : this(x) { ... } 

• कीवर्ड ऑब्जेक्ट के बाद।

 val x = object : IFoo { ... } 

पहले एक स्थान न रखें : जब वह एक विज्ञापन और उसके प्रकार को अलग करता है।

 abstract fun foo(a: Int): T 

हमेशा एक स्थान रखें :

 abstract class Foo<out T : Any> : IFoo { abstract fun foo(a: Int): T } class FooImpl : Foo() { constructor(x: String) : this(x) { ... } val x = object : IFoo { ... } } 

वर्ग घोषणा प्रारूपण

कई बुनियादी निर्माण मापदंडों और छोटे नामों वाली कक्षाएं एक पंक्ति में लिखी जा सकती हैं:

 class Person(id: Int, name: String) 

लंबे नाम या मापदंडों की संख्या वाली कक्षाओं को प्रारूपित किया जाना चाहिए ताकि निर्माणकर्ता का प्रत्येक मुख्य पैरामीटर इंडेंटेशन के साथ एक अलग लाइन पर हो। साथ ही, क्लोजिंग ब्रैकेट नई लाइन पर होना चाहिए। यदि हम वंशानुक्रम का उपयोग करते हैं, तो सुपरक्लास के निर्माता को कॉल करें या कार्यान्वित इंटरफेस की सूची को ब्रैकेट के समान लाइन पर स्थित होना चाहिए:

 class Person( id: Int, name: String, surname: String ) : Human(id, name) { ... } 

जब इंटरफ़ेस को निर्दिष्ट करना और सुपरक्लास के निर्माता को कॉल करना, सुपरक्लास का निर्माणकर्ता पहले स्थित होना चाहिए, तो एक नई लाइन पर इंटरफ़ेस का नाम वाम-औचित्य है:

 class Person( id: Int, name: String, surname: String ) : Human(id, name), KotlinMaker { ... } 

सुपर प्रकार की एक लंबी सूची वाले वर्गों के लिए, आपको बृहदान्त्र के बाद एक लाइन ब्रेक लगाने और बाईं ओर क्षैतिज रूप से सभी सुपर प्रकार के नामों को संरेखित करने की आवश्यकता है:

 class MyFavouriteVeryLongClassHolder : MyLongHolder<MyFavouriteVeryLongClass>(), SomeOtherInterface, AndAnotherOne { fun foo() { ... } } 

क्लास हेडिंग को स्पष्ट रूप से अलग करने के लिए और जब क्लास की हेडिंग लंबी होती है, या तो क्लास हेडिंग के बाद एक खाली लाइन रखें (जैसा कि ऊपर दिए गए उदाहरण में है), या ओपनिंग ब्रेस को एक अलग लाइन पर रखें:

 class MyFavouriteVeryLongClassHolder : MyLongHolder<MyFavouriteVeryLongClass>(), SomeOtherInterface, AndAnotherOne { fun foo() { ... } } 

निर्माता मापदंडों के लिए नियमित इंडेंटेशन (4 रिक्त स्थान) का उपयोग करें।

औचित्य: यह सुनिश्चित करता है कि मुख्य कंस्ट्रक्टर में घोषित संपत्तियों में समान इंडेंटेशन है जो वर्ग के शरीर में घोषित गुण हैं।

संशोधक

यदि किसी विज्ञापन में कई संशोधक होते हैं, तो हमेशा उन्हें निम्न क्रम में व्यवस्थित करें:

 public / protected / private / internal expect / actual final / open / abstract / sealed / const external override lateinit tailrec vararg suspend inner enum / annotation companion inline infix operator data 

सभी एनोटेशन को संशोधक से पहले रखें:

 @Named("Foo") private val foo: Foo 

यदि आप लाइब्रेरी पर काम नहीं कर रहे हैं, तो निरर्थक संशोधक (उदा। सार्वजनिक) को छोड़ दें।

प्रारूप एनोटेशन

घोषणाओं को आमतौर पर घोषणा से पहले अलग-अलग लाइनों पर रखा जाता है, जिसमें वे संलग्न होते हैं, और एक ही इंडेंट के साथ:

 @Target(AnnotationTarget.PROPERTY) annotation class JsonExclude 

तर्कों के बिना टिप्पणियों को एक पंक्ति में स्थित किया जा सकता है:

 @JsonExclude @JvmField var x: String 

तर्कों के बिना एक एनोटेशन को उसी लाइन पर रखा जा सकता है जो संबंधित घोषणा के अनुसार है:

 @Test fun foo() { ... } 

फ़ाइल एनोटेशन

फाइलों पर टिप्पणी पैकेज के बयान से पहले फाइल पर टिप्पणी के बाद रखी गई है (यदि कोई हो), तो पैकेज से एक खाली लाइन द्वारा अलग किया जाता है (इस तथ्य पर जोर देने के लिए कि वे फ़ाइल पर लक्षित हैं, पैकेज नहीं)।

 /** License, copyright and whatever */ @file:JvmName("FooBar") package foo.bar 

कार्य स्वरूपण

यदि विधि हस्ताक्षर एक पंक्ति पर फिट नहीं होता है, तो निम्न सिंटैक्स का उपयोग करें:

 fun longMethodName( argument: ArgumentType = defaultValue, argument2: AnotherArgumentType ): ReturnType { // body } 

फ़ंक्शन मापदंडों के लिए नियमित इंडेंटेशन (4 रिक्त स्थान) का उपयोग करें।

औचित्य: कंस्ट्रक्टर मापदंडों के साथ संगतता

एक पंक्ति से मिलकर कार्यों के लिए घुंघराले ब्रेसिज़ के बिना एक अभिव्यक्ति का उपयोग करना बेहतर है।

 fun foo(): Int { // bad return 1 } fun foo() = 1 // good 

एकल-पंक्ति अभिव्यक्ति स्वरूपण

यदि एकल-रेखा फ़ंक्शन का शरीर घोषणा के समान रेखा पर फिट नहीं होता है, तो पहली पंक्ति में = चिह्न डालें। 4 स्थानों द्वारा अभिव्यक्ति के शरीर को इंगित करें।

 fun f(x: String) = x.length 

संपत्ति स्वरूपण

केवल पढ़ने योग्य गुणों के लिए, एकल-पंक्ति स्वरूपण का उपयोग करना बेहतर होता है:

 val isEmpty: Boolean get() = size == 0 

अधिक जटिल गुणों के लिए, हमेशा अलग-अलग पंक्तियों में उपयोग और set :

 val foo: String get() { ... } 

आरंभीकरण वाले गुणों के लिए, यदि इनिशलाइज़र बहुत लंबा है, तो बराबर चिह्न के बाद एक लाइन ब्रेक जोड़ें और इनिशियलाइज़ेशन स्ट्रिंग के लिए चार रिक्त स्थान का संकेत दें:

 private val defaultCharset: Charset? = EncodingRegistry.getInstance().getDefaultCharsetForPropertiesFiles(file) 

स्वरूपण नियंत्रण निर्देश

यदि या when नियंत्रण कथन बहु-रेखा में स्थिति है, तो हमेशा कथन के शरीर के चारों ओर घुंघराले ब्रेसिज़ का उपयोग करें। कथन की शुरुआत के सापेक्ष 4 स्थानों द्वारा स्थिति की प्रत्येक बाद की रेखा को इंगित करें। शर्त के समापन कोष्ठकों को एक अलग रेखा पर घुंघराले ब्रेस के साथ रखें:

 if (!component.isSyncing && !hasAnyKotlinRuntimeInScope(module) ) { return createKotlinNotConfiguredPanel(module) } 

औचित्य: स्वच्छ संरेखण और स्थिति शरीर और स्थिति शरीर का स्पष्ट पृथक्करण

else , catch , finally कीवर्ड, साथ ही डू के कीवर्ड के साथ / जबकि एक ही लाइन पर लूप करें जो पिछले समापन कर्ली ब्रैकेट के रूप में है:

 if (condition) { // body } else { // else part } try { // body } finally { // cleanup } 

यदि निर्देशों की शर्तों में कई ब्लॉक शामिल हैं, तो उन्हें खाली लाइन के साथ एक दूसरे से अलग करने की सिफारिश की जाती है:

 private fun parsePropertyValue(propName: String, token: Token) { when (token) { is Token.ValueToken -> callback.visitValue(propName, token.value) Token.LBRACE -> { // ... } } } 

when घुंघराले ब्रेसिज़ के बिना एक ही लाइन पर बयान when तो छोटे ब्लॉक रखें।

 when (foo) { true -> bar() // good false -> { baz() } // bad } 

स्वरूपण विधि कॉल

मापदंडों की एक लंबी सूची का उपयोग करते समय, कोष्ठक के बाद लाइन ब्रेक लगाएं। 4 रिक्त स्थान को इंगित करें और तर्क को एक पंक्ति पर तार्किक रूप से संबंधित करें।

 drawSquare( x = 10, y = 10, width = 100, height = 100, fill = true ) 

पैरामीटर नाम और उसके मान के बीच समान चिह्न के आसपास रिक्त स्थान का उपयोग करें।

एक चेन फंक्शन कॉल को फॉर्मेट करना

जंजीर कॉल का उपयोग करते समय, रखो . या ?. 4 स्थानों में एक इंडेंटेशन वाली नई लाइन पर ऑपरेटर:

 val anchor = owner ?.firstChild!! .siblings(forward = true) .dropWhile { it is PsiComment || it is PsiWhiteSpace } 

श्रृंखला में पहली कॉल में आम तौर पर इसके सामने एक लाइन ब्रेक होना चाहिए, लेकिन यह सामान्य है कि कोड बेहतर तरीके से पढ़ा जाए और यह समझ में न आए।

स्वरूपण लंबोदर भाव

लैम्ब्डा अभिव्यक्तियों में, रिक्त स्थान घुंघराले ब्रेसिज़ के आसपास और तीर के आसपास का उपयोग किया जाना चाहिए जो शरीर से मापदंडों को अलग करता है। यदि कोई कॉल एक एकल लंबो चरित्र को स्वीकार करता है, तो इसे जब भी संभव हो, कोष्ठक के बाहर इस्तेमाल किया जाना चाहिए।

 list.filter { it > 10 } 

एक लैम्ब्डा अभिव्यक्ति के लिए एक लेबल असाइन करते समय, लेबल और शुरुआती ब्रेस के बीच एक स्थान न रखें:

 fun foo() { ints.forEach lit@{ // ... } } 

मल्टी-लाइन लैम्ब्डा एक्सप्रेशन में पैरामीटर नामों की घोषणा करते समय, नामों को पहले लाइन, फिर एरो, और नई लाइन पर फंक्शन बॉडी की शुरुआत में रखें:

 appendCommaSeparated(properties) { prop -> val propertyValue = prop.get(obj) // ... } 

यदि पैरामीटर सूची एक लाइन पर फिट नहीं होती है, तो तीर को एक अलग लाइन पर रखें:

 foo { context: Context, environment: Env -> context.configureEnv(environment) } 

प्रलेखन बनाना

मल्टी-लाइन प्रलेखन का उपयोग करते समय, एक अलग लाइन पर /** डालें, और प्रत्येक बाद की लाइन को एक तारांकन के साथ शुरू करें:

 /** * This is a documentation comment * on multiple lines. */ 

लघु प्रलेखन को एक पंक्ति में रखा जा सकता है:

 /** This is a short documentation comment. */ 

सामान्य तौर पर, परम और रिटर्न टैग का उपयोग करने से बचें। इसके बजाय, पैरामीटर का विवरण शामिल करें और मानों को दस्तावेज़ टिप्पणी में सीधे शामिल करें और जहाँ भी उनका उल्लेख है, पैरामीटर संदर्भ जोड़ें। परम का उपयोग करें और केवल तब लौटें जब एक लंबे विवरण की आवश्यकता होती है जो मुख्य पाठ के अर्थ में फिट नहीं होता है।

 // Avoid doing this: /** * Returns the absolute value of the given number. * @param number The number to return the absolute value for. * @return The absolute value. */ fun abs(number: Int) = ... // Do this instead: /** * Returns the absolute value of the given [number]. */ fun abs(number: Int) = ... 

अनावश्यक निर्माणों से बचना

कोटलिन में कई सिंटैक्टिक निर्माण वैकल्पिक हैं और विकास के माहौल को अनावश्यक के रूप में उजागर करते हैं, आपको अपने कोड को "स्पष्ट" बनाने के लिए उन्हें अपने कोड में उपयोग नहीं करना चाहिए।

कीवर्ड यूनिट का उपयोग करें

फ़ंक्शन में, यूनिट कीवर्ड का उपयोग नहीं किया जाना चाहिए:

 fun foo() { // ": Unit" is omitted here } 

सेमीकोलन

हर अवसर पर अर्धविराम का उपयोग करने से बचें।

स्ट्रिंग पैटर्न

टेम्प्लेट स्ट्रिंग में एक साधारण चर सम्मिलित करते समय घुंघराले ब्रेसिज़ का उपयोग न करें। केवल लंबे भावों के लिए घुंघराले ब्रेसिज़ का उपयोग करें।

 println("$name has ${children.size} children") 

भाषा की विशेषताओं का मुहावरेदार उपयोग

अचलता

उत्परिवर्तित डेटा से पहले अपरिवर्तनीय डेटा का उपयोग करना बेहतर होता है। हमेशा वैरिएबल और प्रॉपर्टीज को val घोषित करें, न कि var , जब तक कि वे वास्तव में नहीं बदलते।

संग्रह बदलने की घोषणा करने के लिए हमेशा Collection संग्रह इंटरफेस ( Collection , List , Set , Map ) का उपयोग करें। हर अवसर पर, संग्रह बनाने के लिए कारखाने के तरीकों का उपयोग करते समय, एक कार्यान्वयन का उपयोग करें जो अपरिवर्तनीय संग्रह लौटाता है:

 // Bad: use of mutable collection type for value which will not be mutated fun validateValue(actualValue: String, allowedValues: HashSet<String>) { ... } // Good: immutable collection type used instead fun validateValue(actualValue: String, allowedValues: Set<String>) { ... } // Bad: arrayListOf() returns ArrayList<T>, which is a mutable collection type val allowedValues = arrayListOf("a", "b", "c") // Good: listOf() returns List<T> val allowedValues = listOf("a", "b", "c") 

: .

.

 // Bad fun foo() = foo("a") fun foo(a: String) { ... } // Good fun foo(a: String = "a") { ... } 

[Type alias]

, , :

 typealias MouseClickHandler = (Any, MouseEvent) -> Unit typealias PersonIndex = Map<String, Person> 

-

-, , it . - .

-

. - , . , - .

( @ ) .

, , boolean , .

 drawSquare(x = 10, y = 10, width = 100, height = 100, fill = true) 

try , if when , return :

 return if (x) foo() else bar() //   ,    if (x) return foo() else return bar() // return when(x) { 0 -> "zero" else -> "nonzero" } //   ,    when(x) { 0 -> return "zero" else -> return "nonzero" } 

if when

if when

 when (x) { null -> ... else -> ... } if (x == null) ... else ... //      

, when .

Boolean?

Boolean? , if (value == true) if (value == false) , if (value ?: false) if (value != null && value) .

filtet , map .. . : forEach ( for null forEach )

, , , .

until ( ):

 for (i in 0..n - 1) { ... } // bad for (i in 0 until n) { ... } // good 

.

\n escape- .

, trimIndent , , trimMargin , :

 assertEquals( """ Foo Bar """.trimIndent(), value ) val a = """if(a > 1) { | return a |}""".trimMargin() 

. , , .

:

• ( )
• ,

. , , , , . API, , . , .

infix , , . : and , to , zip . : add .

infix , .

, , . , , . , , .

 class Point(val x: Double, val y: Double) { companion object { fun fromPolar(angle: Double, radius: Double) = Point(...) } } 

, , .

: , , Kotlin null , null

public /, , Kotlin:

 fun apiCall(): String = MyJavaApi.getProperty("name") 

(package-level class-level) Kotlin:

 class Person { val name: String = MyJavaApi.getProperty("name") } 

, , Kotlin :

 fun main() { val name = MyJavaApi.getProperty("name") println(name) } 

apply / with / run / also / let

Kotlin . , :

• ? , , it , this ( also let ). also , .

 // Context object is 'it' class Baz { var currentBar: Bar? val observable: Observable val foo = createBar().also { currentBar = it // Accessing property of Baz observable.registerCallback(it) // Passing context object as argument } } // Receiver not used in the block val foo = createBar().also { LOG.info("Bar created") } // Context object is 'this' class Baz { val foo: Bar = createBar().apply { color = RED // Accessing only properties of Bar text = "Foo" } } 

• ? , apply also . , with , let run .

 // Return value is context object class Baz { val foo: Bar = createBar().apply { color = RED // Accessing only properties of Bar text = "Foo" } } // Return value is block result class Baz { val foo: Bar = createNetworkConnection().let { loadBar() } } 

• null ? , apply , let run . , with also .

 // Context object is nullable person.email?.let { sendEmail(it) } // Context object is non-null and accessible directly with(person) { println("First name: $firstName, last name: $lastName") } 

API:

• ( API)
• ( )
• KDoc public api, , /