1. Coding Style

본 문서는 Deviewsched의 Codingstyle에 관한 내용을 다룹니다.

기본적으로 Android Opensource Project에서 권장하는 Java Language Rules를 따릅니다.
본 문서는 아래 레퍼런스 문서를 필요한만큼 번역한 내용 입니다.
reference : https://source.android.com/source/code-style.html

본 문서를 모두 참고하였으면 아래의 두 Android coding Guideline관련 문서를 읽어주세요.
(권유가 아닌 필수입니다!)
Android Best Practices(한글)
android-guidelines(영문)

네이밍 (변수/메소드)

변수명과 메소드는 다음과같은 패턴으로 대,소문자를 활용하여 작성합니다. 테스트코드 메소드가 아닌이상 언더바( _ )는 활용하지 않습니다.

Good	Bad
XmlHttpRequest	XMLHTTPRequest
getCustomerId	getCustomerID
class Html	class HTML
String url	String URL
long id	long ID

변수명

• public이 아니며, static이 아닌 필드변수의 이름은 m으로 시작합니다.
• Static 필드변수의 이름은 s로 시작합니다.
• 그 외의 다른 필드변수의 이름은 소문자로 시작합니다.
• 단 public static final로 시작하는 상수 필드변수의 이름은 대문자와 언더바( _ )만 사용합니다.
• 변수명은 언제나 각 소스코드의 최상단에 작성합니다.

ex 변수명의 예시

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;
}

테스트 메소드 네이밍

테스트코드에서 중요한 부분을 이루는 메소드는 test로 메소드의 이름을 시작하며, 그 이후에는 테스트할 메소드의 이름을 적습니다. 메소드의 이름뒤에는 언더바( _ )를 작성하여 언더바 뒤에는 해당 테스트 메소드가 어떤 상황에 대하여 테스트를 진행하는지에대한 서술을 합니다.

예를 들어 userLogin이라는 메소드에서 유저가 자동로그인을 실행하는 경우에 대해서 테스트하는 메소드를 작성한다면 그 메소드명은 다음과 같을 것 입니다. testUserLogin_autologin

메소드 작성

확장성있는 소프트웨어를 개발하기위해서 메소드코드는 되도록 짧고 함축적이게 작성해야합니다.
그러나 가끔은 긴 메소드 코드가 메소드의 역할에 대해 알기쉬운 경우가 종종 있습니다.
그래서 메소드 길이에대한 명확한 제한은 없습니다. 하지만 만약 메소드 한개의 길이가 40줄을 넘어간다면 그것은 현재 짜고있는 코드가 프로그램의 구조에 해를 끼치고있는 것이 아닌지 돌아봐야할 필요성이 있습니다.

주석

자바문서 표준 주석 사용하기

코드의 가장 상단에는 해당 코드에대한 저작권을 명시합니다. 그리고 그 밑으로 Import에 대한 코드가 이어지며, Import 아래로 존재하는 코드들부터는 주석을 달아야하는 코드의 상단 빈칸에 관련한 설명 주석을 적습니다. 예를들어 클래스나 인터페이스에 대한 간단한 안내를 담은 주석코드는 class MyClass extends A의 위에 적으며, 각 메소드에대한 설명을 담은 주석은 public void userLogin()의 상단에 해당 메소드의 역할과 메소드에 들어가는 인자에 대한 설명을 적으면 됩니다.

Todo 주석 활용하기

아마 개발을 진행하면서 해당 코드영역에서 차후에 해야할 일에대한 Todo를 작성하려 하는 경우가 있을 것입니다. 그러한 경우에는 //Todo : We must write login logiccode! 와 같이 주석에 Todo라는 키워드를 작성하는것을 시작으로 주석을 작성하면 됩니다. Todo로 시작하는 주석문에대해서는 형광색으로 Highlight 될 것입니다.

Fixme 주석 활용하기

위의 Todo의 경우와 똑같이 Fixme는 코드를 작성하면서 차후에 리팩토링을 진행해야하는 부분이거나, 문제가 발생할 소지가 있는 코드의 경우에 수정을 해야하는 부분에대해서 안내를 하기위한 주석 키워드 입니다. 사용법은 Todo와 같습니다.

들여쓰기

들여쓰기는 일반적으로 4칸을 사용합니다. 순수한 Tab 들여쓰기는 사용하지 않으며, Android Studio에서 제공하는 Tab을 누르면 space4칸을 할당하는 기능을 활용하여 간편히 들여쓰기를 수행하세요. (기본으로 되어있습니다)
단, 들여쓰기를 8칸 할당해야하는 경우가 있습니다. 이 경우는 이어져야하는 코드를 어쩔수없이 길이를 조정하기위해 한 줄을 내리는 경우가 생길 수 있는데, 이 경우에 한 줄을 내린 코드는 8칸짜리 들여쓰기를 시행합니다. 다음은 그 좋은 예입니다.

Instrument i =
        someLongExpression(that, wouldNotFit, on, one, line);

조건문

표준 Brace Style 사용하기

아래와같은 형태가 표준 Brace Style입니다. 여러분들이 일반적으로 사용하는 조건문의 형태와 크게 다르지 않습니다.

class MyClass {
    int func() {
        if (something) {
            // ...
        } else if (somethingElse) {
            // ...
        } else {
            // ...
        }
    }
}

단 if 조건문의 하단에 단 한줄만의 코드가 존재하는 경우는 다음과 같이 두 가지 형태로 컨벤션이 존재합니다.

올바른 예 Ex1)

if (condition) {
    body(); 
}

올바른 예 Ex2)

if (condition) body();

잘못된 예

if (condition)
    body();  // bad!

Import

Import 작성 순서

Import를 작성하는 코드에도 순서가 있습니다! 기본적으로 다음과같은 순서를 따라주세요

• Android관련 패키지 Import (Acitivty, Fragment, View 등)
• 3th party 라이브러리 (volley, junit, NAVER maps 등)
• java and javax (ArrayList, Math 등)

그리고 IDE에서 코드 자동 정렬을 진행하면 다음과같은 형태로 정렬됩니다.

• 알파벳 순서대로 정렬이 됩니다.
• Major(android, com, org, java, etc...)끼리 그룹핑이 된것들끼리 한 줄간격으로 분리가 됩니다.

위와같은 Import 작성순서의 기준이 성립된 원인은 다음과 같습니다.

• 개발자들은 import를 볼때 android와 관련한 import를 보는 경우 가장 상단을 보는 경향이 있습니다.
• 사람들은 import를 볼떄 java와 관련한 import를 보는 경우 가장 하단을 보는 경향이 있습니다.
• 이미 많은 사람들이 이러한 스타일에 익숙해져있습니다.
• 많은 IDE들이 이러한 스타일을 따라왔습니다.

다중 Import 컨벤션

Bar라는 클래스를 Import하기위해 우리는 다음 두가지 형태와 같은 방법을 따를 수 있습니다.

import foo.*; / import foo.Bar;

첫번째와같은 경우는 좋은 import가 아닙니다. 다른 개발자가 Import를 보았을 때 어떤 목적을 갖고 어떤 클래스를 Import 하려했는지 그 의도를 알아채기가 어려우며, 쓸데없는 클래스를 Import 하는 것은 낭비이기 떄문입니다. 정말 해당 패키지의 모든 클래스가 필요한경우 (junit.framework.*)가 아니라면 사용해야할 클래스만 정확히 명시해서 Import 하는것을 추천드립니다.

코드 한 줄당 최대 길이

코드 한줄에 100자이상의 코드는 적지 않는것을 권장합니다. Android Studio 기준 Seperated Method 기능을 켜면 100자 기준으로 에디터영역에 실선이 그어지는 것을 볼 수 있습니다. 혹은 IDE 하단 우측에 현재 커서가 몇 칸째인지를 안내하는 부분을 보고 적절히 개행을 진행하여 코드를 짜면 됩니다.

3rd Party Library

외부 라이브러리를 사용하면서 각 라이브러리의 문서를 꼭 한번정도는 읽고 해당 라이브러리가 지속적으로 개발이 되는지, Issue를 보면서 우리의 프로젝트에 사용하면서 문제의 소지가 없는지 살펴봅시다. 특히 Deprecated된 라이브러리를 사용하지 않는것으로 합니다.

Android Log사용에 대해

우리는 흔히 안드로이드개발을 하면서 크게 의식하지않고 Log를 용도에 맞지않게 활용하는 경우가 많습니다. Android의 Log에는 ERROR / WARNING / INFORMATIVE / DEBUG / VERBOSE 종류가 있으며 로그를 출력할때 그 로그가 어떤 카테고리에 속하는지에 대해서 생각을하면서 적절한 로그를 사용해야합니다. 본 Deviewsched프로젝트에서는 Android의 로그를 직접 호출하는 것이 아닌, Util 패키지에있는 LogUile 클래스를 활용하여 LOGD / LOGI / LOGW / LOGV / LOGE 와 같이 활용하는 유틸 클래스가 존재합니다.

꼭 본문의 내용 뿐만아니라 이 문서 상단에서 소개한 나머지 두개의 페이지에대해서도 읽어보세요. 해당 문서들에 담겨있는 컨벤션 안내 역시 본 프로젝트의 코딩 스타일 컨벤션으로 적용해나갈 예정입니다!