1. 스타일 가이드 적용하기
이 스타일 가이드에 따라 IntelliJ 포맷터를 구성하려면 Kotlin 플러그인 버전 1.2.41 이상을 설치하고,
설정 | 편집자 | 코드 스타일 | Kotlin의 오른쪽 위 모서리에있는 "Set from ..."링크를 클릭하고 메뉴에서 "Predefined style / Kotlin style guide"를 선택
스타일 가이드에 따라 코드가 포맷되었는지 확인하려면 검사 설정으로 이동하여 "Kotlin | 스타일 문제 | 프로젝트 설정에 따라 파일 형식이 지정되지 않았습니다"검사를 활성화
스타일 지침서에 설명 된 다른 문제 (예 : 명명 규칙)를 확인하는 추가 검사는 기본적으로 사용됩니다.
** IntelliJ Style Guide 적용:
To configure
Preference | Editor | Code Style | Kotlin > "Set from..." > "Predefined style / Kotlin style guide"
To verify (코딩 가이드에 따라 되었는지)
Preference | Editor | Code Style | Inspections | Kotlin > File is not formatted according to project settings 체크
2. Source Code Organization
2.1 디렉토리 구조
혼합 언어 프로젝트에서 Kotlin 소스 파일은 Java 소스 파일과 동일한 소스 루트에 있어야하며 동일한 디렉토리 구조를 따라야 한다.
(각 파일은 각 패키지 명령문에 해당하는 디렉토리에 저장되어야합니다).
순수한 Kotlin 프로젝트에서 권장되는 디렉토리 구조는 공통 루트 패키지가 생략 된 패키지 구조를 따라야 한다.
** 공통 패키지명을 뺀 나머지 패키지 구조를 따른다.
** 공통 패키지: com.example.kotlin = root 디렉토리
** 서브 패키지: com.example.kotlin.foo.bar = foo/bar 디렉토리
2.2 소스파일명
Kotlin 파일에 하나의 클래스 (관련 최상위 수준 선언이 포함될 수 있음)가 포함 된 경우 해당 이름은 클래스 이름과 동일해야하며,
.kt 확장자가 추가되어야 한다.
파일에 여러 클래스 또는 최상위 레벨 선언 만 포함되어 있으면,
파일에 포함 된 것을 설명하는 이름을 선택하고 이에 따라 파일의 이름을 지정해야 한다.
대문자 첫 글자가있는 낙타 혹(camel humps)을 사용하십시오 (예: ProcessDeclarations.kt )
파일의 이름은 파일의 코드가하는 것을 설명해야 한다. 따라서 파일 이름에 "Util"과 같은 의미없는 단어를 사용하지 말자.
2.3 소스파일 구성
같은 선언문이 의미론적으로 서로 밀접하게 관련되어 있고,
파일 크기가 적절한 수준으로 유지되는 한 (수백 줄을 초과하지 않는 한),
여러 선언 (클래스, 최상위 함수 또는 속성)을 동일한 Kotlin 소스 파일에 배치하는 것이 좋다.
특히 이 클래스의 모든 클라이언트와 관련된 클래스의 확장 함수를 정의 할 때,
클래스 자체가 정의 된 동일한 파일에 이 함수를 넣는 것이 좋다.
특정 클라이언트에 대해서만 의미가있는 확장 기능을 정의 할 때, 해당 클라이언트의 코드 옆에 확장 기능을 지정하자.
"Foo"의 모든 확장"을 보관할 파일 만 만들지 말자.
2.4 클래스 레이아웃
일반적으로 클래스의 내용은 다음 순서로 정렬하자.
속성선언 및 Initializer 블록
보조 생성자
메소드 선언
Companion Object(동반자 객체)
Kotlin은 Java 명명 규칙을 따르고 있다.
특히, 패키지 이름은 항상 소문자이며 밑줄은 사용하지 않는다. (org.exmaple.myproject)
일반적으로 권장하지는 않지만, 여러단어를 사용해야 하는 경우에는 간단히 병합하거나 낙타 혹을 사용한다. (org.exmaple.myProject)
클래스와 객체의 이름은 대문자로 시작하여 낙타 혹을 사용한다.
open class DeclarationProcessor { ... } object EmptyDeclarationProcessor : DeclarationProcessor() { ... } |
3.1 Function names
함수, 속성 및 지역 변수의 이름은 소문자로 시작하여 낙타 혹을 사용하며 밑줄은 사용하지 않는다.
fun processDeclarations() { ... } |
** 예외사항: 클래스의 인스턴스를 만드는데 사용되는 팩토리 함수는 생성되는 클래스와 동일한 이름을 가질 수 있다.
abstract class Foo { ... } class FooImpl : Foo { ... } fun Foo(): Foo { return FooImpl(...) } |
3.2 Names for test methods
** backtick = `
테스트에서 backtick(`)으로 둘러싸인 공백을 포함한 메소드 이름을 사용할 수 있다.
메소드 이름의 밑줄 또한 테스트 코드에서 사용할 수 있다.
class MyTestCase { @Test fun `ensure everything works`() { } @Test fun ensureEverythingWorks_onAndroid() { } } |
3.3 Property names
상수는 밑줄을 포함한 대문자로 구분된 이름을 사용해야 한다.
상수: const로 표시된 property, immutable 데이터를 보유하고 있는 custom get 함수가 없는 최상위 또는 객체 val property
const val MAX_COUNT = 8 val USER_NAME_FIELD = "UserName" |
behavior 또는 mutable 데이터를 보유하고 있는 최상위 또는 객체 property의 이름은 일반적으로 낙타 혹 표현을 사용해야 한다.
val mutableCollection: MutableSet<String> = HashSet()
|
싱글톤 객체에 대한 참조를 보유하고 있는 property의 이름은 객체의 선언(대문자로 시작하여 낙타 혹을 사용)과 동일한 명명 스타일을 사용해야 한다.
val PersonComparator: Comparator<Person> = ... |
열거형 상수(enum constants)인 경우,
대문자로 구분된 이름 또는 대문자로 시작하는 일반적인 낙타 혹을 사용해야 한다.
enum class Color { RED, GREEN } |
3.4 Names for backing properties
클래스가 개념상으로는 동일하지만 하나는 public API의 일부이고, 다른 하나는 구현 세부정보가 있는 경우 private property 이름은 접두사로 밑줄을 사용한다.
class C { private val _elementList = mutableListOf<Element>() val elementList: List<Element> get() = _elementList }
|
3.5 Choosing good names
클래스의 이름은 일반적으로 클래스가 무엇인지 설명하는 명사 또는 명사구(List, PersonReader)이다.
메소드의 이름은 보통 메소드의 기능을 알려주는 동사 또는 동사구(close, readPersons)이다.
또한 객체의 변화 또는 새로운 객체의 반환의 의미가 포함되어야 한다.
예를 sort는 collection 객체를 정렬하는 것이고, sorted는 정렬된 collection 사본의 반환을 의미한다.
이름은 entity(클래스, 메소드, 프로퍼티 등)의 목적이 무엇인지 명확해야 하므로 의미없는 단어(Manager, Wrapper 등)를 사용하지 않는 것이 좋다.
선언 이름의 일부가 약어인 경우,
약어가 두문자인경우(IOStream 등) 대문자로 표기하고 더 긴 경우(XmlFormatter, HttpInputStream 등) 첫번째 문자만 대문자로 사용
4. Formatting
대부분의 경우 Kotlin은 Java 코딩 규칙을 따른다.
들여쓰기는 탭을 사용하지 않고 4칸을 지정하여 사용
중괄호의 경우 구성 시작 부분의 끝줄에 여는 중괄호를 입력하고,
열린 구성과 수직적으로 정렬된 별도의 줄에 닫는 중괄호를 입력한다.
if (elements != null) { for (element in elements) { // ... } } |
** Kotlin에서 세미콜론은 선택사항이므로 바꿈이 매우 중요하다.
4.1 Horizontal whitespace
binary operator 주위에 공백을 넣자. (a + b)
예외: "range to" operator 주위에 공백을 넣지 말아야 한다. (0...i)
unary operator 주위에도 공백을 넣지 말아야 한다.(a++)
control flow keyword(if, when, for and while)와 열린 괄호 사이에 공백을 넣자.
기본 생성자 선언, 메서드 선언, 메서드 호출에서 여는 괄호 앞에 공백을 넣지 말아야 한다.
class A(val x: Int) fun foo(x: Int) { } fun bar() { foo(1) }
|
(, [ 뒤에 또는 ), ] 전에 공백을 넣지 말아야 한다.
. 또는 ?. 주위에 공백을 넣지 말아야 한다.
|
주석 // 뒤에 공백을 넣자.
// This is a comment |
5. Documentation comments
6. Avoiding redundant constructs
7. Idiomatic use of language features
8. Coding conventions for libraries
