Конвенція щодо імен Android

Я шукаю ретельну пропозицію щодо імен Android. Я знайшов тут трохи:

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

який говорить:

• Непублічні, нестатичні імена полів починаються з m.
• Статичні назви полів починаються з s.
• Інші поля починаються з малої літери.
• Публічні статичні кінцеві поля (константи) є ALL_CAPS_WITH_UNDERSCORES.

Тим не менше, я шукаю щось набагато ширше, що охоплює всі аспекти Android:

• як називати макети та подання всередині,
• як назвати меню
• як називати стилі
• як називати таблиці бази даних (однини, множини) та поля всередині
• тощо

Якщо є якась загальновизнана пропозиція, я просто хотів би слідувати цьому. Всі SDK, схоже, йдуть своїм шляхом, тому мене особливо цікавить спосіб Android, як це зробити.

Рекомендації 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 діяльності повинні починатися з назвою дії всіх компоненти повинні мати префікс або коротке ім'я , як БТНА для 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

Ось що я використовую. Я також скопіюю за цим посиланням.

Назви об’єктів

• Не використовуйте префікс mабо sпрефікс відповідно до вказівок Google. Я зупинявся роками, і мені легше без них. IDE повідомить вам, коли ви використовуєте щось приватне або статичне; це здається застарілою конвенцією.
• КОНСТАНТИ починаються з шапки
• Абревіатури повинні писати лише велику літеру першої літери. Наприклад, functionUrlі unitId. Ні unitID.
• Префікс із типом об’єкта. Наприклад, TextView, який містить ім'я, буде tvName. EditView з паролем буде etPass.
• Якщо це щось, що зазвичай використовується лише один раз під час дії (наприклад, ListView), не бійтеся просто викликати це lv.
• Якщо це не тип об’єкта, просто назвіть його за його функцією. Наприклад, якщо це рядок, що містить ідентифікатор, назвіть його як id, а не stringId. IDE покаже вам, коли це рядок, плаваючий або довгий.
• Залишайте його розбірливим. Використовуйте щось на зразок Passзамість Password.
• У XML ім'я має бути підкресленим, без великих літер, наприклад tv_nameіet_pass
• Помістіть android:idяк перший атрибут у XML.

Назви файлів

• Макети префіксів із типом, яким він є. Наприклад fragment_contact_details.xml, view_primary_button.xml, activity_main.xml.
• Для класів класифікуйте їх за папками, але використовуйте суфікси. Наприклад, /activities/MainActivity.javaабо /fragments/DeleteDialog.java. Мої папки - це дії, фрагменти, адаптери, моделі та утиліти .
• Адаптери повинні повідомляти, як і коли вони використовуються. Тож може бути викликаний адаптер ListView для ChatActivity 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 часто мають маленькі регістри і використовують підкреслення лише тому, що, схоже, всі роблять це таким чином.

ПОСЛІДОВІСТЬ
Кожен (крім випадків, коли вони працюють у командах) матиме власну конвенцію, і яку з них ви оберете, не має значення. Переконання, що вона узгоджується протягом усього додатку, має значення.


СТРУКТУРА
Особисто я використовую таку конвенцію іменування, як ця, оскільки вона починається від імені класу до компонента і узгоджується в усьому xml:

• КЛАС :<ClassName>
• ДІЯЛЬНІСТЬ :<ClassName>**Activity**
• ПЛАН :classname_activity
• ІДЕНТИФІКАЦІЇ КОМПОНЕНТІВ :classname_activity_component_name

Прикладом цього може бути OrderActivity.class, order_activity.xml, order_activity_bn_cancel. Зверніть увагу, що весь XML пишеться малими літерами.

СКОРОЧЕННЯ ПЛАНІВ
Якщо ви хочете використовувати коротші імена, щоб зберегти код акуратніше; тоді іншим методом може бути скорочення ВСІХ назв у XML, а також макетів.

Прикладом цього може бути OrderActivity .class: ord_act .xml, ord_act _bt_can, ord_act _ti_nam, ord_act _tv_nam. Я розбиваю імена на три, але це залежить від кількості схожих імен

СКОРОЧЕННЯ ТИПІВ КОМПОНЕНТІВ
При скороченні типів компонентів намагайтеся також підтримувати їх послідовність. Зазвичай я використовую дві літери для типу компонента та три літери для імені. Однак іноді ім'я не буде необхідним, якщо це єдиний елемент такого типу в макеті. Принцип посвідчення особи - бути унікальним

• ІДЕНТИФІКАЦІЇ КОМПОНЕНТІВ :nam_act_component_nam

СКОРОЧЕННЯ ТИПУ КОМПОНЕНТІВ (Цей список містить дві букви, яких достатньо)
Макет кадру: fl
Лінійний макет: ll
Макет таблиці: tl
Рядок таблиці: tr
Макет сітки: gl
Відносний макет: rl

Вид тексту: телевізор
Кнопка: Б.Т.
Check Box: центібар
перемикача: SW
Кнопка перемикання: Т.Б.
Кнопка Зображення: І.Б.
Image Вид: IV
Progress Bar: пб
Seek Bar: С.Б.
Рейтинг Бар: гь
Spinner: зр
WebView: WV
Edit Text: ЕТ

Група радіо: rg
Перегляд списку: lv
Grid View: gv
Розширений перегляд списку: el
Scroll View: sv
Горизонтальний перегляд прокрутки: hs
View View: * se
Tab Host: th
Video View: vv
Dialer Filter: df

Включити: ic
Фрагмент: fr
Спеціальний вигляд (інше): cv

Я не думаю, що для цього ще існує домовленість. кожна компанія має свої правила, і я не думаю, що тут хтось особливо дбає про це.

Для мене я віддаю перевагу розміщенню назви, щоб вона була прив'язана до контексту. наприклад, якщо є діяльність, яка називається "MainActivity", її назва макета буде "main_activity.xml", і для кожного ресурсу, пов'язаного з цією діяльністю, я додаю префікс "main_activity", щоб я знав, що він використовує її. те саме стосується ідентифікаторів, що використовуються для цієї діяльності.

Причина, по якій я використовую ці імена, полягає в тому, що їх легше знайти, видалити, якщо потрібно, і ви не отримаєте заміну їх іншими, якщо ви використовуєте андроїд-бібліотеки, оскільки імена досить унікальні.

Я також намагаюся якомога більше давати значущих імен, тому ви зазвичай не бачите "listView" або "imageView2" як ідентифікатори, а щось на зразок "contactsListView" та "contactImageView". те саме ім'я (або подібне) також відповідало б змінним всередині коду Java, щоб полегшити пошук.

Отож, коротко, мої поради:

• намагайтеся уникати цифр всередині імен. вони, як правило, не значать багато, і показують, що ви використовували перетягування лише для дизайнера інтерфейсу.

• для демонстраційних версій, POC та для питань тут не турбуйтеся про те, щоб назвати.

• спробуйте додати префікс до всіх назв ресурсів (включаючи ідентифікатори), щоб показати, до якого контексту вони належать, та досягти унікальності.

• дайте значущі імена, де це можливо.

Найновіші плагіни Android Eclipse автоматично створюють деякі файли, які ви згадуєте під час створення нового проекту. З цього іменування є приблизно таким:

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

Я дотримувався цієї схеми, наприклад

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

Отже, це щось на зразок назв пакунків, від загальних до детальних. Це також дозволяє акуратно сортувати.

Кожне тіло використовує своє власне. Основна мета - уникнути помилок та неправильної інтерпретації, особливо коли інші читають ваш код. Хоча підсвічування синтаксису та автоматична перевірка коду в сучасних середовищах розробки середовища робить це досить суттєвим.

Але ці конвенції про іменування також роблять дуже зручним, коли ввімкнено заповнення коду. Наприклад, просто введіть mі автозаповнення покаже вам список полів класу.

Але багато разів доводиться працювати з чужим кодом, який не використовує таку домовленість. такі захищені змінні та перевизначені параметри методу просто додають плутанини.

Кілька прикладів:

• Поставте до змінних класу префікс m, а статичні фінальні змінні зробіть усі великі, _розділяючи слова. Не використовуйте префікс для зменшення змінних обсягу.

• Ім'я макета після батьківського призначеного для користувача інтерфейсу, наприклад act_main.xml, frg_detail.xml, itm__act_main__list1.xml; для діяльності MainActivity, фрагмента DetailFragment, розташування елемента для ListViewін MainActivityз ідентифікатором list1, відповідно.

• Ідентифікатори елемента імені в макетах xml, наприклад: lsv__act_main__list1для ListView та btn__act_main__submitелемента `Button. Це значно полегшує їх пошук за допомогою автозаповнення.

Що стосується угоди про іменуванні і / або найкращої практики, я часто слідую цей мД файлу з Рібо / андроїда-рекомендація сховища в GitHub , який має проект і кодування керівних принципів занесених в ньому.