Соглашение об именах идентификаторов Android: нижний регистр с подчеркиванием и верблюжий регистр


89

В настоящее время я разрабатываю приложение для Android. Теперь я обнаружил, что вы не можете поместить объекты ресурсов, скажем, изображение в папку с возможностью рисования, и назвать его как «myTestImage.jpg». Это приведет к ошибке компилятора, поскольку синтаксис верблюжьего регистра недопустим, поэтому вам придется переименовать его как «my_test_image.jpg».

Но как насчет идентификаторов, которые вы определяете в файле XML. Скажем, у вас есть следующее определение

<TextView android:id="@+id/myTextViewFirstname"
              android:layout_width="wrap_content"
              android:layout_height="wrap_content"
              android:text="Firstname" />

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

Теперь в примерах Android всегда используются строчные буквы и подчеркивание. Это просто соглашение об именах для использования нижнего регистра с подчеркиванием для идентификаторов или это может вызвать проблемы на реальном устройстве?

Спасибо

Ответы:


87

Устройство не будет жаловаться, если вы используете имена идентификаторов в верблюжьем регистре. Для моего первого приложения я написал все идентификаторы в верблюжьем регистре, потому что я думаю, что таким образом он выглядит лучше в коде Java, и он отлично работает.

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

// This must be undescored due to naming constrictions
setContentView(R.layout.my_long_layout_name);

// Now this looks a little out of place
findViewById(R.id.myLongSpecificId);

Меня тоже интересуют стандарты здесь. Google противоречит своим примерам; иногда они используют все строчные буквы, иногда вставляют подчеркивания, а иногда используют верблюжий регистр.


18
Да, это как раз моя проблема. Они заставляют вас использовать соглашение об именах с подчеркиванием для макетов, в то время как вы можете использовать либо верблюжий регистр, либо подчеркнутый для идентификаторов, ссылающихся на элементы управления / виджеты внутри определений макета XML. Google действительно должен определить здесь какой-то стандарт (если они еще этого не сделали, по крайней мере, я ничего не нашел). Таким образом, выбор одного пути - лучший вариант для обеспечения единообразия во всем приложении, независимо от того, ссылаетесь ли вы на макеты или поля, на которые ссылаются идентификаторы.
Юрий,

Просто для любопытства: у вас есть ссылка, где Google противоречит, то есть где они использовали нотацию верблюжьего регистра для идентификаторов?
Юрий

6
Чтобы еще больше запутать ситуацию, имена стилей (которые похожи на идентификаторы стилей) в шаблонах проектов используют PascalCase, например AppBaseThemeи AppTheme.
Эдвард Брей

4
Метод подчеркивания обычно считается гораздо менее читаемым в командах, в которых я участвовал. Несколько странное ограничение имен файлов ресурсов, которым не разрешается указывать в случае с верблюжьими буквами, не должно загрязнять ваше мышление для остальных интерфейсов Java - camelCase прочно укоренился, и я не думаю, что кто-то поблагодарил бы вас за использование нового стиля "_" в соглашениях об именах.
RichieHH

3
@RichardRiley Я нахожу это интересным, так как с подчеркиванием границы слов определены правильно, в то время как с верблюжьим регистром они сжимаются вместе, поэтому мне легче анализировать имена, разделенные подчеркиванием, чем имена с верблюжьим регистром.
JAB

13

Если вы посмотрите на android.R.id.*поля, вы заметите, что все они в верблюжьем футляре. Так что, если идентификаторы android написаны в верблюжьем кейсе, я думаю, мы должны следовать этому соглашению :)


Они там находятся в верблюжьем футляре, потому что были созданы в camelCase. Это не создает прецедента стиля кодирования для сообщества в целом и не связано с соглашениями об именах файлов ресурсов и строками идентификаторов, о которых спрашивает исходный плакат.
RichieHH

3
Да, они были созданы в верблюжьем футляре. Но эти идентификаторы взяты из самого API Android, поэтому, если создатель API использовал случай верблюда, я думаю, это хороший подход, чтобы следовать его соглашению.
Кирилл Александров

8
есть widget_frameполе [ developer.android.com/reference/android/R.id.html#widget_frame] также в android.R.id.*полях. в этом поле Google использует подчеркивание, а не верблюжий регистр. Итак, ваш вывод о соглашении с верблюжьим регистром - правильный выбор для соглашения об идентификаторе может быть ложным
Ахмед Хамди

4

Я думаю, будет хорошо, если мы будем использовать все строчные буквы с подчеркиванием.

Просто посмотрите на это (добавление к тому, что ответил Даниэль)

  // Camel Case
    TextView tvUserName = (TextView) findViewById(R.id.tvUserName);
    // Small Caps and Underscores
    TextView tvUserName = (TextView) findViewById(R.id.tv_user_name);

по моему собственному опыту, я склонен немного запутаться в соглашении о случае верблюда в xml, потому что, когда вы связываете его с Java, который также использует случай верблюда (потому что это стандарт), он выглядит как доппельгангер.


Это очень субъективно и не отвечает на вопрос о том, почему вы не можете так же именовать файлы ресурсов, как вы можете идентифицировать строки.
RichieHH

3

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


3

Если вы посмотрите на некоторые из примеров приложений Google, например:

https://github.com/google/iosched

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


3
android:id="@+id/frag_account_button"
frag_account_button = ((ListView)view.findViewById(R.id.frag_account_button));

android:id="@+id/fragAccountButton"
fragAccountButton = ((ListView)view.findViewById(R.id.fragAccountButton));

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

  1. Переменную легко найти, выполнив поиск проекта как на стороне XML, так и на стороне java.

  2. Определение библиотеки butterKnife

    @BindView (R.id.infoTextView) TextViewFont infoTextView;

Так будет лучше.


3
Привязка представления Kotlin возвращает то же самое, что и butterKnife, поэтому я полностью отбрасываю snake_case.
Рик Мартинс

1

Имена файлов xml (которые используются в папке с возможностью переноса) должны быть полностью строчными буквами, разделенными символом подчеркивания _, поскольку имена файлов с заглавной буквы не поддерживаются в xml.


1
Речь идет не об именах файлов, и, кроме того, некоторые люди предпочитают не использовать первую букву с заглавной буквы при использовании верблюжьего регистра.
Джеспер

Это странная непоследовательная проблема, ИМО. У вас не может быть чувствительности к регистру, чтобы различать, нет, но почему бы просто не запретить файлы ресурсов с одинаковым именем корневого компонента в одном каталоге.
RichieHH


0

Если компилятор Android действительно делает то, что вы говорите, ограничивая случай верблюда (что кажется довольно странным), тогда вам следует придерживаться установленных соглашений.

Если идти против течения, это приведет только к ненужной путанице. По возможности старайтесь сохранять единообразие во всех местах.


Вы, наверное, неправильно поняли то, что я пытался сказать. Компилятор будет жаловаться, если вы поместите ресурсы, такие как файл, и напишите это в верблюжьем случае. Однако в другом случае вы указываете идентификаторы в файлах макета XML. Там у вас есть возможность разместить имена идентификаторов в верблюжьем регистре, и эмулятор работает нормально. Как я уже упоминал, все образцы Google имеют форму my_id_name, но есть много других образцов, имеющих имена идентификаторов из верблюжьего регистра ...
Юрий
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.