เริ่มทำ Code Review ด้วย ktlint กันเถอะ

เนื่องด้วยทำงานบริษัท startup ที่เปลี่ยนแปลง requirement ได้บ่อย จนเดฟไม่มีเวลาทำ Unit Test แล้วไม่รู้จะทำ Code Review ยังไงอีก อ่ะงั้นเราค่อยๆเริ่มทำสักอย่างก็แล้วกัน

https://ktlint.github.io/

แน่นอนว่า Android Kotlin Developer นั้น มักจะใช้ ktlint ทำ Code Review กัน อ่ะเรามาลองทำความรู้จักและใช้งานกันเถอะนะ

รู้จักน้อง ktlint กันเถอะ!

Lint คือ ตัวที่ช่วยตรวจสอบโค้ดของเรา เพื่อแก้ไขโครงสร้างของโค้ด โดยที่ไม่ต้อง execute app ของเราหรือเขียน test case แต่ละปัญหาจะถูกระบุไว้โดย tool ตัวนี้โดยบอก description และ level ของปัญหานั้นๆที่พบ ทำให้เราแก้ไขปัญหาได้ไวขึ้นนั่นเอง

หลายๆคนคงจะทราบกันอยู่แล้ว ว่า Android Studio สามารถทำ lint check ได้ ทำง่ายๆโดยผ่าน command line เลยหล่ะ

./gradlew lint

ผลที่ได้จาก Android Studio จะมีเรื่อง lint และมีหัวข้ออื่นๆอีก เช่น Correctness, Security, Performance, Usability, Accessibility, Internationalization และมี Disabled Checks ด้วยแหะ

อันนี้เป็นตัวอย่างจากที่เราได้มา ในส่วนของการที่ต้องอัพเดต dependency ต่างๆ แคปแค่นี้ก็พอเนอะ

ดังนั้น ktlint นั้น ย่อมาจาก Kotlin Linter ก็คือ tool ที่ช่วยตรวจสอบ Kotlin Code Style ของเรา ให้ถูกสุขอนามัยในแบบฉบับของ Kotlin นั่นเอง

มาลองใช้ ktlint กันเถอะ!

วิธีการลงมี 3 แบบ นั่นก็คือ Command Line, Maven และ Gradle

ในที่นี้จะเป็น Gradle นะ ใส่ไปใน build.gradle ของ module :app

ในนี้จะมี task 2 ตัวเพิ่มมานั่นคือ

• ktlint เอาไว้ตรวจว่าโค้ดของเรานั้นเป็นไปตาม Kotlin Code Style หรือไม่ การใช้งานนั้นสุดแสนจะง่ายมาก นั่นก็คือ ./gradlew ktlint นั่นเอง
• ส่วน ktlintFormat เป็นการเปลี่ยนโค้ดบางไฟล์ที่ยังไม่ถูกหลักอนามัย ให้ถูกต้องนั้นเอง โดยไม่ต้องแก้มือ อารมณ์แบบซักเครื่องอ่ะ ไม่ต้องใช้แรงมือ การใช้งานคือ ./gradlew ktlintFormat จากนั้นเราก็นำไฟล์ที่ทำการแก้แล้ว ไป commit และ push ลง repo ของเราได้เลยจ้า

ส่วน Rule ในเว็บเขามี 10 ข้อด้วยกัน ที่ทำการ Code Inspection

Code Inspection เป็นการตรวจสอบ format ของโค้ด ตามที่ทีมกำหนดไว้

• indent ห่างกัน 4 spaces : อันนี้อาจจะเหวอๆ เนื่องจาก data class เราจะให้ตัวแปรใน object นั้นอยู่ตรงเส้นกัน
• ไม่มี Semicolons : แหงหล่ะ เราเขียน Kotlin นี่เนอะ ยกเว้นกรณีที่เขียนบรรทัดเดียวกันแล้วอยากจะแยกส่วนคำสั่งที่ต้องทำในบรรทัดนั้นๆ
• ไม่มีการ import library ที่มี * ต่อท้ายแบบเอาทั้งหมดก้อน ทั้งๆที่ใช้ตัวเอง และมีการ import library เท่าที่ตัวเองใช้เท่านั้น
• ไม่มีบรรทัดว่างต่อเนื่องระหว่างกัน : มีแซะด้วยว่าไม่ใช่ python นะเตง
• แน่นอนว่าห้ามมี space ท้ายบรรทัด : โดนกันเยอะแน่แบบไม่ได้ตั้งใจ
• ห้าม return เป็น Unit
• ห้ามใส่ {} เปล่าๆ ให้เอาออก สำหรับ empty class
• ใช้ String template
• การเรียงลำดับของ modifier ก็คือเรียงพวก Modifiers ให้ถูกต้อง เช่น suspend ต้องอยู่หน้าสุด สามารถเข้าไปอ่านเพิ่มเติมได้ที่

Coding Conventions

• ระยะห่างที่สอดคล้องกัน จากตัวอย่าง เช่น บางคนชอบให้ = วางตรงกันตอนประกาศตัวแปร จริงๆควรเว้นแค่ 1 space หน้าหลัง = ก็พอ พวกเครื่องหมายทางคณิตศาสตร์ก็เช่นกัน บางคนชอบวางติดๆกัน จริงๆควรห่าง 1 space เช่นกัน, หลัง if ก็ห่าง 1 space เช่นกัน และอีกหลายตัว ขอแคปจากหน้า Document ของ ktlint ให้ดูประกอบด้วยกว่าเนอะ

https://ktlint.github.io/#rule-spacing

อันไหนที่เจอบ่อยๆในโปรเจกเรากันนะ

• Unexpected indentation (expected 8, actual 23)
• Missing newline before “)”
• Parameter should be on a separate line (unless all parameters can fit a single line)
• Trailing space(s)
• Missing spacing before “{“
• Unexpected blank line(s) before “}”
• Imports must be ordered in lexicographic order without any empty lines in-between
• Unused import
• Wildcard import (cannot be auto-corrected)
• Unexpected spacing before “:”
• Missing spacing after “/”
• Missing space after //
• Needless blank line(s)
• Line must not begin with “&&”

ความงงคือ มันก็ทำงานบอกว่าอันไหนผิดหลักอนามัย แต่ดัน build failed ตรงนี้ อย่างงง

เพราะเรา apply plugin: “java” แล้วมันไม่สามารถ build ได้ พอไม่ใส่มันทำงานได้นะ ทั้งตอน ktlint และ ktlintFormat นะ

เราสามารถเอาไปใส่ใน CI ได้นะ แต่ขอแยกไปอีกบล็อกแล้วกันเนอะ

สุดท้ายฝากร้านกันสักนิด ฝากเพจด้วยนะจ๊ะ