Kotlin Coding Conventions sẽ khác với mặc định của IntelIJ IDEA như thế nào?

Từ trước tới nay, IDE thường được tích hợp sẵn những bộ định dạng code sẵn giúp cho việc code của chúng trở nên sạch sẽ và đồng bộ nếu những ta làm việc trong những dự án có nhiều thành viên.

Thật không may, bộ định dạng code được tích hợp trong InteliJ IDEA đã hoạt động rất lâu trước khi tài liệu Kotlin Coding Conventions của Kotlin được phát hành. Vì thế sẽ có đôi chút khác nhau giữa Kotlin Coding Conventions và formating mặc định của InteliJ IDEA

Những điểm khác nhau giữa "Kotlin Coding Conventions" và "Intelij IDEA ddefault code style"

Sự thay đổi đáng chú ý nhất là trong việc thụt đầu dòng tiếp túc.

Đôi khi chúng ta sẽ có những đoạn code viết rất dài và chúng bị quá số lượng kí tự trên một dòng code(thường là 100 kí tự). Vì thế, để đánh dấu những dòng code chưa kết thúc, ở dòng tiếp theo chúng ta sẽ thụt lề đầu dòng 2 lần(2 lần tab).

Đây là một quy tắc rất đơn giản và hợp lý, tuy nhiên với cấu trúc của Kotlin, chúng sẽ khó xử hơn rất nhiều nếu chúng ta định dạng như vậy. Vì thế, Kotlin đã khuyến khích chúng ta chỉ sử dụng 1 lần thụt lề đầu dòng thay vì 2 như cũ.

Bắt đầu từ đâu khi áp dụng code style mới

Sẽ thật là dễ nếu chúng ta bắt đầu một dự án mới và áp dụng ngay kiểu định dạng mới vì khi ấy sẽ không có những đoạn code được định dạng theo cách cũ.

Đó là lý do tại sao bắt đầu từ phiên bản 1.3, Plugin IntlinJ của Kotlin tạo ra các dự án mới với định dạng từ tài liệu Code Conventions được bật theo mặc định.

Trong trường hợp khác, với những dự án đã có và đang phát triển, việc thay đổi định dạng là một nhiệm vụ đòi hỏi cao hơn nhiều, và có lẽ nên được bắt đầu bằng việc thảo luận về tất cả các cảnh báo với nhóm.

Nhược điểm chính của việc thay đổi kiểu mã trong một dự án hiện tại là tính năng VCS đổ lỗi / chú thích sẽ chỉ ra các cam kết không liên quan thường xuyên hơn. Mặc dù mỗi VCS có một số cách để giải quyết vấn đề này, điều quan trọng là phải quyết định xem một phong cách mới có đáng để nỗ lực hay không. Việc thực hành phân tách định dạng lại cam kết từ các thay đổi có ý nghĩa có thể giúp ích rất nhiều cho các cuộc điều tra sau này.

Ngoài ra, việc di chuyển có thể khó hơn đối với các nhóm lớn hơn vì cam kết nhiều tệp trong một số hệ thống con có thể tạo ra xung đột hợp nhất trong các nhánh cá nhân. Và trong khi mỗi giải quyết xung đột thường là tầm thường, vẫn nên biết liệu có các nhánh tính năng lớn hiện đang hoạt động hay không.

Nói chung, đối với các dự án nhỏ, Kotlin khuyên chúng ta nên chuyển đổi tất cả các tệp cùng một lúc.

Đối với các dự án vừa và lớn, quyết định có thể khó khăn. Chúng ta có thể quyết định chuyển định dạng dần theo module hoặc tiếp tục di chuyển dần dần cho các tệp đã sửa đổi.

Chuyển đổi sang kiểu code mới

Việc chuyển đổi Kotlin Coding Conventions có thể được thực hiện bằng cách sửa đổi định dạng mặc định IDEA , chúng ta sẽ vào File > Settings > Editor > Code Style > Kotlin Sửa Continuation Indent từ 8 -> 4

Để chia sẻ những sửa đổi của mình cho các thành viên trong team, chúng ta cần phải giao thác thư mục .idea/codeStyle thành VCS

Trong những trường hợp một hệ thống xây dựng bên ngoài được sử dụng cho việc thiết lập project, và nó đã được quyết định không chia sẻ thư mục .idea/codeStyle, chúng ta có thể thêm những thuộc tính cần thiết trong Gradle, Maven để thay đổi Kotlin Coding Conventions

In Gradle

Thêm thuộc tính kotlin.code.style=official vào file gradle.properties tại project rôt và ủy thác nó sang VCS.

In Maven

Thêm thuộc tính kotlin.code.style official vào file pom.xml

<properties>
  <kotlin.code.style>official</kotlin.code.style>
</properties>

Cảnh báo: có bộ tùy chọn kotlin.code.style có thể sửa đổi lược đồ code style trong quá trình nhập dự án và có thể thay đổi cài đặt kiểu mã.

Sau khi cập nhật cài đặt code style, hãy kích hoạt "Refactor Code" trong chế độ xem dự án trên phạm vi mong muốn.

Để di chuyển dần dần, có thể kích hoạt kiểm tra "File is not formatted according to project settings". Nó sẽ làm nổi bật những nơi cần được định dạng lại. Sau khi bật tùy chọn "Apply only to modified files", sự kiểm tra sẽ chỉ hiển thị các sự cố định dạng trong các tệp đã sửa đổi. Những tập tin như vậy có lẽ sẽ sớm được cam kết.

Một số điều cần lưu ý với Kotlin style của Google

Dấu ngoặc nhọn

Dấu ngoặc nhọn không cần thiết sử dụng cho những nhánh của câu lệnh when và phần thân của câu lệnh if nếu không có nhánh else if/else nào khác hoặc là chúng có thể nằm trên 1 dòng

if (string.isEmpty()) return

when (value) {
    0 -> return
    // …
}

Trong những trường hợp khác đều cần phải có dấu ngoặc nhọn, thậm chí nội dung của chúng là trống rỗng hoặc chỉ chứa duy nhất một câu lệnh

if (string.isEmpty())
    return  // WRONG!

if (string.isEmpty()) {
    return  // Okay
}

Đối với những block trống hay block-like, cần phải tuân theo phong cách K&R

try {
    doSomething()
} catch (e: Exception) {} // WRONG!

try {
    doSomething()
} catch (e: Exception) {
} // Okay

val value = if (string.isEmpty()) 0 else 1  // Okay

val value = if (string.isEmpty())  // WRONG!
                0
            else
                1
                
val value = if (string.isEmpty()) { // Okay
    0
} else {
    1
}

Kiểu dữ liệu trả về

Nếu một thân hàm biểu thức hoặc một bộ khởi tạo thuộc tính là một giá trị vô hướng hoặc kiểu trả về có thể được suy ra rõ ràng từ thân thì nó có thể được bỏ qua.

override fun toString(): String = "Hey"
// becomes
override fun toString() = "Hey"

private val ICON: Icon = IconLoader.getIcon("/icons/kotlin.png")
// becomes
private val ICON = IconLoader.getIcon("/icons/kotlin.png")

Tên package

Tên package đều là chữ thường, với các từ liên tiếp được ghép đơn giản với nhau (không có dấu gạch dưới).

// Okay
package com.example.deepspace
// WRONG!
package com.example.deepSpace
// WRONG!
package com.example.deep_space

Tham khảo

[1] https://kotlinlang.org/docs/reference/code-style-migration-guide.html [2] https://developer.android.com/kotlin/style-guide