Как ни странно, попытка погуглить этот вопрос приносит только эту страницу как значимый результат ...
Последние полгода я использую соглашение об именах, подобное вашему, но с более короткими префиксами. Например:
Для активности, которая показывает экран «О нас»:
Имя класса : 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
- это место, где у нас больше всего проблем с дубликатами name
s. Создать дубликаты очень легко, если не используется соглашение об именах, например activity_element_item
. Это добавляет много дополнительной печати, но это избавит вас от большого количества путаницы в дальнейшем.
Для глобальных (прикладных) строк мы используем префикс "global_"
, например global_btn_ok
, global_msg_no_inet_conn
. Обычно мы возлагаем на одного человека ответственность за все строки global_
, поэтому, если кому-то нужна новая строка или изменение, ему нужно синхронизироваться с ним, чтобы избежать беспорядка.
(теперь я понимаю, что activity__element__item
(два подчеркивания) более четкий и читаемый, чем activity_element_item
)
В общем, я до сих пор не могу избавиться от ощущения, что с моим подходом что-то не так, потому что я не могу поверить, что разработчики Google создали такую неудобную среду, когда дело доходит до работы с файлами, идентификаторами, именами, и т.д ...