Skip to content

NUTEE Android Coding Style

Jump to bottom
Jinsu Park edited this page Jul 27, 2020 · 4 revisions

Android Coding Style

해당 코딩 스타일은 먼저 만들어진 프로젝트에서는 적용되어있지 않으며,

추후 리펙토링을 통해 해당 스타일을 맞춰갈 생각입니다.

1. Kotlin Language Rules

Kotlin 코드 스타일의 규칙을 따른다.

1.1 Import의 경우 전체를 다 표시할 것

2. Code/Comment Rule

2.1 기본 규칙

package, import, class 또는 인터페이스 순으로 기술하고 각 블럭은 빈줄로 구분한다.

페키지와 파일의 이름은 그 구분을 명확하게 할 수 있는 이름으로 전부 소문자로 작성한다.

띄어쓰기가 필요할경우 _를 사용한다.

해당 class/interface 위에는 다음과 같은 내용을 기술한다.

/*
 * Created by <github id>
 * DESC: <설명>
 */

ex)
/*
 * Created by jinsu4755
 * DESC: 회원가입 Activity의 이메일 인증 Fragment
 */

클래스와 함수명은 반드시 그 의도를 명확하게 구분할 수 있는 이름으로 만든다.

함수 사용시 그 의도가 명확하지 않은경우 간단하게 주석으로 의도를 기술한다.

혹은 함수 내부에서 명확하지 않은 부분은 주석으로 명확한 의도를 기술한다.

/* 이름으로 의도파악이 가능한 함수
 * 사용자의 게시물이 없음을 보이게 설정하는 함수
 */

private fun setVisibleInEmptyUserPostView(){
    cl_empty_user_post.visibility = View.VISIBLE
}



/* 함수 내부 의도파악이 안되는 경우*/
override fun onActivityResult(
    requestCode: Int,
    resultCode: Int, 
    data: Intent?
) {
	super.onActivityResult(requestCode, resultCode, data)
    
    //이미지를 선택하고 결과가 들어온경우 
	if (requestCode == REQUEST_CODE_PICK_IMAGE &&
        resultCode == Activity.RESULT_OK && 
        data != null
    ){
        //...
    }

Static 처리가 필요한 변수/함수는 반드시 companion object에 선언한다.

companion object{
    private const val SPLASH_DELAY:Long = 1000 // 1 seconds
}

2.2 특별한 경우가 아닌이상 각 함수는 40줄 이상 작성하지 않는다.

함수가 40줄이 넘지 않도록 작성하며, 40줄을 넘긴경우 설계가 잘못된 것일 수 있음을 검토.

2.3 Define Fields in Standard Place

Fields 선언은 표준위치를 지킨다.

2.4 TODO, FIXME 주석문 이용

단기 처방 및 완벽하지 않은 해결책일 경우 해당 주석문을 사용하자.

2.5 메소드 인자수 제한

메소드 인자수는 최대 3개로 제한한다.

그럼에도 반드시 3개 초과 전달시 data class 를 이용한다.

3개도 줄일 수 있다면 줄이도록 노력한다.

2.6 한줄에는 하나의 . 만 허용

디미터의 법칙을 지키기.

한줄에는 하나의 .만을 사용할 것.

희망 사항(객체지향 생활 체조 규칙 지키기)

3.로깅(Log)

로깅은 성능에 영항을 준다. 로깅하기 전에 먼저, 로그 레벨 이해 필수.

  • ERROR: 항상 기록되는 레벨, 치명적 상황을 기록할때 사용하며 항상 기록되므로 조심스럽게 사용한다.
  • WORNING: 항상 기록되는 레벨, 심각한 상황을 기록, 사용자가 인식할 수 있는 오류 결과가 나타나고, 사용하던 데이터가 날아가고, 새로운 버전의 앱을 다운 받기 전에는 복구가 안될 경우 사용
  • INFORMATIVE: 항상 기록되는 레벨, 오류는 아니지만 모두가 알아야하는 대단한 경우 기록한다.
  • DEBUG: 디버그 모드에서만 기록되는 레벨, 디버깅 과정에서 관련 추가 정보를 기록할때 사용, 반드시 if문 안에 구현한다.혹시나, 다른 대안으로 리펙토링을 통해 logging 기능을 밖으로 빼는 방법을 생각해보기도 하는데 (re-factoring out), 이는 좋은 생각이 아니다. 왜냐하면, String 파라미터가 전달되면서 불필요한 String 생성이 발생하기 때문임.
  • VERBOSE: 뭐든 로깅해도 되는 레벨 이지만, 디버깅 레벨 처럼 반드시 if구문내에 구현해야 함. 아니면 배포전에 아예 없애버리던가. 주로, 로깅보다는 그냥 필요 정보를 로깅할때 사용한다.

사용

  • (VERBOSE level 이 아닐경우) 하나의 모듈 내에 있는 하나의 function chain 내에서 오류는 가능한 한번만 보고 되어야 한다. method overloading 방식으로 methodA(param1) 가 methodA(param1, param2)를 호출하면 error는 methodA(param1, param2) 에서만 기록하자.
  • 반복되거나 동일한 작업이 예상되는 것은 일정한 조건을 걸어서 로깅해라. 이를 테면, onTouchEvent 내에 로깅할때
  • 네트웍 단절 상태등은 충분히 예상되는 내용이다. debug verbose 이상의 로깅을 하지 말것.
  • 다른 앱에서 접근가능한 파일시스템 용량 초과 같은 이슈는 INFORMATIVE 이하 레벨로 검증 되지 않은 소스로부터 들어오는 잘못된 데이터 입력등의 이슈는 DEBUG 이하로 작성할 것.
  • Log.v() 는 배포버전에서도 컴파일 된다. 레벨에 따라 로깅이 안될 뿐이지. 따라서 반드시 if 구문안에서 String을 처리해야함.
  • 모든 로깅은 간결하고 누구나 쉽게 이해할 수 있어야 한다. 작성자만 알아볼 수 있게 하지 말 것. (DEBUG level 이상의 로깅의 경우)
  • 가능한 한줄로 표현되게끔 해주세요. 너무 길지도 않게.
  • 작업 성공 여부 같은 것은 VERBOSE 외에선 사용하지 말 것.
  • 검사나 분석을 위한 임시 로깅은 반드시 DEBUG or VERBOSE level 에서만 작성할 것.
  • 로깅으로 개인정보 등 보안 정보가 유출되지 않도록 각별히 신경 쓸것.
  • println()등은 사용하지 말것. 가능하면 Log를 사용할 것.
  • 로그가 로그를 만들게 하지 말자.

​

Clone this wiki locally