Follow Field Naming Conventions
가. Non-public, non-static field 는 m으로 시작
예)
private int mPrivate;
int mPackagePrivate;
protected int mProtected;
나. Static field 는 s로 시작
예) private static MyClass sSingleton;
다. 나머지는 소문자로 시작.
예) public int publicField;
라. Public static final fields (상수) 는 모두 대문자로 ALL_CAPS_WITH_UNDERSCORES.
예) public static final int SOME_CONSTANT = 42;
public class MyClass {
public static final int SOME_CONSTANT = 42;
public int publicField;
private static MyClass sSingleton;
int mPackagePrivate;
private int mPrivate;
protected int mProtected;
}
시작 중괄호는 "{" 따로 한줄을 차지하지 않는다.
class MyClass {
int func() {
if (something) {
// ...
} else if (somethingElse) {
// ...
} else {
// ...
}
}
}
if (condition) body();
TODO 주석문 또는 FIXME 주석문을 사용 할 것.
단기처방이나, 완벽하지 않은 해결책인 경우에는 반드시 TODO or FIXME주석문을 기입할 것.
// TODO: UrlTable2
또는
// FIXME: flag
Activity 개발 시 주의 사항
context를 별도 멤버로 선언하고 관리하지 않도록 하자.
context가 필요하면 getContext() 를 사용하자.
잘못된 사례
아래 예시는 잘못된 예시입니다.
public class MyActivity extends Activity {
private Context mContext = null;
...
...
protected void onCreated(Bundle savedInstanceState){
mContext = this;
}
JavaTests Style Rules
테스트 방법 명명 규칙 준수
Test Method 의 이름을 설계할 때, test case를 "_" 뒤에 붙여줄 수 있다.
예)
testMethod_specificCase1 testMethod_specificCase2
void testIsDistinguishable_protanopia() {
ColorMatcher colorMatcher = new ColorMatcher(PROTANOPIA)
assertFalse(colorMatcher.isDistinguishable(Color.RED, Color.BLACK))
assertTrue(colorMatcher.isDistinguishable(Color.X, Color.Y))
}
로깅(Log)은 간결하게.
로깅은 성능에 지대한 영향을 준다.
로깅하기 전에 먼저, 로그 레벨을 이해하자.
ERROR 레벨: 항상 기록되는 레벨, 뭔가 치명적인 상황을 기록한다.
따라서 조심스럽게 사용해야 한다. 먼가 치명적인 상황을 기록한다.
예를 들어 어떤 데이터를 직접 삭제하거나, 앱을 지우거나, 폰을 싹 밀어버리거나 하기 전에는 복구가 안되는 상황을 사용자가 직면해야 할때만 기록하고, (가능하면)통계수집 서버에 통보하도록 하자.
WARNING 레벨: 항상 기록되는 레벨, 심각한 상황을 기록한다.
심각한 상황을 기록한다.
예를 들어 사용자가 인식할 수 있는 오류결과가 나타나고, 사용하던 데이터(다운로드 중인 데이터 등등)가 날아가버리고,
사용자가 앱 혹은 폰을 리부팅하거나, 화면을 죽이거나, 새로운 버전의 앱을 다운 받기 전에는 복구가 안되는 상황에 사용하자.
0 INFORMATIVE: 역시 항상 기록되는 레벨, 오류가 아닌 뭔가 대단한 상황일 경우 기록한다.
오류는 아니더라고, 뭔가 모두가 알았으면 하는 대단한 상황일 경우 기록한다.
예를 들어 오류는 아니지만, 동접자 수가 100만명이 넘어갔다거나, 악성코드로 의심되는 입력값이 감지되었다거나 등등 모두가 알면 좋을 만한 사건이 발생한 상황에 사용하자.
DEBUG 레벨: 디버그 모드에서만 기록되는 레벨, 디버깅 과정과 관련된 추가 정보를 기록한다.
디버깅 과정과 관련한 추가 정보를 기록할 때 사용한다.
만약 로깅 자체보다는 개발자 본인의 관심사와 관련한 정보라면 verbose level로 로깅하자.
배포 버전에도 로깅이 가능하며, 로깅과 관련한 소스가 컴파일 되기 때문에 성능을 고려한다면
로깅 소스는 반드시 다음과 같이 if (LOCAL_LOG) or if (LOCAL_LOGD) 구문내에 구현해야 한다.
혹시나, 다른 대안으로 리펙토링을 통해 logging 기능을 밖으로 빼는 방법을 생각해보기도 하는데 (re-factoring out), 이는 좋은 생각이 아니다.
왜냐하면, String 파라미터가 전달되면서 불필요한 String 생성이 발생하기 때문이다.
VERBOSE 레벨: 뭐든 로깅해도 되는 레벨, 개발자 본인의 관심사와 관련된 정보 등을 기록한다.
debug level 처럼 반드시 if구문내에 구현하도록 하자.
아니면 배포전에 아예 없애버리자.
기억할 것
1. VERBOSE 레벨 이 아닐경우 - 상위 method 오버로딩 시 상위 method에 logging하자.
하나의 모듈 내에 있는 하나의 function chain 내에서 오류는 가능한 한번만 보고(logging)가 되도록 해야 한다.
이를테면 method overloading 방식으로 methodA(param1) 가 methodA(param1, param2)를 호출하면 error는 methodA(param1, param2) 에서만 기록하도록 하자.
그래야 issue를 격리시키는 게 쉬워진다.
2. VERBOSE 레벨 이 아닐경우 2 - 상위 모듈에 전달된 DATA 가 문제가 될 경우, debug모드로
연쇄적으로 작동하는 모듈간에 만약 상위 모듈에서 전달된 data에 문제가 있다고 판단될 경우 로깅을 하려면 debug 모드로 해야 한다.
굳이 information 이상 레벨의 로깅이 필요하다면, 상위 레벨 모듈에서 처리해야한다.
특히 lib 나 프레임워크개발시에 이런 규칙이 중요하다.
lib 나 framework를 가져다 쓰는 경우 마음대로 로깅을 남기고 곤란한 경우가 발생한다.
3. 반복되거나 동일한 작업이 예상되는 것은 일정한 조건을 걸어서 로깅해라.
이를 테면, onTouchEvent 내에 로깅할때 네트웍 단절 상태등은 충분히 예상되는 내용이다. debug verbose 이상의 로깅을 하지 말자.
4. 다른 앱에서 접근가능한 파일시스템 용량 초과 같은 이슈는 INFORMATIVE 이하 레벨로 검증 되지 않은 소스로부터 들어오는 잘못된 데이터 입력등의 이슈는 DEBUG 이하로 작성할 것.
5. Log.v() 는 배포버전에서도 컴파일 된다.
레벨에 따라 로깅이 안될 뿐이지. 따라서 반드시 if 구문안에서 String을 처리해야함.
6. 모든 로깅은 간결하고 누구나 쉽게 이해할 수 있어야 한다.
작성자만 알아볼 수 있게 하지 말 것. (DEBUG level 이상의 로깅이라면 말이지)
7. 가능한 한줄로 표현되게끔 해주세요. 너무 길지도 않게.
8. 작업 성공 여부 같은 것은 VERBOSE 외에선 사용하지 말 것.
9. 검사나 분석을 위한 임시 로깅은 반드시 DEBUG or VERBOSE level 에서만 작성할 것.
10. 로깅으로 개인정보 등 보안 정보가 유출되지 않도록 각별히 신경 쓸것.
11. System.out.println()(or printf() for native code) 는 절대 사용하지 말것.
System.out와 System.err는 /dev/null 로 연결되므로 아무 기능도 안하게 되는데 괜히 StringBuilder 만 잡아 먹게 된다.
12. 로그가 로그를 만들게 하지 말자.
