it-swarm.com.ru

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

Какие соглашения о присвоении имен файлам люди придумали.

Я ничего не нашел в Интернете, но подумал об использовании следующего соглашения.

Что все думают?

 - activity_* 
 - dialog_*
 - list_item_*

Это все, с чем я работал до сих пор.

Кроме того, как насчет именования деятельности против ее макета? Например:

-> res
    -> layout
        -> activity_about_us.xml
-> src
    -> activity
        -> AboutUs.Java
38
Salsero69

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

Имя класса : ActAboutUs. Префиксный класс является своего рода излишним, но он четко отличает классы активности от других. Первоначально я использовал отдельный каталог для всех действий (аналогично вашему подходу), но через некоторое время я понял, что для больших приложений может быть лучше группировать каталоги по функциям, чем по суперклассам (то есть активности). Мне легче работать в одном каталоге, например, /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 - это место, где у нас больше всего проблем с дублированием names. Создать дубликаты очень легко, если не используется соглашение об именах, такое как activity_element_item. Это добавляет много дополнительной печати, но это избавит вас от большого количества путаницы в дальнейшем. Для глобальных (прикладных) строк мы используем префикс "global_", например global_btn_ok, global_msg_no_inet_conn. Обычно мы возлагаем на одного человека ответственность за все строки global_, поэтому, если кому-то нужна новая строка или изменение, ему нужно синхронизироваться с ним, чтобы избежать беспорядка.

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

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

28
Ognyan

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

для деятельности 

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

DisplayListActivity

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

display_list_activity.xml

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

country_list_item.xml

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

delete_country_dialog.xml
9
Sunil Pandey

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

Имя класса: AboutActivity.Java
Название макета: about_activity.xml
Имя дополнительного макета: about_activity_menu.xml
Имя суб-макета: about_activity_menu_item.xml

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

6
Molimo

Это хорошее чтение https://jeroenmols.com/blog/2016/03/07/resourcenaming/

По сути, вы следуете WHAT WHERE DESCRIPTION SIZE

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

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

строки

  • articledetail_title: заголовок ArticleDetailFragment
  • feedback_explanation: объяснение обратной связи в FeedbackFragment

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

2
onmyway133

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

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

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

1
Jeffalee