Соглашение об именах для виджетов Android

Question

Я думаю, что официальные code style guidelines из Google очень полезны, но они не охватывают соглашения об именах для элементов вида.

Предположим, мы простоем, который содержит один ImageView, один TextView и Button. Код будет выглядеть следующим образом:

class SimpleActivity extends Activity { 

    private ImageView mImageView; 
    private TextView mTextView; 
    private Button mButton; 
} 

Конечно, мы не будем давать такие имена для виджетов, потому что они не являются описательными. Мы должны знать функции этих виджетов. Итак, давайте представим, что ImageView представляет изображение профиля пользователя, TextView представляет имя пользователя, а кнопка представляет кнопку продолжения.

я бы разделил возможные соглашения о присвоении имен в трех категориях:

1.

class SimpleActivity extends Activity { 

    private ImageView mUserProfileImageView; 
    private TextView mUsernameTextView; 
    private Button mContinueButton; 
} 

Большое преимущество первых конвенций является то, что при использовании членов в коде, мы знаем, что это TextView и мы например, может использовать метод setText(). К сожалению, имя очень длинное, потому что ленивый программист - хороший программист, это недостаток.

2.

class SimpleActivity extends Activity { 

    private ImageView mUserProfileImage; 
    private TextView mUsernameText; 
    private Button mContinueButton; 
} 

Здесь мы смешали конвенции, мы до сих пор знаем, что вид виджетов это при использовании где-то в коде, но, может быть, когда у нас есть более сложные функции виджетов эти имена были бы еще слишком долго?

3.

class SimpleActivity extends Activity { 

    private ImageView mUserProfile; 
    private TextView mUsername; 
    private Button mContinue; 
} 

ленивые категории.

Вопрос

Какие соглашения именования вы используете в коде и что ваш опыт? Может быть, есть лучшие соглашения, о которых я не упоминал? Какое соглашение Google использует?

Answer 1

Прежде всего, префикс 'm' используется в исходном коде AOSP. Он не предназначен для использования в качестве приложения в приложениях Android, поэтому я предлагаю вам его удалить (вы можете прочитать немного больше here).

Ваш третий вариант устраняется первым; например, mContinue может быть легко логической переменной, которая представляет, продолжать ли что-то делать, поэтому она определенно не очень читаема.

Между первым вариантом и вторым я по-прежнему буду первым, так как он значительно читабельнее, и, как правило, в ООП читаемость важнее коротких имен. Кроме того, если вы переместите методы настройки и привязки данных к другим классам, у вас будет минимальное количество ссылок в коде операции.