关于如何命名资源有约定吗?

Are there conventions how to name resources in Android? For example, buttons, textViews, menus, etc.

Android中有命名资源的惯例吗?例如，按钮、文本视图、菜单等。

15 个解决方案

#1

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

我不知道是否有任何官方的建议。

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

对于包含小部件和容器的布局中的id，我使用以下约定:

<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.

对于我在这些布局中使用的任何调光器、字符串、数字和颜色，我都采用相同的策略。然而，我确实尝试过归纳。e。如果所有的按钮都有一个通用的textColor，我不会在名称前面加上布局。资源名称将是“button_textColor”。如果所有的textColor都使用相同的资源，它将被命名为“textColor”。对于样式，通常也是如此。

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.

动画的不同之处在于不能使用大写字母。我认为，可绘制xml资源也是如此。

#2

Android SDK will be a good place to start.

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

For example, I try to scope IDs within the activity.

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

If I had a ListView it simply would be @android:id/list in all the activities.
If, however, I had two lists then I would use the more specific @id/list_apple and @id/list_orange

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

So generic (ids, ...) gets reused in the R.java file while the unique ones (sometimes gets reused) get prefixed with generic ones separated by an underscore.

所以泛型(id，…)在R中被重用。当惟一的文件(有时会被重用)以泛型文件为前缀，并用下划线分隔。

---

The underscore is one thing, I observed, for example:

我观察到，下划线是一件事:

Layout width is layout_width in xml and layoutWidth in code, so I try to stick to it as list_apple

布局宽度在xml中是layout_width，在代码中是layoutWidth，所以我尽量把它当作list_apple。

So a Login button will be login, but if we have two logins then login_foo and login_bar.

登录按钮是Login，但是如果我们有两个登录，那么login_foo和login_bar。

#3

Taken from Android's documentation. There is more there on the subject.

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

#4

There are a few conventions used in resources:

参考资料中使用了一些公约:

• For resources that exist as separate files, they must be lower_case_underscore_separated. The appt tool makes sure that your files are only lower-case, because using mixed case can cause issues on case-insensitive filesystems.
• 对于作为独立文件存在的资源，它们必须是lower_case_underscore_separated。appt工具确保您的文件只是小写，因为使用混合大小写可能会导致不区分大小写的文件系统出现问题。
• For resources declared only in values/... (attributes, strings, etc) the convention is generally mixedCase.
• 对于仅以值/…声明的资源(属性、字符串等)约定通常是混合的。
• There is a convention used sometimes to tag names with a "classification" to have simple namespaces. This is for example where you see things like layout_width and layout_alignLeft. In a layout file the attributes for both the View and the parent layout management are mixed together, even though they are different owners. The "layout_*" convention ensures that there are no conflicts between these names and it is easy to understand which entity the name impacts.
• 有一种惯例，有时使用“分类”来标记名称，以拥有简单的名称空间。例如，您可以看到layout_width和layout_alignLeft之类的内容。在布局文件中，视图和父布局管理的属性混合在一起，即使它们是不同的所有者。“layout_*”约定确保这些名称之间没有冲突，并且很容易理解名称影响的实体。

This "layout_blah" convention has also been used in a few other places. For example, there are "state_blah" attributes which are the drawable states a view can have.

这种“layout_blah”约定也在其他一些地方使用过。例如，有“state_blah”属性，这些属性是视图可以拥有的可绘制状态。

Also because of these two conventions (underscore_separated for files, mixedCase for declared resources), you will find a number of inconsistencies. For example colors can be declared with either files or as explicit values. Generally we'd like to stick with underscore_separated for all of those, but it doesn't always happen.

由于这两种约定(文件的underscore_separate，声明的资源的mixedCase)，您将发现许多不一致之处。例如，颜色可以用文件或显式值声明。一般来说，我们都希望使用underscore_apart，但是这种情况并不总是会发生。

Ultimately we don't worry a whole lot about naming conventions for resources. The big one that we keep consistent is "mixedCase" for attributes, and the use of "layout_blah" to identify layout param attributes.

最后，我们不太担心资源的命名约定。我们保持一致的一个重要方面是属性的“mixedCase”，以及使用“layout_blah”标识布局param属性。

Also browsing through the public resources here should give a good feel for the conventions:

浏览这里的公共资源，也会让你对这些惯例有个好印象:

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

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

You'll see the attributes are all quite consistent (given you understand the layout_ convention), drawables are all underscore_separated, etc.

您将看到所有的属性都是相当一致的(考虑到您了解layout_约定)，drawables都是underscore_separated，等等。

#5

To answer your question: Yes, there are.

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

You can find many of them via google search for example. And there is no such thing as the best naming convention. It always depends on your needs and your project attributes (most importantly the scope).

你可以通过谷歌搜索找到他们中的很多。没有最好的命名规则。它总是取决于您的需求和项目属性(最重要的是范围)。

---

Recently, I've read quite good blog post about naming resources in Android XML from Jeroen Mols. Author mentions the basic principle all resources should follow and then how this convention is applied to each resource type. Both described on Android resource naming cheat sheet:

最近，我从Jeroen Mols上读到了一篇关于在Android XML中命名资源的很好的博客文章。作者提到了所有资源应该遵循的基本原则，以及如何将该约定应用于每种资源类型。都在Android资源命名备忘单中描述:

He then describes each element and each resource type in detail.

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

---

I would say you could use this convention from small to medium projects (personal use, few months contract applications). Although, I would not recommend it for long time projects with like 50+ activities or 1000+ strings.

我想说，您可以使用这个约定从小型到中型项目(个人使用，几个月的合同申请)。虽然，我不会推荐它用于长期项目，比如50+活动或1000+字符串。

Conventions for resource values in projects of such a large scale requires more investigation on how they will be used. Take strings for example. Might be affected by size of your team, translation center you are using (if any), VCS you are using (to avoid merge conflicts for example), etc. You might even think about splitting strings into multiple files.

在如此大规模的项目中，资源价值的约定需要更多地研究如何使用它们。以字符串为例。可能会受到您的团队规模、您正在使用的翻译中心(如果有的话)、您正在使用的VCS(例如，为了避免合并冲突)等的影响。

I assume you are looking for something to begin with. So I would recommend the blog post I mentioned. It's good for starters and you can definitely use it as inspiration to create good naming conventions of your own.

我猜你一开始是在找什么。所以我推荐我提到的博客文章。这对初学者来说很好，你可以用它作为灵感来创建自己的好命名习惯。

Also keep in mind that as a project grows, many needs and requirements may change in time. So its completely normal that naming conventions that were suitable in the beginning will not be suitable after 2 years. And it's completely fine. You should not try to predict future. Just choose a convention and follow it. You will find if it is suitable for you and your project. If its not, think about why it is not suitable and start using something else.

还要记住，随着项目的发展，许多需求和需求可能会随着时间的变化而变化。所以一开始适用的命名惯例在两年后就不适用了，这是完全正常的。这完全没问题。你不应该试图预测未来。选择一个约定并遵循它。你会发现它是否适合你和你的项目。如果不是，想想为什么它不合适，然后开始用别的东西。

#6

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

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

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

基于文件的资源名称必须只包含小写的a-z、0-9或_。

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.

一开始让我感到困惑的是缺乏带有id的名称空间，但是如果您有两个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.

对于id，我使用3个字母的限定词，后面跟着骆驼符号e。g lblFoo表示静态文本标签(或textview)， txtFoo表示可编辑的文本框(在Android中是edittext)。乍一看可能有点奇怪，但我从VB6开始就一直在使用它，这些控件被称为label和textbox。

Here are some more I commonly use:

下面是我常用的一些方法:

• btnFoo - button
• btnFoo -按钮
• pwdFoo - password
• pwdFoo——密码
• lstFoo - list
• lstFoo——列表
• clrFoo - color
• clrFoo -颜色
• tblFoo - table
• tblFoo——表
• colFoo - column
• colFoo -列
• rowFoo - row
• rowFoo -行
• imgFoo - image
• imgFoo——形象
• dimFoo - dimension
• dimFoo -维
• padFoo - padding
• padFoo——填充
• mrgFoo - margin
• mrgFoo——保证金

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:

我在java文件的代码中也使用了相同的代码，所以我不需要考虑它，包范围将很好地允许这一点:

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.

如果你喜欢用下划线来添加一个空格。e btn_foo……如果我能改掉旧习惯，我可能会这么做。

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.

有些人可能认为使用这些可能不是理想的缩写和纯粹主义者会辩称,应该使用全名,但是当你命名的控制和改变不同系统之间和框架,全名失去意义,我用这些十多年来在VB,c++,ASP。NET, WinForms (c#和VB)净,Android和Python。我从来不需要记住，如果Android称之为文本框或edittext。我只需要知道lblFoo是静态标签，txtFoo是用户输入的。

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

最后要注意的一点是，无论您决定什么约定，重要的事情都是正确和一致地命名控件，这样您就不会遇到模糊的默认ide。g TextView5或不同的约定的混合。

#7

I don't think there is any standard convention promoted by Google. I've seen all kinds of different ways people name stuff, even within different official Google apps.

我认为谷歌并没有推广任何标准约定。我看到过人们用各种不同的方式来命名东西，即使是在不同的官方谷歌应用中。

Whatever helps you the most when trying to make sense of a 100 layout (or drawables, menus, etc.) files in one directory hierarchy.

当您试图理解一个目录层次结构中的100个布局(或可绘制文件、菜单等)文件时，任何对您最有帮助的都可以。

#8

Useful link for designer and developers - here

设计人员和开发人员的有用链接-这里

Dimensions and sizes, naming conventions, styles and themes, nine-patch and so on.

尺寸和大小，命名约定，样式和主题，九块补丁等等。

#9

If you poke around in Android's documentation, there are various mentions of "best practices", but there are certainly no concrete rules. For example, in Icon Design Guidelines, Google suggests naming icons with a "ic_" prefix.

如果你仔细查看Android的文档，会发现有各种各样的“最佳实践”，但肯定没有具体的规则。例如，在图标设计指南中，谷歌建议使用“ic_”前缀命名图标。

A good place to start may be Providing Resources.

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

Also dig around in the SDK source/examples as well as on the Android Developers Blog if you want to see how the Google developers do things.

如果您想了解谷歌开发人员是如何工作的，还可以在SDK源代码/示例以及Android开发人员博客中查找。

#10

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)

简短的回答:如果您想向Android开发人员学习，一个很好的例子是支持库v7 (https://dlssl.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

否则，下面是我为资源命名所考虑的内容:1。在编写代码2时很容易找到资源。阅读代码3时容易理解资源。使名称对翻译人员有用。*只资源)4。使用 (R.id)重新使用布局。*资源冲突)5。处理库项目

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).

从逻辑上讲，安排资源应该与将java类分组到包(或将文件放入文件夹)没什么不同。但是，由于Android资源没有名称空间，因此必须将前缀添加到资源名称中以实现相同的目的(例如com.example.myapp)。照片变成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).

我建议将应用程序划分为独立的组件(活动、片段、对话框等)，并使用简短的惟一名称作为资源前缀。这样我们分组资源相关功能结合在一起,这使得他们容易找到(位置1),我们同时避免命名冲突与 <包括> 和库项目(分4和5)。请注意,多个组件的公共资源可以仍然有一个前缀(例如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).

在前缀之后，名称应该告诉我们资源用于什么(要执行的操作、要显示的内容等)。选择一个好的名字对理解很重要(第2点和第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).

有时，“component_name”将提供足够的信息，尤其是当R类(在R.string中)已经给出的类型时。myapp_name_string第二个“字符串”是冗余的)。然而，显式添加类型可以提高理解(例如，它可以帮助译者区分吐司或标签)。有时“名称”和“类型”部分可以交换，以允许基于类型的过滤(R.string)。photo_menu_*将只给我们提供与照片组件有关的项目)。

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"):

假设我们在编写一个活动，用于拍照，类com.example.myapp。.PhotoActivity照片。我们的资源可以像这样(按组件“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  

#11

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.

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

#12

you can read the google documentation for code style to get an idea here

您可以阅读有关代码样式的谷歌文档以了解这里的概念

#13

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:

我通常遵循资源id的java命名约定(不是文件的文件)，但是我在id前面添加了“x”，例如:

<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)

在java中，我们可以简单地使用它(我们也可以简单地记住)

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.

在这里，mTvName(一般是android建议的命名约定)和xTvName(在布局文件中作为android TextView的Id(x表示XML)的一部分命名)，我遵循了这种类型的命名约定，用于诸如按钮和EditText等视图对象。

in XML IDS:xViewTypeSpecificName

在XML id:xViewTypeSpecificName

in Java:mViewTypeSpeficName

在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.

当我创建复杂的布局时，上面的约定使我的生活更容易。只要尽量使你的名字尽可能短，如果它们对其他共同开发人员来说是可以理解和有意义的(但可能不是每次都能做到)，希望我的经验可以帮助其他人，建议是受欢迎的。

#14

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.

在我们的android项目中有很多组件，比如按钮、标签和文本框。所以像"name"这样的简单名字很难区分"name"是标签还是文本框。它主要发生在您维护由其他开发人员开发的项目时。

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

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

Example :

例子:

 btnName
 labName
 txtName
 listName

May be this is helpful for you.

也许这对你有帮助。

#15

There are some restrictions:

有一些限制:

1. Resource name should contains be a-z,0-9,_
2. 资源名应该包含a-z、0-9、_
3. Resource name should start with a-z,_
4. 资源名应该以a-z、_开头

By the way, it is more advisable to follow the guidelines or to learn from standard code.

顺便说一下，更明智的做法是遵循指导方针或从标准代码中学习。