[Android] XML naming convention

xml 컨벤션 가이드

Posted by Kim Heebeom on April 25, 2018

A successful xml naming convention 해당 글을 번역 및 일부 수정한 글 입니다.

A successful XML naming convention

안드로이드 프로젝트를 진행하다보면 빌드 환경, CI, 코딩 컨벤션 등 여러 가지 전략을 가지고 있지만 리소스에 대한 naming 규칙은 가지지 않은 경우가 많습니다.

특히나, XML은 네임스페이스의 부재로 인해서 더욱 관리하기가 힘듭니다. 대규모 프로젝트의 경우 쉽게 제어하기 힘든 상황이 될 수 있습니다.

아래의 네이밍 규칙을 적용하면 이런 문제들을 어느 정도 해결할 수 있습니다.

naming convention 적용 시의 장점
  • 모든 리소스를 쉽게 찾을 수 있다 (autocomplete)
  • 논리적이고 예측 가능한 이름
  • 깔끔하게 정렬할 수 있다
  • 타입화된 리소스

기본 원리

모든 리소스의 네이밍은 아래의 간단한 규칙을 따릅니다. <WHAT>_<WHERE>_<DESCRIPTION>_<SIZE>

<WHAT> - 자원이 실제로 무엇을 나타내는지 표시합니다. (예: MainActivity -> activity)

<WHERE> - 논리적으로 앱에 속한 위치를 설명합니다. 여러 화면 에서 사용되는 리소스의 경우 all을 사용하고, 다른 리소스들은 안드로이드 뷰 서브클래스의 커스텀 부분을 사용합니다. (예: MainActivity -> main, ArticleDetailFragment -> articledetail)

<DESCRIPTION> - 한 화면에서 여러 요소를 구분합니다. (예: title, content)

<SIZE> - Drawables, dimensions 에서 선택적으로 사용합니다. (예: 24dp, small)

장점

1. 화면별 리소스 정렬

<WHERE> 부분은 리소스가 속한 화면에 대해 설명합니다. 따라서 특정 화면에 대한 모든 Id, drawables, dimenstions 들을 쉽게 얻을 수 있습니다.

2. 강력하게 타입화된 리소스 ID

리소스 ID의 경우, <WHAT>는 자신이 속한 xml 요소의 클래스 이름을 설명합니다. 이것은 findViewById() 사용을 쉽게 만들어줍니다.

3. 더 나은 리소스의 구성

프로젝트 내비게이터는 일반적으로 파일을 사전 순으로 정렬합니다. 즉, layout과 drawable이 각각 <WHAT>(액비비티, 프래그먼트) 및 <WHERE>접두어로 그룹화됩니다.

4. 효율적인 자동 완성

리소스 이름이 훨씬 더 예측 가능하기 때문에 IDE의 자동 완성 기능을 사용하면 훨씬 쉽습니다. <WHAT> 또는 <WHERE>을 입력하면 자동 완성을 제한된 범위로 좁힐 수 있습니다.

5. 이름 충돌이 없다

다른 화면에 있는 유사한 리소스들은 all에 있거나 다른 <WHERE>을 가지고 있습니다. 이 네이밍 규칙이 모든 충돌을 피하게 해줍니다.

6. 깔끔한 리소스 이름

전체적으로 모든 리소스의 이름이 논리적으로 지어져서 깔끔한 프로젝트가 됩니다.

7. 도구 지원

네이밍 규칙이 Android Studio 제공 기능에서 쉽게 지원할 수 있다. lint 규칙을 사용해서 이러한 이름을 적용하고 프로젝트 뷰에서 더 나은 리소스 시각화를 해줍니다.

Layouts

레이아웃은 일반적으로 화면당 레이아웃이 적기 때문에 상대적으로 간단합니다. 따라서 규칙을 다음과 같이 단순화 할 수 있습니다.

<WHAT>_<WHERE>.XML

여기서 <WHAT>은 다음 중 하나입니다.

예:

  • activity_main : MainActivity의 content view
  • fragment_articledetail : ArticleDetailFragment의 뷰
  • view_menu : 인플레이드되는 MenuView(커스텀 뷰)
  • item_article : ArticleRecyclerView의 list item
  • layout_actionbar_backbutton : back버튼이 있는 액션바 레이아웃

Strings

<WHAT> 부분은 Strings 부분과는 무관합니다. <WHERE>을 사용해서 어디서 사용되는지 나타냅니다.

<WHERE>_<DESCRIPTION> 또는 all_<DESCRIPTION>

예:

  • articledetail_title : ArticleDetailFragment의 제목
  • feedback_explanation : FeedbackFragment의 피드백 설명
  • feedback_namehint : FeedbackFragment의 이름 필드 힌트
  • all_done : 일반적인 “완료” 문자열

Drawables

<WHAT> 부분은 Drawables 부분과는 무관합니다. <WHERE>을 사용해서 어디서 사용되는지 나타냅니다.

<WHERE>_<DESCRIPTION>_<SIZE> 또는 all_<DESCRIPTION>_<SIZE>

선택적으로 <SIZE>를 사용합니다. 실제 크기를 지정하는 “24dp” 또는 size qualifier “small”

예:

  • articledetail_placeholder : ArticleDetailFragment의 placeholder
  • all_infoicon : 일반적인 info 아이콘
  • all_infoicon_large : large 버전의 info 아이콘
  • all_infoicon_24dp : 24dp 버전의 info 아이콘

IDs

ID의 경우 <WHAT>이 element가 속한 클래스의 이름입니다. 다음은 ID가 있는 화면이고, 하나의 화면에서 유사한 요소를 구별하기 위한 설명(선택사항)이 옵니다.

<WHAT>_<WHERE>_<DESCRIPTION>

예:

  • tablayout_main : MainActivity의 TabLayout
  • imageview_menu_profile : 커스텀 MenuView의 프로필 이미지
  • textview_articledetail_title : ArticleDetailFragment의 title TextView

Dimensions

앱은 제한된 Dimension 셋을 정의하고 계속 재사용하게 됩니다. 이는 기본적으로 모든 Dimensionsall을 기본으로 가지게 합니다.

<WHAT>_all_<DESCRIPTION>_<SIZE>

or

<WHAT>_<WHERE>_<DESCRIPTION>_<SIZE> (특정 화면에 대해서만 사용할 경우)

예:

  • height_toolbar : 모든 툴바의 높이
  • textsize_medium : 모든 텍스트의 중간 크기
  • size_menu_icon : 메뉴 아이콘 크기

제한사항

1. 화면에 교유한 이름이 있어야 한다.

예를 들어, “MainActivity” 와 “MainFragment”는 <WHAT>(Activity, Fragment)를 사용하지 않고, <WHERE>(Main)를 쓰는 Strings와 Drawables에서는 고유하게 식별되지 않는다.

2. 리팩토링 지원이 되지 않음.

“MainActivity”의 이름을 “ContentActivity”로 변경하면 “activity_main” 레이아웃의 이름이 “activity_content”로 바뀌지 않는다.

3. 모든 리소스 유형에 적용되진 않는다.

제안한 방식은 현재 모든 리소스 유형에 적용되진 않는다. 일부 리소스의 경우 자주 사용되지 않고 매우 다양할 수 있다.(테마, 스타일, 색상, 애니메이션)


[Reference]