Соглашения об именах файлов компоновки?

Ответ 1

Как ни странно, при попытке google этот вопрос выводит только эту страницу как значимый результат... За последние полгода я использую соглашение об именовании, подобное вашему, но с более короткими префиксами. Например: Для активности, которая показывает экран "О нас":

Имя класса: ActAboutUs. Класс префикса - это излишний, но он явно отличает классы активности от других. Первоначально я использовал отдельный каталог для всех видов деятельности (как и ваш подход), но через некоторое время я понял, что для больших приложений лучше всего группировать в каталогах по функциям, чем по суперклассу (т.е. Activity). Мне легче работать в одном каталоге, например /src/settings/, когда я работаю над настройками. Таким образом, все файлы java, которые мне нужны, находятся в одном каталоге, поэтому мне не нужно блуждать:

/src/settings/ActSettingsGlobal.java
/src/settings/ActSettingsNet.java
/src/settings/Settings.java
/src/settings/SettingsDBAdapter.java
/src/settings/etc...

Этот подход также помогает разделить работу между разными разработчиками, т.е. каждый работает в своем собственном каталоге на отдельной функции, поэтому не ступая друг на друга: -).

Некоторые люди предпочитают суффиксы, но я считаю их менее полезными. Префиксы помогают группировать вещи в алфавитном порядке, как в примере выше: префикс Act* сначала сортируется, поэтому все действия удобно расположены вверху.

Я даже рассматриваю возможность использования Act_ в качестве префикса, который более читабельен, хотя он противоречит соглашениям об именах java...

Макет имени файла: act_about_us.xml. В res/layout/ у нас нет "роскоши" поддиров, что весьма неудачно, поэтому единственный способ группировать вещи - использовать соответствующий префикс, например Act_, dlg_ и т.д.

Имена строк: <string name="act_about_us_dlg_help1_title" ... string.xml - это место, где у нас больше всего проблем с дублированием name s. Очень легко создавать дубликаты, если соглашение об именах, например activity_element_item, не используется. Это добавляет много дополнительного набора текста, но это избавляет вас от много путаницы позже. Для глобальных (прикладных широких) строк мы используем префикс "global_", например global_btn_ok, global_msg_no_inet_conn. Обычно мы делаем одного человека ответственным за все строки global_, поэтому, если кому-то нужна новая строка или изменение, которое ему нужно синхронизировать с ним, чтобы избежать создания беспорядка.

(теперь я понимаю, что activity__element__item (два символа подчеркивания) более четкие и читаемые, чем activity_element_item)

В целом я все еще не могу избавиться от чувства, что с моим подходом что-то не так, потому что я не могу поверить, что разработчики Google создали такую ​​неудобную структуру, когда дело доходит до работы с файлами, идентификаторами, именами, и т.д...

Ответ 2

Я думаю, что следующее соглашение об именах должно следовать

для активности

если наше название деятельности

DisplayListActivity

тогда наше имя макета должно быть

display_list_activity.xml

для элементов списка мы можем включить категорию в имя макета списка

country_list_item.xml

а для диалоговых окон их действие может быть включено

delete_country_dialog.xml

Ответ 3

При поиске группы макетов, как я обычно работаю над ними, я считаю эффективным всегда добавлять имя класса и следить за любыми подмакетами. Для экземпляра:

Имя класса: AboutActivity.java
Имя макета: about_activity.xml
Подмакетное имя: about_activity_menu.xml
Sub Sub-layout Name: about_activity_menu_item.xml

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

Ответ 4

Хорошо читать https://jeroenmols.com/blog/2016/03/07/resourcenaming/

В основном, вы следуете WHAT WHERE DESCRIPTION SIZE

Например, файл макета

• activity_main: просмотр содержимого MainActivity
• fragment_articledetail: просмотр для элемента ArticleDetailFragment

строка

• articledetail_title: название статьиDetailFragment
• feedback_explanation: описание обратной связи в FeedbackFragment

вытяжка  - all_infoicon_large: большая версия значка общей информации  - all_infoicon_24dp: 24dp версия общей информации значок

Ответ 5

Первая часть имени файла макета всегда должна быть типом соответствующего класса. Например, если у нас есть класс MainActivity (в этом случае тип Activity), соответствующий файл макета следует называть activity_main.xml

Это означает, что мы можем сказать, что у нас есть диалог под названием WarningDialog, соответствующий файл макета следует называть dialog_warning.xml, то же самое касается фрагментов и т.д.

Это может показаться знакомым, потому что так же называются файлы activity/layout при создании нового проекта в Android Studio (MainActivity → activity_main.xml).

Ответ 6

Для меня наименование должно исправить два важных требования:

1. он должен дать вам подсказку о содержимом и типе файлов (например, activity_login/login_activity или movie_list_item/list_item_movie)
2. он должен группировать связанные элементы, чтобы свести к минимуму скачки назад и вперед

Для второго требования большинство людей определяют "связанный" как связанный тип, который дает вам что-то вроде этого:

activity_login
activity_movie_list
activity_user_list
activity_settings
fragment_movie_list
fragment_user_list
item_movie 
item_user

и т.д.

Я предпочитаю группировать по функциям, так как вы почти никогда не будете работать со всеми действиями или всеми фрагментами, но вместо этого вы будете работать с функцией фильмов или функцией настроек.

Итак, мой предпочтительный способ заключается в следующем:

login_activity
movie_list_activity
movie_list_fragment
movie_list_item 
user_list_activity
user_list_fragment
user_list_item
settings_activity

Исходные файлы следуют за именами XML, но в CamelCase, поэтому будет

LoginActivity
MovieListActivity
MovieFragment 
etc.