안드로이드 리소스(xml) 명명 규칙

이번에 좋은 기회를 얻어서 다른 사람들과 안드로이드 프로젝트를 진행하게 되었다.

 

그런데 만들어져 있는 소스파일을 보니 레이아웃이나 파일들 이름이 일정한 규칙으로 짜여져 있는 것은 확인했는데 뭐라고 적혀있는지 알아보기가 힘들었다;; 그 중에서도 특히 xml과 관련 된 파일의 이름이 생소하였다.

 

그러던 와중에 괜찮은 글을 발견하게 되어 한 번 정리해보려고 한다.

 

jeroenmols.com/blog/2016/03/07/resourcenaming/

A successful XML naming convention

 

기본 원칙

<WHAT>_<WHERE>_<DESCRIPTION>_<SIZE>

<WHAT>

리소스가 실제로 무엇을 나타내는지 지칭한다. 예) MainActivity => activity

 

<WHERE>

앱에서 논리적으로 어디에 속해있는지를 설명한다. 다양한 화면에서 사용되는 리소스 강튼 경우는 all을 사용하고 그 외리소스는 자신이 속해 있는 안드로이드 뷰 서브클래스의 이름을 사용한다. 

 

예) MainActivity => main, ArticleDetailFragment => articledetail

 

<DESCRIPTION>

한 화면에 있는 다양한 요소를 구분짓는 부분이다.

 

<SIZE> (optional)

정확한 크기 또는 size bucket(?) 을 표현한다. 선택적으로 사용하면 된다.

 

https://jeroenmols.com/img/blog/resourcenaming/resourcenaming_cheatsheet.pdf

장점

 

위 방식대로 xml의 이름을 구성하면 다음과 같은 장점을 얻을 수 있다.

 

1. 화면 별로 리소스 순서를 정할 수 있다.

WHERE 부분은 리소스가 속한 화면을 설명한다. 따라서 특정 화면에 대한 모든 IDs, drawables, dimensions등을 쉽게 찾을 수 있다.

 

2. 강력하게 형식화 된 resource IDs

findViewById() 캐스팅을 쉽게 진행할 수 있다.

 

3. 더 나은 리소스 구성

File 브라우저/ 프로젝트 탐색기는 일반적으로 알파벳 순ㅅ으로 정렬된다. 즉, 레이아웃이나 drawable 같은 경우 WHAT이나 WHERE의 접두사 별로 그룹화가 되는데 간단한 안드로이드 스튜디오의 플러그인이나 기능으로 폴더가 있는 것처럼 리소스들을 나타낼 수 있다.

 

4. 더욱 효율적인 자동 완성

리소스 이름을 예측하기가 쉬워지기 때문에 IDE의 자동 완성을 사용하는 것이 훨씬 더 쉬워진다. 

 

5. 더이상의 이름 충돌은 그만~

다른 화면에 있는 비슷한 리소스라고 하더라도 WHERE가 다르거나 all이라서 이름 충돌을 피할 수 있다.

 

6. 깔끔한 리소스 이름

전반적으로 모든 리소스는 논리적으로 이름이 지어져서 깔끔한 안드로이드 프로젝트가 된다.

 

7. Tools 지원

이런 명명 schema는 안드로이드 스튜디오에서 제공하는 기능을 쉽게 지원받을 수 있다. 이렇게 이름을 강제하는 lint rules나 WHAT이나 WHERE를 바꿀 때 리팩토링을 지원한다. 

 

레이아웃(Layouts)

<WHAT>_<WHERE>.XML

<WHAT> 같은 경우는 아래 선택지 중 하나다.

Prefix	Usage
activity	액티비티의 contentview
fragment	Fragement의 view
view	커스텀 view에의 inflate 된 것
item	list/recycler/gridview에 사용되는 item 레이아웃
layout	tag가 포함되서 재사용되는 layout

예시:

• activity_main : MainActivity의 content view
• fragment_articledetail : ArticleDetailFragment의 view
• view_menu : MenuView의 커스텀 뷰 클래스에 의해 inflated 된 레이아웃
• item_article : ArticleRecyclerView의 list item
• layout_actionbar_backbutton : backbutton이 포함 된 actionbar 레이아웃

 

Strings

String의 경우에는 <WHAT>이 의미가 없다.

<WHERE>_<DESCRIPTION>

또는

all_<DESCRIPTION>

예시 : 

• articledetail_title : ArtitlceDetailFragment의 제목
• feedback_explanation : FeedbackFragment에서의 피드백 설명
• feedback_namehint : FeedbackFragment에서의 name 필드의 힌트
• all_done : 일반적인 "done" string

 

Drawables

Drawable도 마찬가지로 <WHAT>이 필요없다.

<WHERE>_<DESCRIPTION>_<SIZE>

또는

all_<DESCRIPTION>_<SIZE>

<SIZE>의 경우 선택적으로 지정하고 "24dp"처럼 실제 사이즈를 지정하거나 "small" 크기를 나타내는 단어를 사용한다.

 

예시 : 

• articledetail_placeholder : ArticleDetailFragment의 placeholder
• all_infoicon : 일반적인 info icon
• all_infoicon_large : info icon의 큰 버전
• all_infoicon_24dp : info icon의 24dp 버전

 

IDs

<WHAT>의 경우 XML 요소가 포함되어 있는 클래스 이름이다. <WHERE>는 ID가 포함되어 있는 화면 이름이고 한 화면에서 유사한 요소를 구별하기 위해서 <DESCRIPTION>을 선택적으로 활용합니다.

<WHAT>_<WHERE>_<DESCRIPTION>

예시 : 

• tablayout_main : MainActivity의 TabLayout
• imageview_menu_profile : 커스텀 MenuView의 profile image
• textview_artilcedetail_title : ArticleDetailFragment의 title TextView

 

Dimensions

앱은 사수로 재사용 될 만한 크기와 관련된 묶음을 정의해야 한다. 기본적으로 대부분의 크기를 all로 만든다.

그래서 보통은 아래의 형식으로 사용한다.

<WHAT>_all_<DESCRIPTION>_<SIZE>

선택적으로 다음과 같이 사용되기도 한다.

<WHAT>_<WHERE>_<DESCRIPTION>_<SIZE>

<WHAT>의 경우는 아래의 종류 중에서 하나를 사용하는 경우가 많다.

Prefix	Usage
width	폭 (dp)
height	높이 (dp)
size	만약 폭과 높이가 같다면 사용
margin	margin (dp)
padding	padding (dp)
elevation	z축 높이 (dp)
keyline	view의 가장자리에서부터 측정된 keyline (dp)
textsize	size of text (sp)

 

예시 : 

• height_toolbar : 모든 toolbar의 높이
• textsize_medium : 모든 텍스트의 medium 크기
• size_menu_icon : menu의 icon 크기
• height_menu_profileimage : 메뉴의 프로필 이미지 높이

 

현재 한계

1. 화면의 이름이 고유해야 한다.

MainActivity가 있다면 MainFragment가 있어서는 안 된다. 리소스의 이름이 꼬이게 된다.

2. 리팩토링이 지원이 안 됨.

클래스 이름이 변경되더라도 리팩토링이 지원되지 않기 때문에 리소스의 <WHERE> 부분을 일일이 찾아서 수정해줘야 한다. 

3. 모든 리소스 타입에 지원되는 것이 아님.

theme, styles, colors, animation와 같은 리소스 타입은 아직 명명 체계가 확립되지 않았다.