Convention

🤗 Naming

파일명

• LAYOUTS : WHAT_WHERE.XML / e.g. activity_main.xml
• STRINGS : WHERE_DESCRIPTION / e.g. main_intro, all_done
• DRAWABLES : WHERE_DESCRIPTION_SIZE / e.g. main_background
• IDS : WHAT_WHERE_DESCRIPTION / e.g. linearylayout_main_fragmentcontainer
• DIMENSIONS : WHAT_WHERE_DESCRIPTION_SIZE / e.g. keyline_all_text
• Fagment는 PascalCase로 작성한다. / e.g BookFragment

변수명

• 변수명은 기본적으로 camelCase를 사용한다.
• 가능한 명사를 사용한다.
• 복수의 경우 복수형 명사를 사용한다.
• boolean 형을 갖는 변수는 앞에 is를 붙인다.
• 약어를 사용하지 않는다.

함수명

• 함수명은 기본적으로 camelCase를 사용한다.
• 가능한 동사를 사용한다.
• 함수명을 축약하지 않는다.
• boolean형을 return하는 함수는 앞에 check를 붙인다.

🙄 Issue Conventions

• Issue 내용은 Todo-List 형식으로 작성한다.

👊 Commit Message Conventions

• 커밋 시 아래 규칙을 참고해 메세지를 작성하자, 영어로 작성할 필요는 없다.

• issue-number는 Github의 issue를 발급하고, 생성된 번호를 사용한다.

[#{issue-number}] feat - (feature)
[#{issue-number}] fix - (bug fix)
[#{issue-number}] refactor - (split package)
[#{issue-number}] docs - (documentation)
[#{issue-number}] style - (formatting, missing semi colons, …)
[#{issue-number}] test - (when adding missing tests)

😾 Github branching

• master
• dev
• feature/{issue-number}-{desc..}
• branch는 camelCase로 작성한다.
• Pull Request는 Merge 전 Reviewer의 approve가 필요하다.
• feature -> dev -> main

👶 Code

• Android Lint를 활용한다.
• 버그가 있으면 커밋할 수 없다.
• import를 정규화한다.

import foo.* (x)
import foo.bar (o)

• 변수 범위는 명확하게 제한한다.
• 예외를 무시할 경우 주석으로 이유를 남긴다.
• 들여쓰기는 4칸으로 한다.