Каковы некоторые соглашения об именах файлов компоновки, которые люди придумали.
Я ничего не нашел в Интернете, но подумал об использовании следующего соглашения.
Что думают все?
- activity_*
- dialog_*
- list_item_*
Это все, с чем я работал до сих пор.
Также, как насчет наименования активности против ее макета? Например:
-> res
-> layout
-> activity_about_us.xml
-> src
-> activity
-> AboutUs.java
Как ни странно, при попытке 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 создали такую неудобную структуру, когда дело доходит до работы с файлами, идентификаторами, именами, и т.д...
Я думаю, что следующее соглашение об именах должно следовать
для активности
если наше название деятельности
DisplayListActivity
тогда наше имя макета должно быть
display_list_activity.xml
для элементов списка мы можем включить категорию в имя макета списка
country_list_item.xml
а для диалоговых окон их действие может быть включено
delete_country_dialog.xml
При поиске группы макетов, как я обычно работаю над ними, я считаю эффективным всегда добавлять имя класса и следить за любыми подмакетами. Для экземпляра:
Имя класса: AboutActivity.java
Имя макета: about_activity.xml
Подмакетное имя: about_activity_menu.xml
Sub Sub-layout Name: about_activity_menu_item.xml
Ваша деятельность всегда будет на вершине каждой группировки, и охота на не-деятельность становится менее сложной задачей. Кто-нибудь знает, почему вложенные папки еще не все? Я ожидаю эффективности и простоты на заднем плане, но я думаю, что это не повредит слишком много.
Хорошо читать https://jeroenmols.com/blog/2016/03/07/resourcenaming/
В основном, вы следуете WHAT WHERE DESCRIPTION SIZE
Например, файл макета
строка
вытяжка - all_infoicon_large: большая версия значка общей информации - all_infoicon_24dp: 24dp версия общей информации значок
Первая часть имени файла макета всегда должна быть типом соответствующего класса.
Например, если у нас есть класс MainActivity (в этом случае тип Activity), соответствующий файл макета следует называть activity_main.xml
Это означает, что мы можем сказать, что у нас есть диалог под названием WarningDialog, соответствующий файл макета следует называть dialog_warning.xml, то же самое касается фрагментов и т.д.
Это может показаться знакомым, потому что так же называются файлы activity/layout при создании нового проекта в Android Studio (MainActivity → activity_main.xml).
Для меня наименование должно исправить два важных требования:
Для второго требования большинство людей определяют "связанный" как связанный тип, который дает вам что-то вроде этого:
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.