Соглашение об именах Android

Ответ 1

рекомендации по 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

Ответ 2

Это отличная коллекция лучших практик для начала: 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 часто находятся в нижнем регистре и используют символы подчеркивания только потому, что все, кажется, делают это таким образом.

Ответ 3

ПОСЛЕДОВАТЕЛЬНОСТЬ
Каждый (если не работает в команде) будет иметь свое собственное соглашение, и то, какое вы выберете, не имеет значения. Удостовериться, что оно согласовано во всем приложении.


СОСТАВ
Лично я использую соглашение об именах, подобное этому, так как оно работает от имени класса до компонента и является единым для всей xml:

• КЛАСС: <ClassName>
• ACTIVITY: <ClassName>**Activity**
• LAYOUT: 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. Я делю имена на три части, но это зависит от того, сколько похожих имен у вас

СОКРАЩЕНИЕ ТИПОВ КОМПОНЕНТОВ
При сокращении типов компонентов старайтесь также сохранять их согласованность. Я обычно использую две буквы для типа компонента и три буквы для имени. Однако иногда имя не требуется, если это единственный элемент этого типа в макете. Принцип удостоверения личности должен быть уникальным

• КОМПОНЕНТ IDS: nam_act_component_nam

СОКРАЩЕНИЯ ТИПА КОМПОНЕНТА (в этом списке показаны две буквы, которых вполне достаточно)
Структура кадра: fl
Линейный макет: ll
Расположение стола: tl
Строка таблицы: tr
Расположение сетки: gl
Относительная компоновка: рл

Просмотр текста: ТВ
Кнопка: bt
Флажок: cb
Переключатель: SW
Кнопка переключения: tb
Кнопка изображения: ib
Просмотр изображения: iv
Прогресс-бар: pb
Искать бар: сб
Рейтинг-бар: рб
Spinner: sp
WebView: wv
Редактировать текст: et

Радио Группа: рг
Просмотр списка: lv
Вид сетки: Г.В.
Расширяемый список просмотра: el
Scroll View: SV
Горизонтальная прокрутка: hs
Поиск: * se
Tab Host: th
Просмотр видео: vv
Фильтр номеронабирателя: df

Включить: ic
Фрагмент: фр.
Пользовательский вид (другой): cv

Ответ 4

Я не думаю, что для этого есть соглашение. у каждой компании есть свои правила, и я не думаю, что здесь кто-то много заботится об этом.

Для меня я предпочитаю привязывать имя к контексту. например, если есть действие под названием "MainActivity", его имя макета будет "main_activity.xml", и для каждого ресурса, связанного с этим действием, я добавляю префикс "main_activity", чтобы я знал, что он его использует. то же самое относится к идентификаторам, используемым для этой активности.

Причина, по которой я использую эти имена, заключается в том, что их легче найти, удалить, если необходимо, и вы не сможете их заменить другими, если вы используете библиотеки Android, так как имена уникальны.

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

Итак, короче говоря, мои советы таковы:

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

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

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

• дайте содержательные имена там, где это возможно.

Ответ 5

Каждый орган использует свою собственную. Основная цель - избегать ошибок и неправильной интерпретации, особенно когда другие читают ваш код. Хотя подсветка синтаксиса и автоматическая проверка кода в современной среде IDE делают его более точным.

Однако эти соглашения об именах также очень удобны при включении кода. Например, просто введите m и auto complete покажет вам список полей классов.

Но много раз вам приходится работать с другим кодом, который не использует такое соглашение. такие защищенные переменные и переопределенные параметры метода просто добавляют к путанице.

Несколько примеров:

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

• Макет имени после родительского интерфейса пользователя, например act_main.xml, frg_detail.xml, itm__act_main__list1.xml; для операции MainActivity, фрагмента DetailFragment, макета элемента для ListView в MainActivity с id list1, соответственно.

• Идентификатор элемента ID в xml-макетах, например: lsv__act_main__list1 для ListView и btn__act_main__submit для элемента Button. Это облегчает их поиск с автоматическим завершением.

Ответ 6

Новые плагины Android Eclipse создают некоторые из файлов, которые вы указываете автоматически при создании нового проекта. Отсюда именование - вот что:

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

Я следовал этой схеме, например,

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

Итак, это что-то вроде с именами пакетов, от общего к подробному. Он также позволяет аккуратную сортировку.