java - Android 小部件的命名约定

Question

我想官方code style guidelines来自谷歌的非常有用，但它们不包括 View 元素的命名约定。

假设我们有一个简单的 Activity，它包含一个 ImageView、一个 TextView 和 Button。代码看起来像这样:

class SimpleActivity extends Activity {

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

当然我们不会为小部件起这样的名字，因为它们不是描述性的。我们应该知道这个小部件的功能。假设 ImageView 代表用户个人资料图片，TextView 代表用户名，Button 代表继续按钮。

我会将可能的命名约定分为三类:

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

首先，AOSP 源代码中使用了 'm' 前缀。 它不打算用作 Android 应用程序中的约定，因此我建议您将其删除(您可以阅读更多 here )。

你的第三个选项是第一个淘汰；例如，mContinue 可以很容易地成为一个 boolean 变量，表示是否继续做某事，因此它绝对不是很可读。

在第一个选项和第二个选项之间，我仍然会选择第一个，因为它的可读性要高得多，而且作为 OOP 中的一般规则，可读性比短名称更重要。此外，如果您将 View 的自定义和数据绑定(bind)方法移动到其他类，您将在 Activity 代码中拥有最少的引用。