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

24

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

对于IDS在我的布局与小工具和容器，我用的约定：

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

我做同样的策略，对于任何梦诗，字符串，数字和颜色我在这些布局中使用。但是，我尝试推广。例如，如果所有的按钮都有一个公共的textColor，我不会在名称前加布局。资源名称将是'button_textColor'。如果所有的textColors使用相同的资源，它将被命名为'textColor'。对于样式，这通常也是如此。

对于菜单资源使用：

menu_<activity>_<name>

动画，只有不同的，因为你不能使用大写字母。我相信，可绘制的XML资源也是如此。

来源

2011-08-30 20:30:01 Ian

+1

我这样做，只是我宁愿缩短布局和小部件名称，以避免长名称，例如身份验证布局上的用户名编辑框将是：“au_eb_username”而不是“authentication_editbox_username” –

0

你可以阅读代码风格的谷歌文档，以得到一个想法here

来源

2011-08-23 18:18:06

+9

本文对Android的资源约定没有任何意义。 – Eugene

+0

哦对不起，我想我误解了你的问题。我知道，对于菜单文件，你应该使用下划线来分隔单词。恩。 options_menu.xml –

3

我不认为这是由谷歌推动任何标准的约定。我已经看到人们用各种不同的方式命名内容，即使是在不同的官方Google应用程序中。

当试图理解一个目录层次结构中的100个布局（或可绘制，菜单等）文件时，无论如何最有帮助。

来源

2011-08-27 18:31:07

42

Android SDK将是一个很好的开始。

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

如果我有一个ListView它只是在所有的活动@android:id/list。
但是，如果我有两个列表，然后我会用更具体的@id/list_apple和@id/list_orange

所以通用（IDS，...）在R.java file得到重用，而唯一的个（有时被重复使用）获得前缀通用的用下划线分开。

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

布局宽度为layout_width在XML和layoutWidth在代码，所以我尝试坚持它作为list_apple

因此，登录按钮将为login，但如果我们有两个登录然后login_foo和login_bar。

来源

2011-08-29 03:01:32 Samuel

+2

我也使用这个约定 – Aracem

+0

我很抱歉不能从您的答案中获利。它激发太多的目标来斋戒我的眼睛。例如，我想知道你如何命名一个注册按钮，坐在两个不同的活动视图。 – Stephane

+0

@StephaneEybert，您可以在混合中添加活动名称，购买您为什么要访问不同活动的视图。 :) – Samuel

11

这是任何语言或框架的常见问题，但只要你避免保留字，你应该可以假设你能记住你所谓的东西。

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

基于文件的资源名称只能包含小写字母a-z，0-9或_。

东西绊倒了我，当初是一个缺乏与ID的命名空间，但如果你有两个ID是一样的Android只会重用定义ID这个一般可以忽略不计。

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

下面是一些我经常使用：

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

我使用相同的代码Java文件中太让我没有去想它，包范围将使这相当愉快：

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

如果你喜欢使用添加下划线即btn_foo ......我可能会做这个，如果我能BRE有点距离，你可以老习惯。有些人可能会争辩说缩写这些可能并不理想，纯粹主义者会争辩说应该使用全名，但是当您命名了许多控件并在不同的系统和框架之间进行切换时，全名将会丢失他们的含义，我已经在VB，C++，ASP.NET，C＃和VB.NET，Android和Python中使用了十多年。我从来不需要记住Android是否称它为文本框或编辑文本。我需要知道的是lblFoo是静态标签，txtFoo是用户输入的内容。

最后一点需要注意的是，无论您决定什么样的约定，重要的事情都是正确地和一致地命名控件，以避免模糊的默认ID e。克TextView5或不同的惯例

来源

2011-09-01 01:25:40 Merlin

-2

有混合物是一些限制：

资源名应该是含有AZ，0-9，_
资源名称应与AZ开始，_

顺便说一句，遵循指导或从标准代码学习更为明智。

来源

2011-09-01 07:29:19

15

有资源使用的一些约定：

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

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

也因为这两个约定（下划线分隔文件，声明资源的mixedCase），你会发现一些不一致。例如，可以使用文件或显式值来声明颜色。一般来说，我们希望坚持所有这些的underscore_separated，但它并不总是会发生。

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

另外通过公共资源浏览这里应该给出规则的一种良好的感觉：

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

你会看到属性都相当一致的（给你了解layout_约定），图形是所有下划线等

来源

2011-09-01 16:48:28 hackbod

2

如果你在Android的文档中找到了各种提及的“最佳实践”，但肯定没有具体的规则。例如，在Icon Design Guidelines中，Google建议使用“ic_”前缀命名图标。

开始的好地方可能是Providing Resources。

如果您想了解Google开发人员如何执行操作，还可以在SDK源代码/示例以及Android Developers Blog中进行深入研究。

来源

2011-09-02 03:05:44 NuSkooler

0

我通常遵循Java命名为资源ID约定（不能在档案的文件），除了我的ID前面的例子中加入“X”：

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

在java中我们可以用它简单（我们也可以rememberin简单）

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

这里mTvName（这是一般的Android建议的命名惯例）和xTvName这是在布局文件命名为机器人的TextView的ID（X意味着XML）的一部分，我跟着这个命名约定的类型视图对象，例如按钮和的EditText等

在XML IDS：xViewTypeSpecificName

在Java中

：mViewTypeSpeficName

上述约定使得当我创建复杂的布局我的生活更轻松。尽量尽量缩短你的名字，如果他们对其他合作开发者是可以理解和有意义的（但它不可能每次都是这样），希望我的经验能够帮助别人，建议也欢迎。

来源

2011-09-02 14:48:21 sunriser

23

取自Android's documentation。这个问题上还有更多。

来源

2013-01-02 09:53:29

+12

我的两分钱：我不喜欢* ic *前缀 –

+1

“请注意，您不需要使用任何类型的共享前缀，这样做只是为了您的方便。”这是该图表下方的线。所以前缀是选择的问题。 –

+0

普通字符串的命名约定是什么？我在我的应用程序中使用了大约30000个字符串。这是令人难以置信的。 – User3

0

在我们的Android项目中有很多像按钮，标签，文本框组件。如此简单的名称，如“名称”，这很容易混淆，以识别“名称”是标签或文本框。主要发生在您维护其他开发人员开发的项目时。

因此，为了避免这样的困惑我用下面的按钮文本框名称或标签

例子：

btnName 
labName 
txtName 
listName

可能这是对你有帮助。

来源

2014-04-30 14:38:01

3

有用的链接，设计师和开发商 - here

尺寸和大小，命名约定，风格和主题，九宫格等。

来源

2014-05-14 08:02:14 validcat

+0

非常好的资源！谢谢你！ –

2

一个简短的回答：如果您想从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中），则尤其如此。但是，明确添加类型可以提高理解（例如，翻译人员可以帮助区分敬酒或标签）。有时可以交换“名称”和“类型”部分以允许基于类型的过滤（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

来源

2015-03-20 14:22:47 bzu

1

我发现得心应手下一个命名约定的字符串：

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

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

来源

2015-06-17 11:24:32 andrei

14

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

例如，您可以通过google search找到其中很多。并没有最好的命名约定。它总是取决于你的需求和你的项目属性（最重要的是范围）。

最近，我读过有关blog post从吉荣莫尔斯Android的XML命名资源相当不错。作者提到了所有资源应该遵循的基本原则，然后将该约定应用于每种资源类型。上Android resource naming cheat sheet既描述：

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

我会说你可以使用这个约定从小到中等项目（个人使用，几个月的合同申请）。尽管如此，我不会推荐它用于像50+活动或1000多个字符串的长时间项目。

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

我假设你正在寻找一些开始。所以我会推荐我提到的博客文章。这对初学者很有好处，你一定可以用它作为灵感来创建你自己的优秀命名约定。

同时请记住，随着项目的增长，许多需求和需求可能会随时间而改变。因此，一开始适合的命名惯例在2年后将不合适，这是完全正常的。它完全没问题。你不应该试图预测未来。只需选择一个约定并遵循它。你会发现它是否适合你和你的项目。如果没有，请考虑为什么它不适合，并开始使用其他的东西。

来源

2016-10-05 06:18:38 arenaq

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

回答

相关问题