Подтвердить что ты не робот

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

Я ищу подробное предложение по соглашению об именах Android. Я нашел немного здесь:

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

который говорит:

  • Непубличные, нестатические имена полей начинаются с m.
  • Имена статических полей начинаются с s.
  • Другие поля начинаются со строчной буквы.
  • Открытые статические конечные поля (константы) являются ALL_CAPS_WITH_UNDERSCORES.

Тем не менее, я ищу что-то гораздо более обширное, охватывающее все аспекты Android:

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

Если есть какое-то общепринятое предложение, я бы просто хотел последовать этому. Все SDK, кажется, идут своим путем, поэтому я особенно заинтересован в способе Android сделать это.

4b9b3361

ОТВЕТЫ

Ответ 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
...

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