آموزش برنامه‌نویسی کاتلین: قواعد کدنویسی کاتلین

در این مطلب برخی از قواعد کدنویسی کاتلین را معرفی می‌کنیم.

قواعد نامگذاری

هر جایی در مورد قواعد نامگذاری ابهام داشتید به قوانین نامگذاری جاوا رجوع کنید:

  • برای نام‌ها از «کمل کیس» استفاده کنید (از زیرخط یا underscore در نام‌ها استفاده نکنید)
  • نوع‌ها با حرف بزرگ شروع می‌شوند.
  • متدها و ویژگی‌ها با حرف کوچک شروع می‌شوند.
  • از چهار حرف فاصله برای تو رفتگی استفاده کنید.
  • بهتر است تابع‌های عمومی همانند مستندات کاتلین، مستندات داشته باشند.

دونقطه

در جایی که دونقطه جدا کننده نوع و نوع مافوق (در ارث بری) باشد، قبل از دونقطه از یک فاصله استفاده کنید و در جایی که جداکننده بین شی و نوع باشد، هیچ حرف فاصله‌ای قبل از دو نقطه قرار ندهید:

interface Foo<out T : Any> : Bar {
    fun foo(a: Int): T
}

لامبدا

در عبارت‌های لامبدا، در اطراف آکولاد از فاصله استفاده کنید.همانطور در اطراف پیکانی که پارامترها را از بدنه تابع جدا می‌کند. لامبدا باید تا حد امکان بیرون از پرانتز قرار داده شود:

list.filter { it > 10 }.map { element -> element * 2 }

در لامبداهایی ساده و غیر تو در تو توصیه می‌شود که از it به جای تعریف صریح پارامتر استفاده کنید. در لامبداهای تو در تو و دارای پارامتر، بهتر است پارامترها را صریح تعریف کنید.

فرمت سرآیند کلاس

کلاس‌هایی با تعداد آرگومان کم می‌توانند در یک خط نوشته شوند:

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 {
    // ...
}

پارامترهای سازنده می‌توانند از تورفتگی معمولی یا دو برابر استفاده کنند.

Unit

اگر نوع بازگشتی تابع Unit باشد بهتر است Unit حذف شود:

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

}

توابع در برابر ویژگی‌ها

در برخی مواقع می‌توان توابع بدون آرگومان و ویژگی‌های فقط خواندنی را به جای یکدیگر به کار برد. با این که از نظر معنایی این دو شبیه هم هستند، برای انتخاب یکی به جای دیگری قواعدی وجود دارد.

در مواقعی که الگوریتم اصلی ویژگی‌های زیر را داشته باشد، ویژگی‌ها بر تابع‌ها برتری دارند:

  • هیچ استثنایی پرتاب نکند
  • پیچیدگی O(1) داشته باشد
  • محاسبه آن ساده باشد (یا در اولین اجرا کش شود)
  • در فراخوانی‌های متفاوت، همیشه یک مقدار را برگرداند

منبع: مستندات رسمی سایت کاتلین

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail




پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *