【发布时间】：2011-11-02 04:41:16
【问题描述】：
Android 中是否有命名资源的约定？例如按钮、textViews、菜单等。
【问题讨论】：
-
好问题。作为一个相关话题，我问了whether to use custom R. or android.R.
-
维度资源我想出了these
标签： android naming-conventions android-resources
【发布时间】：2011-11-02 04:41:16
【问题描述】：
您可以阅读 google 文档以了解代码样式以了解here
【讨论】：
-
这篇文章没有关于 Android 的资源约定。
-
哦，对不起，我想我误解了你的问题。我知道对于菜单文件，您应该使用下划线来分隔单词。前任。 options_menu.xml
我认为 Google 没有推广任何标准约定。我见过人们命名事物的各种不同方式，甚至在不同的官方 Google 应用中也是如此。
在尝试理解一个目录层次结构中的 100 个布局（或可绘制对象、菜单等）文件时最能帮助您的方法。
【讨论】：
Android SDK 将是一个很好的起点。
例如，我尝试在活动中限定 ID。
如果我有一个ListView，那么在所有活动中它就是@android:id/list。
但是，如果我有两个列表，那么我会使用更具体的 @id/list_apple 和 @id/list_orange
所以泛型 (ids, ...) 在 R.java file 中被重用，而唯一的 (有时被重用) 以泛型前缀为前缀用下划线分隔。
下划线是一回事，我观察到，例如：
xml 中的布局宽度为layout_width，代码 中的布局宽度为layoutWidth，所以我尽量坚持使用list_apple
所以登录按钮将是login，但如果我们有两个登录那么login_foo和login_bar。
【讨论】：
-
很抱歉不能从您的回答中获益。它向太多目标开火，以至于我的眼睛无法快速。例如，我想知道您如何命名位于两个活动的两个不同视图中的注册按钮。
-
@StephaneEybert，您可以在组合中添加活动名称，购买为什么要访问不同活动的视图。 :)
-
这很好，很简单，它使 xml 代码干净。但是，如果您正在尝试调试某个大型应用程序，那么尝试跟踪五十个名为“关闭”的不同按钮可能会令人沮丧。我非常更喜欢在每个视图前加上其布局的名称。
不知道有没有官方推荐。
对于带有小部件和容器的布局中的 id，我使用约定：
<layout>_<widget/container>_<name>
我对我在这些布局中使用的任何尺寸、字符串、数字和颜色执行相同的策略。但是，我确实尝试概括。例如，如果所有按钮都有一个共同的 textColor，我不会在名称前加上布局。资源名称将是“button_textColor”。如果所有 textColors 都使用相同的资源，它将被命名为“textColor”。对于 Styles，通常也是如此。
对于我使用的菜单资源：
menu_<activity>_<name>
动画只是不同，因为您不能使用大写字母。我相信，可绘制的 xml 资源也是如此。
【讨论】：
-
我这样做是为了，只是我宁愿缩短布局和小部件名称，以避免长名称，例如身份验证布局上的用户名编辑框将是：“au_eb_username”而不是“ authentication_editbox_username"
这对于任何语言或框架来说都是一个常见问题，但只要你避免使用保留字，你应该可以假设你能记住你所称的东西。
我确实注意到 Android 对 xml 资源文件名进行了限制，但下划线似乎没问题。 ADT 实际上声明了
基于文件的资源名称只能包含小写的 a-z、0-9 或 _。
起初让我感到困惑的是缺少带有 id 的命名空间，但如果您有两个 id，通常可以忽略这一点，相同的 Android 只会重用定义的 id。
对于 id，我使用 3 个字母的限定符，后跟它在骆驼表示法中所指的内容，例如 lblFoo 用于静态文本标签（或 textview），txtFoo 用于可编辑文本框（Android 中的 edittext）。起初这可能看起来很奇怪，但我从 VB6 开始就一直在使用它，这些控件被称为标签和文本框。
以下是我常用的一些：
- btnFoo - 按钮
- pwdFoo - 密码
- lstFoo - 列表
- clrFoo - 颜色
- tblFoo - 表
- colFoo - 列
- rowFoo - 行
- imgFoo - 图片
- dimFoo - 维度
- padFoo - 填充
- mrgFoo - 边距
我在 java 文件中的代码中也使用了相同的代码，所以我不必考虑它，包范围会很高兴地允许这样做：
Button btnFoo = (Button)findViewById(R.id.btnFoo);
如果您更喜欢使用下划线添加一点间距，例如 btn_foo，您可以这样做...如果我可以打破旧习惯，我可能会这样做。
有些人可能会认为缩写这些可能并不理想，而纯粹主义者会认为应该使用全名，但是当您命名数十个控件并在不同的系统和框架之间进行更改时，全名会失去它们的意义意思是，我在 VB、C++、ASP.NET、C# 和 VB.NET 中的 WinForms、Android 和 Python 中使用了十多年。我永远不需要记住 Android 是否将其称为文本框或编辑文本。我只需要知道 lblFoo 是静态标签，而 txtFoo 是用户输入的内容。
最后要注意的是，无论您决定什么约定，重要的事情都是正确且一致地命名控件，这样您就不会与模糊的默认 id 搏斗，例如 TextView5 或不同约定的混合
【讨论】：
有一些限制：
- 资源名称应包含 a-z,0-9,_
- 资源名称应以 a-z,_ 开头
顺便说一句，最好遵循指南或从标准代码中学习。
【讨论】：
资源中使用了一些约定：
- 对于作为单独文件存在的资源，它们必须小写_下划线_分隔。 appt 工具可确保您的文件仅为小写，因为使用混合大小写可能会导致不区分大小写的文件系统出现问题。
- 对于仅在 values/...（属性、字符串等）中声明的资源，约定通常是混合大小写。
- 有时使用一种约定来标记带有“分类”的名称以具有简单的命名空间。例如，您可以在其中看到 layout_width 和 layout_alignLeft 之类的内容。在布局文件中，视图和父布局管理的属性混合在一起，即使它们是不同的所有者。 “layout_*”约定确保这些名称之间没有冲突，并且很容易理解该名称会影响哪个实体。
这种“layout_blah”约定也已在其他一些地方使用。例如，“state_blah”属性是视图可以具有的可绘制状态。
同样由于这两种约定（文件用下划线分隔，声明资源用混合大小写），您会发现许多不一致之处。例如，颜色可以用文件或显式值声明。一般来说，我们希望对所有这些都坚持使用 underscore_separated，但并不总是这样。
最终，我们不必担心资源的命名约定。我们保持一致的一个重要方面是属性的“mixedCase”，以及使用“layout_blah”来识别布局参数属性。
此外，浏览这里的公共资源应该可以很好地了解这些约定：
http://developer.android.com/reference/android/R.html
您会看到属性都非常一致（假设您了解 layout_ 约定），drawables 都是下划线分隔的，等等。
【讨论】：
如果您翻阅 Android 的文档，就会发现各种“最佳实践”的提及，但肯定没有具体的规则。例如，在Icon Design Guidelines 中，Google 建议使用“ic_”前缀命名图标。
一个好的起点可能是Providing Resources。
如果您想了解 Google 开发人员的工作方式，还可以浏览 SDK 源代码/示例以及 Android Developers Blog。
【讨论】：
我通常遵循资源 id 的 java 命名约定（不是文件的文件），除了我在 id 前面添加了“x”，例如：
<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>
在java中 我们可以简单地使用它（我们也可以简单地记住）
TextView mTvName=(TextView)findViewById(R.id.xTvName);
这里是 mTvName（通常是 android 建议的命名约定）和 xTvName，它在布局文件中被命名为 android TextView 的 Id（x 表示 XML）的一部分，我遵循这种类型的视图对象命名约定，例如 Buttons 和编辑文本等
在 XML IDS 中：xViewTypeSpecificName
在 Java 中：mViewTypeSpecficName
当我创建复杂的布局时，上述约定让我的生活更轻松。 尽量让你的名字尽量简短，如果它们对其他共同开发者来说是可以理解和有意义的（但可能不是每次都可能），希望我的经验对其他人有所帮助，欢迎提出建议。
【讨论】：
取自Android's documentation。关于这个主题还有更多内容。
【讨论】：
-
我的两分钱：我不喜欢 ic 前缀
-
"请注意，您不需要使用任何类型的共享前缀 — 这样做只是为了您的方便。"这是该图表下方的线。所以前缀是选择的问题。
-
纯字符串的命名约定是什么？我在我的应用程序中使用了大约 30000 个字符串。真是令人难以置信。
在我们的 android 项目中，有很多组件，例如按钮、标签、文本框。如此简单的名称，例如“名称”，很难识别“名称”是标签或文本框。主要发生在您维护由其他开发人员开发的项目时。
所以为了避免这种混淆，我为按钮文本框或标签使用了以下名称
例子：
btnName
labName
txtName
listName
也许这对你有帮助。
【讨论】：
对设计师和开发人员有用的链接 - here
尺寸和大小、命名约定、样式和主题、九个补丁等等。
【讨论】：
简短回答：如果您想向 Android 开发人员学习，一个很好的例子是支持库 v7 (https://dl-ssl.google.com/android/repository/support_r21.zip)
否则，这是我为资源命名所考虑的：
1. 编写代码时轻松查找资源
2. 阅读代码时容易理解资源
3. 使名称对翻译人员有用（仅限R.string.* 资源）
4. 使用<include/>重用布局（R.id.*资源冲突）
5. 处理图书馆项目
从逻辑上讲，安排资源应该与将 java 类分组到包中（或将文件放入文件夹）没有什么不同。但是，由于 Android 资源没有命名空间，因此必须在资源名称中添加前缀才能达到相同的效果（例如，com.example.myapp.photo 变为 com_example_myapp_photo）。
我建议将应用程序分成单独的组件（活动、片段、对话框等），并使用可用作资源前缀的简短唯一名称。通过这种方式，我们将具有相关功能的资源组合在一起，这使得它们易于查找（第 1 点），同时我们避免了与 <include/> 和库项目的命名冲突（第 4 点和第 5 点）。请注意，多个组件共有的资源仍然可以有前缀（例如R.string.myapp_ok_button）。
在前缀之后，名称应该告诉我们资源的用途（要执行的操作、要显示的内容等）。选择一个好名字对于理解很重要（第 2 点和第 3 点）。
有时“component_name”会为我们提供足够的信息，如果类型已经由 R 类给出，则尤其如此（在R.string.myapp_name_string 中，第二个“字符串”是多余的）。但是，显式添加类型可以提高理解能力（例如，有助于翻译人员区分 toast 或 label）。有时可以交换“名称”和“类型”部分以允许基于类型的过滤（R.string.photo_menu_* 将只为我们提供照片组件的菜单相关项）。
假设我们正在编写一个用于拍照的活动，类 com.example.myapp.photo .PhotoActivity。我们的资源可能看起来像这样（按组件“照片”分组）：
R.layout.photo //if only a single layout is used
R.menu.photo
R.string.photo_capture_instructions_label
R.id.photo_capture_instructions_label
R.id.photo_capture_button
R.id.photo_capture_image
R.drawable.photo_capture_placeholder
R.dimen.photo_capture_image_height
【讨论】：
我找到了方便的下一个字符串命名约定：
[<action>]_<object>_<purpose>
例如，clear_playlist_text、delete_song_message、update_playlist_positivebutton_text。而这里的“动作”是可选的。
【讨论】：
回答你的问题：是的，有。
例如，您可以通过google search 找到其中许多。并且没有最好的命名约定。它始终取决于您的需求和项目属性（最重要的是范围）。
最近，我从 Jeroen Mols 阅读了关于 Android XML 中命名资源的很好的 blog post。作者提到了所有资源都应遵循的基本原则，以及如何将此约定应用于每种资源类型。两者都在Android resource naming cheat sheet 上进行了描述：
然后他详细描述了每个元素和每个资源类型。
我想说，您可以在中小型项目（个人使用、几个月的合同申请）中使用此约定。虽然，我不建议将它用于具有 50 多个活动或 1000 多个字符串的长期项目。
如此大规模的项目中的资源价值约定需要对它们的使用方式进行更多调查。以字符串为例。可能会受到团队规模、您正在使用的翻译中心（如果有）、VCS 您正在使用（例如为了避免合并冲突）等的影响。您甚至可以考虑将字符串拆分为多个文件。
我假设您正在寻找开始的东西。所以我会推荐我提到的博客文章。这对初学者很有用，您绝对可以将其作为灵感来创建自己的良好命名约定。
另外请记住，随着项目的发展，许多需求和要求可能会随时间发生变化。因此，一开始适合的命名约定在 2 年后不适合是完全正常的。而且完全没问题。你不应该试图预测未来。只需选择一个约定并遵循它。您会发现它是否适合您和您的项目。如果不合适，想想为什么它不合适，然后开始使用其他东西。
【讨论】：