我想官方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 使用的是哪种约定?
最佳答案
首先,AOSP 源代码中使用了 'm' 前缀。 它不打算用作 Android 应用程序中的约定,因此我建议您将其删除(您可以阅读更多 here )。
你的第三个选项是第一个淘汰;例如,mContinue
可以很容易地成为一个 boolean 变量,表示是否继续做某事,因此它绝对不是很可读。
在第一个选项和第二个选项之间,我仍然会选择第一个,因为它的可读性要高得多,而且作为 OOP 中的一般规则,可读性比短名称更重要。此外,如果您将 View 的自定义和数据绑定(bind)方法移动到其他类,您将在 Activity 代码中拥有最少的引用。
关于java - Android 小部件的命名约定,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40202194/