Android 명명 규칙

Android 명명 규칙

---

철저한 Android 명명 규칙 제안을 찾고 있습니다. 여기서 조금 발견했습니다.

http://source.android.com/source/code-style.html#follow-field-naming-conventions

그것은 말한다 :

• 비공개, 비 정적 필드 이름은 m으로 시작합니다.
• 정적 필드 이름은 s로 시작합니다.
• 다른 필드는 소문자로 시작합니다.
• 공개 정적 최종 필드 (상수)는 ALL_CAPS_WITH_UNDERSCORES.

그러나 저는 Android의 모든 측면을 다루는 훨씬 더 광범위한 것을 찾고 있습니다.

• 레이아웃과 뷰의 이름을 지정하는 방법,
• 메뉴 이름 지정 방법
• 스타일 이름 지정 방법
• 데이터베이스 테이블 (단수, 복수) 및 필드의 이름을 지정하는 방법
• 기타

일반적으로 받아 들여지는 제안이 있다면 나는 그것을 따르고 싶습니다. 모든 SDK는 고유 한 방식으로 진행되는 것 같아서 Android 방식에 특히 관심이 있습니다.

---

ribot의 Android 가이드 라인 은 표준 명명 규칙의 좋은 예입니다.

XML 파일에 대한 명명 규칙 :

activity_<ACTIVITY NAME>.xml - for all activities
dialog_<DIALOG NAME>.xml - for all custom dialogs
row_<LIST_NAME>.xml - for custom row for listview
fragment_<FRAGMENT_NAME>.xml - for all fragments

xml 파일의 컴포넌트 / 위젯에 대한 이름 지정 규칙 :

모든 구성 요소 X의 활동은 모든 구성 요소가 접두사 또는 같은 짧은 이름이 있어야 활동 이름으로 시작해야합니다 BTN 에 대한 Button예를 들어, 로그인 활동 구성 요소의 이름은 다음과 같이해야합니다.

activity_login_btn_login
activity_login_et_username
activity_login_et_password

주요 구성 요소의 짧은 이름 :

Button - btn
EditText - et
TextView - tv
ProgressBar - pb
Checkbox - chk
RadioButton - rb
ToggleButton - tb
Spinner - spn
Menu - mnu
ListView - lv
GalleryView - gv
LinearLayout -ll
RelativeLayout - rl

---

https://github.com/futurice/android-best-practices 로 시작할 수있는 모범 사례 모음입니다.

여기 내가 사용하는 것이 있습니다. 이 링크에서도 복사하겠습니다.

개체 이름 지정

• Google 가이드 라인에 따라 m또는 s접두사를 사용하지 마세요 . 나는 몇 년 동안 멈춰 왔고 그들 없이는 더 쉬웠다. IDE는 비공개 또는 정적 무언가를 사용할 때 알려줍니다. 쓸데없는 관습처럼 보입니다.
• 상수는 대문자로 시작합니다.
• 두문자어는 첫 글자 만 대문자로 표기해야합니다. 예를 들어 functionUrl및 unitId. 아닙니다 unitID.
• 개체 유형의 접두사입니다. 예를 들어 이름이 포함 된 TextView는 tvName. 암호가있는 EditView는 etPass.
• 일반적으로 활동에서 한 번만 사용되는 경우 (예 : ListView)라고 부르는 것을 두려워하지 마십시오 lv.
• 객체 유형이 아닌 경우 기능으로 이름을 지정하십시오. 예를 들어 ID가 포함 된 문자열 인 경우 이름을 idstringId가 아닌으로 지정합니다. IDE는 그것이 문자열, float 또는 long 일 때 알려줄 것입니다.
• 읽기 쉽게 유지하십시오. Pass대신 같은 것을 사용하십시오 Password.
• XML 내에서 이름은 대문자없이 밑줄이어야합니다 (예 : tv_name및et_pass
• android:idXML의 첫 번째 속성으로를 넣으십시오 .

파일 이름 지정

• 유형을 접두사로 배치합니다. 예 fragment_contact_details.xml, view_primary_button.xml, activity_main.xml.
• 클래스의 경우 폴더로 분류하되 접미사를 사용하십시오. 예를 들어, /activities/MainActivity.java또는 /fragments/DeleteDialog.java. 내 폴더는 활동, 조각, 어댑터, 모델 및 유틸리티 입니다.
• 어댑터는 사용 방법과시기를 알려야합니다. 따라서 ChatActivity 용 ListView 어댑터를 ChatListAdapter.

colors.xml 및 dimens.xml을 팔레트로 사용

• 색상의 경우 gray_light, 아니라 같은 이름을 사용합니다 button_foreground.

• 차원의 경우 spacing_large, 아닌 같은 이름을 사용합니다 button_upper_padding.

• 버튼 색상이나 패딩에 특정한 것을 설정하려면 스타일 파일을 사용하십시오.

strings.xml

• 네임 스페이스와 유사한 키로 문자열 이름을 지정하고 두 개 이상의 키에 대해 값을 반복하는 것을 두려워하지 마십시오.

• 사용 error.message.network하지 않고 network_error.

추리

명명 규칙의 목적은 모든 것을 깔끔하고 일관되게 만드는 것이 아닙니다 . 가능한 실수를 표시하고 작업 흐름을 개선하기 위해 있습니다. 이들 중 대부분은 키보드 단축키에 편리하도록 설계되었습니다. 멋지게 보이기보다는 버그를 최소화하고 작업 흐름을 개선하는 데 집중하십시오.

접두사는 "그 TextView의 이름이 무엇입니까?"에 적합합니다. 순간.

접미사는 그런 방식으로 자주 액세스하지 않지만 혼란 스러울 수있는 항목에 대한 것입니다. 예를 들어, 내 코드를 해당 페이지의 Activity, Fragment 또는 Adapter에 넣었는지 확실하지 않을 수 있습니다. 원하는 경우 드롭 할 수 있습니다.

XML ID는 종종 소문자로되어 있으며 모든 사람이 이런 식으로하는 것처럼 보이기 때문에 밑줄을 사용합니다.

---

일관성
( CONSISTENCY) 모든 사람 (팀으로 작업하지 않는 한)은 고유 한 규칙을 갖게되며 어떤 규칙을 선택하든 상관 없습니다. 전체 응용 프로그램에서 일관성 이 있는지 확인하는 것이 중요합니다.


구조
개인적으로 클래스 이름에서 구성 요소까지 실행되고 xml 전체에서 일관성이 있으므로 이와 같은 명명 규칙을 사용합니다.

• 클래스 :<ClassName>
• 활동 :<ClassName>**Activity**
• 레이아웃 :classname_activity
• 구성 요소 ID :classname_activity_component_name

이 예제가 될 것이다 OrderActivity.class, order_activity.xml, order_activity_bn_cancel. 모든 XML이 소문자로되어 있습니다.

ABBREVIATING LAYOUTS
If you would like to use shorter names to keep the code tidier; then another method can be to abbreviate ALL the names in XML aswell as the layouts.

An example of this would be OrderActivity.class: ord_act.xml, ord_act_bt_can, ord_act_ti_nam, ord_act_tv_nam. I break down the names into three but this depends how many similar names you have

ABBREVIATING COMPONENT TYPES
When abbreviating component types try to keep these consistent too. I normally use two letters for the component type and three letters for the name. However sometimes the name will not be necessary if that is the only element of that type in the layout. The principle of the ID is to be unique

• COMPONENT IDS: nam_act_component_nam

COMPONENT TYPE ABBREVIATIONS (This list shows two letters which is plenty)
Frame Layout: fl
Linear Layout: ll
Table Layout: tl
Table Row: tr
Grid Layout: gl
Relative Layout: rl

Text View: tv
Button: bt
Check Box: cb
Switch: sw
Toggle Button: tb
Image Button: ib
Image View: iv
Progress Bar: pb
Seek Bar: sb
Rating Bar: rb
Spinner: sp
WebView: wv
Edit Text: et

Radio Group: rg
List View: lv
Grid View: gv
Expandable List View: el
Scroll View: sv
Horizontal Scroll View: hs
Search View:* se
Tab Host: th
Video View: vv
Dialer Filter: df

Include: ic
Fragment: fr
Custom View (other): cv

---

I don't think there is a convention for this yet . each company has its own rules and I don't think anyone cares much about it here.

For me , I prefer putting the name to be bound to the context . for example , if there is an activity called "MainActivity" , its layout name would be "main_activity.xml" , and for each resource associated with this activity , I add a prefix "main_activity" so that I know that it uses it . same goes for the ids used for this activity .

The reason I use those naming is that it's easier to find them, delete if needed , and you won't get them replaced with others if you use android libraries since the names are quite unique.

I also try as much as possible to give meaningful names , so you will usually not see "listView" or "imageView2" as ids , but something like "contactsListView" and "contactImageView" . the same name (or similar) would also match the variables inside the java code, in order to make it easier to find.

So , in short, my tips are:

• try to avoid numbers inside the names . they usually don't mean much , and show that you've only used drag&drop for the UI designer .

• for demos, POCs and for questions here , don't worry yourself about naming .

• try to add a prefix to all of the names of the resources (including ids) to show which context they belong to , and to achieve uniqueness.

• give meaningful names wherever possible .

---

Every body uses his own, The main goal is to avoid mistakes and misinterpretation, specially when others read your code. Though syntax highlighting, and auto code inspection in modern IDE's makes it pretty point less.

But these naming conventions also make it very convenient when code completion is turned on. For example just type m and auto complete will show you a list of class fields.

But many times you have to work with other's code, which doesn't use such convention. such protected variables and overridden method parameters just add to the confusion.

Few examples:

• Prefix class variables with m , and make static finals variables all caps, with _ separating words. Don't prefix any thing to lower scope variables.

• Name layout after the UI parent, for example act_main.xml , frg_detail.xml , itm__act_main__list1.xml ; for an activity MainActivity, a fragment DetailFragment, item layout for a ListView in MainActivity with id list1, respectively.

• Name element Id's in xml layouts like: lsv__act_main__list1 for a ListView and btn__act_main__submit for a `Button element. This makes them much easier to find with auto complete.

---

The newest Android Eclipse plugins create some of the files you mention automatically when you create a new project. From that, the naming is something like that:

layout/activity_main.xml
menu/activity_main.xml
...

I followed this scheme with e.g.

layout/fragment_a.xml
layout/fragment_b.xml
...

So it's something like with package names, from general to detailed. It also allows for neat sorting.

참고URL : https://stackoverflow.com/questions/12870537/android-naming-convention