当前位置：文江博客话题详情

是否有关于如何命名资源的约定？

发布于 2024-11-30 22:26:38 字数 42 浏览 1 评论 0原文

Android 中是否有命名资源的约定？例如，按钮、文本视图、菜单等。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

内心旳酸楚 2024-12-07 22:26:38

Android SDK 将是一个很好的起点。

例如，我尝试在活动中确定 ID 的范围。

如果我有一个 ListView，它在所有活动中都将是 @android:id/list。
但是，如果我有两个列表，那么我会使用更具体的 @id/list_apple 和 @id/list_orange

因此，通用 (ids, ...) 会在R.java 文件，而唯一的文件（有时会重用）则以通用文件为前缀由下划线分隔。

下划线是一回事，我观察到，例如：

布局宽度是 xml 中的 layout_width 和 code 中的 layoutWidth ，所以我尝试将其保留为 list_apple

因此，登录按钮将是 login，但是如果我们有两个登录，则 login_foo 和登录栏。

回复收藏 0 原文

送你一个梦 2024-12-07 22:26:38

不知道官方有没有推荐。

对于带有小部件和容器的布局中的 id，我使用约定：

<layout>_<widget/container>_<name>

我对在这些布局中使用的任何尺寸、字符串、数字和颜色执行相同的策略。不过，我确实尝试进行概括。例如，如果所有按钮都有一个共同的 textColor，我不会在名称前加上布局前缀。资源名称为“button_textColor”。如果所有 textColors 使用相同的资源，它将被命名为“textColor”。对于样式来说，通常也是这种情况。

对于我使用的菜单资源：

menu_<activity>_<name>

动画只是不同，因为不能使用大写字母。我相信，drawable xml 资源也是如此。

I don't know whether there are any official recommendations.

For ids in my layouts with widgets and containers, I use the convention:

<layout>_<widget/container>_<name>

I do the same strategy for any dimens, strings, numbers, and colors I use in those layouts. However, I do try generalizing. e.g if all buttons have a common textColor, I won't prefix the name with the layout. The resource name would be 'button_textColor'. If all textColors are using the same the resource it will be named 'textColor'. For Styles, this is usually the case as well.

For menu resources i use:

menu_<activity>_<name>

Animations are only different as you cannot use uppercase letters. Same goes for drawable xml resources, i believe.

回复收藏 0 原文

内心荒芜 2024-12-07 22:26:38

摘自 Android 文档。关于这个主题还有更多内容。

回复收藏 0 原文

稚气少女 2024-12-07 22:26:38

回答你的问题：是的，有。

例如，您可以通过 google 搜索找到其中的许多内容。并且不存在所谓的最佳命名约定。它始终取决于您的需求和项目属性（最重要的是范围）。

最近，我阅读了关于 Android XML 中资源命名的很好的博客文章来自杰罗恩·莫尔斯。作者提到了所有资源应遵循的基本原则，以及如何将此约定应用于每种资源类型。两者均在 Android 资源命名备忘单中进行了描述：

然后，他详细描述了每个元素和每种资源类型。

我想说，您可以在中小型项目（个人使用、几个月的合同应用程序）中使用此约定。不过，我不建议将其用于具有 50 多个活动或 1000 多个字符串的长期项目。

如此大规模的项目中的资源价值约定需要对如何使用它们进行更多调查。以字符串为例。可能会受到您的团队规模、您正在使用的翻译中心（如果有）、您的 VCS 的影响正在使用（例如避免合并冲突）等。您甚至可能会考虑将字符串拆分为多个文件。

我假设您正在寻找一些东西。所以我会推荐我提到的博客文章。它对初学者来说很有好处，您绝对可以用它作为灵感来创建自己的良好命名约定。

另请记住，随着项目的发展，许多需求和要求可能会及时发生变化。所以一开始适合的命名规则在两年后就不适合了，这是完全正常的。而且完全没问题。你不应该试图预测未来。只需选择一个惯例并遵循它即可。您会发现它是否适合您和您的项目。如果不适合，请思考为什么不适合并开始使用其他东西。

回复收藏 0 原文

明月夜 2024-12-07 22:26:38

资源中使用了一些约定：

对于作为单独文件存在的资源，它们必须以小写下划线分隔。 appt 工具确保您的文件仅是小写，因为使用混合大小写可能会导致不区分大小写的文件系统出现问题。
对于仅在值/...（属性、字符串等）中声明的资源，约定通常是混合大小写。
有时使用一种约定来用“分类”来标记名称以具有简单的名称空间。例如，您可以在其中看到诸如layout_width和layout_alignLeft之类的内容。在布局文件中，视图和父布局管理的属性混合在一起，即使它们是不同的所有者。 “layout_*”约定确保这些名称之间不存在冲突，并且很容易理解名称影响哪个实体。

这个“layout_blah”约定也被用在其他一些地方。例如，有“state_blah”属性，它们是视图可以具有的可绘制状态。

另外，由于这两个约定（文件下划线分隔，声明资源混合大小写），您会发现许多不一致之处。例如，可以使用文件或显式值来声明颜色。一般来说，我们希望对所有这些都坚持使用下划线分隔，但这并不总是发生。

最终，我们不必太担心资源的命名约定。我们保持一致的一大特点是属性的“mixedCase”，以及使用“layout_blah”来标识布局参数属性。

另外，浏览此处的公共资源应该可以很好地了解这些约定：

http://developer.android.com/ Reference/android/R.html

你会看到属性都非常一致（假设你了解layout_约定），drawables都是下划线分隔的，等等。

回复收藏 0 原文

岁月如刀 2024-12-07 22:26:38

对于任何语言或框架来说，这都是一个常见问题，但是只要您避免使用保留字，假设您可以记住您所说的事物，那就应该没问题。

我确实注意到 Android 对 xml 资源文件名进行了限制，但下划线似乎没问题。 ADT 实际上指出

基于文件的资源名称只能包含小写 az、0-9 或 _。

一开始让我困惑的是缺乏带有 id 的命名空间，但如果你有两个 id，那么通常可以忽略这一点，同一个 Android 只会重用定义的 id。

对于 id，我使用 3 个字母的限定符，后跟它在驼峰表示法中所指的内容，例如 lblFoo 表示静态文本标签（或文本视图），txtFoo 表示可编辑文本框（Android 中的 edittext）。起初这可能看起来很奇怪，但自从 VB6 以来我一直在使用它，这些控件称为标签和文本框。

以下是我常用的一些：

btnFoo - 按钮
pwdFoo - 密码
lstFoo - 列表
clrFoo - 颜色
tblFoo - 表
colFoo - 列
rowFoo - 行
imgFoo - 图像
dimFoo - 维度
padFoo - 填充
mrgFoo - margin

我在 java 中的代码中使用相同的文件，所以我不必考虑它，包范围将非常高兴地允许这一点：

Button btnFoo = (Button)findViewById(R.id.btnFoo);

如果您喜欢使用下划线即 btn_foo 添加一点间距，您可以...我可能如果我能改掉旧习惯，我就会这么做。

有些人可能会认为缩写这些可能并不理想，而纯粹主义者会认为应该使用全名，但是当您命名数十个控件并在不同的系统和框架之间进行更改时，全名就失去了意义，我已经在 VB、C++、ASP.NET、C# 和 VB.NET、Android 和 Python 中的 WinForms 中使用它们十多年了。我永远不需要记住 Android 是否将其称为文本框或编辑文本。我需要知道的是 lblFoo 是静态标签，txtFoo 是用户输入的内容。

最后一点是，无论您决定采用哪种约定，重要的是正确且一致地命名控件，这样您就不会与模糊的默认 id 发生冲突，例如 TextView5 或不同约定的混合

This is a common problem to any language or framework, but so long as you avoid reserved words you should be ok assuming you can remember what you have called things.

I did note that Android places a restrction on xml resource file names but underscores seem to be ok. ADT actually states

File-based resource names must contain only lowercase a-z, 0-9, or _.

Something that tripped me up at first was a lack of namespaces with id's, but this can generally be ignored if you have two id's the same Android will just reuse the defined id.

For id's I use a 3 letter qualifier followed by what it refers to in camel notation e.g lblFoo for a static text label (or textview), txtFoo for an editable textbox (edittext in Android). This may seem odd at first but I've been using it since VB6 and those controls were called label and textbox.

Here are some more I commonly use:

btnFoo - button
pwdFoo - password
lstFoo - list
clrFoo - color
tblFoo - table
colFoo - column
rowFoo - row
imgFoo - image
dimFoo - dimension
padFoo - padding
mrgFoo - margin

I use the same in code within the java file too so I don't have to think about it, package scope will allow this quite happily:

Button btnFoo = (Button)findViewById(R.id.btnFoo);

You could if you prefer add a little spacing using underscore i.e btn_foo ... I probably would do this if I could break old habits.

There are those who may argue that abbreviating these may not be ideal and the purists would argue that the full name should be used, but when you are naming dozens of controls and changing between different systems and frameworks, the full names lose their meanings, I have used these for over a decade in VB, C++, ASP.NET, WinForms in C# and VB.NET, Android and Python. I never need to remember if Android calls it a textbox or an edittext. All I need to know is that lblFoo is the static label and txtFoo is what the user types input into.

One final note is that no matter what convention you decide upon the important things is naming controls properly and consistently, so that you don't wrestle with vague default id's e.g TextView5 or a mixture of different conventions

回复收藏 0 原文

执手闯天涯 2024-12-07 22:26:38

对设计师和开发人员有用的链接 - 此处

尺寸和尺寸、命名约定、风格和主题、九个补丁等等。

回复收藏 0 原文

岁月蹉跎了容颜 2024-12-07 22:26:38

我不认为谷歌提倡任何标准约定。我见过人们命名事物的各种不同方式，甚至在不同的官方 Google 应用程序中也是如此。

当您尝试理解一个目录层次结构中的 100 个布局（或可绘制对象、菜单等）文件时，什么对您最有帮助。

回复收藏 0 原文

雅心素梦 2024-12-07 22:26:38

简短的回答：如果您想向 Android 开发人员学习，一个很好的例子是支持库 v7 (https://dl-ssl.google.com/android/repository/support_r21.zip）

否则，这是我考虑的命名资源的方法：
1.编写代码时轻松查找资源
2.阅读代码轻松理解资源
3. 使名称对翻译人员有用（仅限R.string.* 资源）
4. 通过重用布局（R.id.* 资源冲突）
5. 处理库项目

从逻辑上讲，安排资源应该与将 java 类分组到包中（或将文件放入文件夹中）没有什么不同。但是，由于 Android 资源没有命名空间，因此必须在资源名称中添加前缀才能实现相同的效果（例如，com.example.myapp.photo 变为 com_example_myapp_photo）。

我建议将应用程序划分为单独的组件（活动、片段、对话框等），并使用可用作资源前缀的简短唯一名称。通过这种方式，我们将具有相关功能的资源分组在一起，这使得它们很容易找到（第 1 点），同时我们也避免了与和图书馆项目（第 4 点和第 5 点）。请注意，多个组件共用的资源仍然可以具有前缀（例如R.string.myapp_ok_button）。

前缀之后，名称应该告诉我们资源的用途（要执行的操作、要显示的内容等）。选择一个好名字对于理解很重要（第 2 点和第 3 点）。

有时“component_name”会给我们足够的信息，如果类型已经由 R 类给出（在 R.string.myapp_name_string 中，第二个“string”是多余的），则尤其如此。然而，显式添加类型可以提高理解（例如，它有助于翻译人员区分 toast 或标签）。有时，可以交换“名称”和“类型”部分以允许基于类型的过滤（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

A short answer: if you would like to learn from Android developers, a good example is the support library v7 (https://dl-ssl.google.com/android/repository/support_r21.zip)

Otherwise, here's what I have considered for naming resources:
1. finding resources easily when writing code
2. understanding resources easily when reading code
3. making names useful for translators (R.string.* resources only)
4. reusing layouts with <include/> (R.id.* resource conflicts)
5. dealing with library projects

Logically, arranging resources should be no different than grouping java classes into packages (or putting files into folders). However, since Android resources have no namespaces, prefixes must be added to the resource name to achieve the same (e.g. com.example.myapp.photo becomes com_example_myapp_photo).

I suggest to divide the app into separate components (activities, fragments, dialogs, etc.) with short unique names that can be used as resource prefixes. In this way we're grouping resources with related functionality together, which makes them easy to find (point 1) and we're at the same time avoiding naming conflicts with both <include/> and library projects (points 4 and 5). Note that resources common to multiple components can still have a prefix (such as R.string.myapp_ok_button).

After the prefix, the name should tell us what the resource is used for (action to be performed, content to be displayed, etc.). Choosing a good name is important for understanding (points 2 and 3).

Sometimes "component_name" will give us enough information, which is especially true if the type is already given by the R class (in R.string.myapp_name_string the 2nd "string" is redundant). However, explicitly adding type can improve understanding (e.g., it can be helpful for translators to distinguish between a toast, or a label). Sometimes the "name" and "type" parts can be swapped to allow type-based filtering (R.string.photo_menu_* will give us only menu-related items for the photo component).

Let's say we're writing an activity for taking pictures, class com.example.myapp.photo .PhotoActivity. Our resources could look like this (grouped by the component "photo"):

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

回复收藏 0 原文

缪败 2024-12-07 22:26:38

如果您翻阅 Android 的文档，会发现有各种提到“最佳实践”的内容，但肯定没有具体的规则。例如，在图标设计指南中，Google 建议使用“ ic_”前缀。

一个好的起点可能是提供资源。

如果您想了解更多信息，请深入研究 SDK 源代码/示例以及 Android 开发者博客谷歌开发人员如何做事。

回复收藏 0 原文

花心好男孩 2024-12-07 22:26:38

我发现方便的下一个字符串命名约定：

[<action>]_<object>_<purpose>

例如，clear_playlist_text、delete_song_message、update_playlist_positivebutton_text。这里的“动作”是可选的。

I found handy next naming convention for strings:

[<action>]_<object>_<purpose>

For example, clear_playlist_text, delete_song_message, update_playlist_positivebutton_text. And "action" here is optional.

回复收藏 0 原文

離殇 2024-12-07 22:26:38

我通常遵循资源 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），我遵循了这种类型 XML IDS 中视图对象（例如按钮和 EditText 等）的命名约定

：xViewTypeSpecificName

Java：mViewTypeSpecicName

当我创建复杂的布局时，上述约定使我的生活更轻松。
只是尽量让你的名字长度尽可能短，如果它们对其他合作开发者来说是可以理解和有意义的就更好了（但可能不是每次都可以），希望我的经验能帮助其他人，欢迎提出建议。

I generally followed the java naming conventions for resource ids(not for files for files) except I added "x" in front of the ids for example:

<TextView android:id="@+id/xTvName" android:layout_width="wrap_content" android:layout_height="wrap_content"></TextView>

In java
we can use it simple(we can also rememberin simple)

TextView mTvName=(TextView)findViewById(R.id.xTvName);

Here mTvName(It is in general android suggested naming conventions) and xTvName which was named in layout file as part of android TextView's Id(x meant for XML),I followed this type of naming conventions for view objects such as Buttons and EditText etc.

in XML IDS:xViewTypeSpecificName

in Java:mViewTypeSpeficName

The above conventions makes my life easier when I create complex layouts.
Just try to make your names as much as possible short in length and it is better if they are understandable and meaningful to other co-developers(but it may not possible every time),Hope that my experience will help others,suggestions are welcome.

回复收藏 0 原文

绅士风度i 2024-12-07 22:26:38

在我们的 Android 项目中，有很多组件，例如按钮、标签、文本框。如此简单的名称（例如“名称”）很难识别“名称”是标签还是文本框。主要发生在您维护由其他开发人员开发的项目时。

因此，为了避免这种混乱，我使用以下名称作为按钮文本框或标签

示例：

 btnName
 labName
 txtName
 listName

可能这对您有帮助。

In our android projects there are lots of components like buttons, labels, textboxes. So simple name like for example "name" this is very confusing to identify "name" is label or textbox. Mainly it happen when you are maintaining projects developed by some other developers.

So to avoid this kind of confusion I used following names for Buttons TextBoxes or Labels

Example :