リソースに名前を付ける方法には規則がありますか？

24

公式の推奨事項があるかどうかわかりません。私はこれらのレイアウトで使用するすべてのdimens、文字列、数値、および色のために同じ戦略を行う

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

：ウィジェットとコンテナと私のレイアウトで

IDの

は、私が規則を使用しています。しかし、私は一般化しようとします。たとえば、すべてのボタンに共通のtextColorがある場合は、その名前の前にレイアウトを付けることはありません。リソース名は 'button_textColor'になります。すべてのtextColorsが同じリソースを使用している場合、 'textColor'という名前になります。スタイルについては、通常これも同様です。私が使用したメニューリソースについて

：

menu_<activity>_<name>

アニメーションを使用すると、大文字を使用することはできませんとしてだけ異なっています。同じdrawable xmlリソースに行く、私は信じています。

出典

2011-08-30 20:30:01 Ian

+1

認証レイアウトのユーザ名編集ボックスは、「authentication_editbox_username」の代わりに「au_eb_username」となるように、長い名前を避けるためにレイアウトとウィジェットの名前を短くしたいだけです。 –

0

は、私はGoogleが推進任意の標準的な慣習があるとは思いません。私はさまざまな正式なGoogleアプリ内であっても、人々が名前を付けるさまざまな方法をすべて見てきました。

100のレイアウト（またはドロウアブル、メニューなど）のファイルを1つのディレクトリ階層で理解しようとするときに最も役立ちます。

出典

2011-08-23 18:18:06

+9

この記事では、Androidのリソース規約については何もありません。 – Eugene

+0

ああ申し訳ありませんが、私はあなたの質問を誤解していたと思います。メニューファイルの場合は、アンダースコアを使用して単語を区切ってください。例。 options_menu.xml –

3

を取得するために、コードスタイルのGoogleドキュメントを読むことができるボタンなど、textViews、メニュー、

出典

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の2つのログインがある場合は、となります。

出典

2011-08-29 03:01:32 Samuel

+2

私もこのコンベンションを使用します – Aracem

+0

あなたの答えから利益を得られないのは残念です。それは私の目のために速くするためにあまりにも多くのターゲットで発生します。たとえば、登録ボタンの名前を2つの異なる2つのアクティビティの2つのビューにどのように置くのだろうと思います。 – Stephane

+0

@StephaneEybert、あなたはミックスにアクティビティ名を追加することができます。なぜ、別のアクティビティのビューにアクセスしたいのですか？ :) – Samuel

11

これはどの言語やフレームワークにとっても共通の問題ですが、予約語を避ける限り、あなたは自分が何を呼び出したかを覚えていればOKです。

私は、AndroidがXMLリソースファイル名にリストアを設定することに注意しましたが、アンダースコアは大丈夫と思われます。 ADTの実際の状態

ファイルベースのリソース名には、英小文字のa〜z、0〜9、または_のみを使用する必要があります。

最初に私を引きつけたものは、IDの名前空間の欠如でしたが、同じIDを2つ持っていれば無視できます。

idの場合、私は3文字の修飾子を使用し、それにラクダ表記ではlblFoo（静的なテキストラベル（またはテキストビュー））、txtFoo（Androidではedittext）を使用します。これは最初は奇妙に思えるかもしれませんが、私はVB6以来それを使ってきました。そのコントロールはラベルとテキストボックスと呼ばれていました。

はここにいくつかのより多くの私は、一般的に使用されています

btnFoo - ボタン
pwdFoo - パスワード
lstFoo - リスト
clrFoo - カラー
tblFoo - テーブル
colFooを - 列
rowFoo - 行
imgFoo - 画像
dimFoo - 次元
padFoo - マージン

私もそう、私はそれについて考える必要はありませんjavaファイル内のコードで同じを使用する -

mrgFooをパディング、パッケージのスコープは、この非常に喜んでできるようになります：

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

あなたはアンダースコアすなわちbtn_fooを使用して少し間隔を追加することを好む場合、私はBREをできればあなたは...私はおそらくこれを行うだろうことができakの古い習慣。

これらを省略すると理想的ではないかもしれないと主張する人もいますが、純粋主義者はフルネームを使用すべきだと主張する人もいます。しかし、何十ものコントロールに名前を付け、異なるシステムとフレームワークを変更すると、その意味は、私はVB、C++、ASP.NET、C＃とVB.NET、Android、PythonのWinFormsで10年以上使ってきました。 Androidがそれをテキストボックスまたは編集テキストと呼んでいるかどうかは決して覚えておく必要はありません。私が知る必要があるのは、lblFooは静的ラベルであり、txtFooはユーザーが入力したものです。

最終的な注意点は、重要なことを決める際に、コントロールが正しく、一貫して命名されているため、漠然としたデフォルトIDと争ってはいけないということです。グラムTextView5または異なる慣習の混合物

出典

2011-09-01 01:25:40 Merlin

-2

いくつかの制限があります。 _、AZで始まる必要があり

リソース名がすべきは、AZ、0-9、_
リソース名も含まれてい
ところで、ガイドラインに従うことや標準コードから学ぶことをお勧めします。

出典

2011-09-01 07:29:19

15

リソースで使用されるいくつかの規則があります：別のファイルとして存在するリソースについては

は、彼らがlower_case_underscore_separatedする必要があります。大文字小文字を混在させると、大文字と小文字を区別しないファイルシステムで問題が発生する可能性があるため、apptツールはファイルが小文字のみであることを確認します。
値/ ...（属性、文字列など）でのみ宣言されたリソースの場合、規約は通常mixedCaseです。
単純な名前空間を持つために名前に「分類」を付けるために時々使用される規則があります。これは、たとえばlayout_widthやlayout_alignLeftのようなものが見られる場所です。レイアウトファイルでは、ビューと親レイアウト管理の両方の属性が、異なる所有者であっても混在しています。 "layout_ *"規約は、これらの名前の間に矛盾がないことを保証し、名前がどのエンティティに影響するかを容易に理解することができます。

この「layout_blah」コンベンションは、他のいくつかの場所でも使用されています。たとえば、ビューが持つことができる描画可能な状態である "state_blah"属性があります。

また、これらの2つの規則（ファイルの場合はunderscore_separated、宣言されたリソースの場合はmixedCase）によって、多くの不一致が見つかります。例えば、色はファイルか明示的な値として宣言することができます。一般的に、それらのすべてについてunderscore_separatedを使用したいと思いますが、必ずしもそうとは限りません。

最終的に私たちはリソースの命名規則について心配する必要はありません。私たちが一貫性を保つ大きなものは、属性のための "mixedCase"と、レイアウトパラメータの属性を識別するための "layout_blah"の使用です。また、ここでは公共の資源を拾い読み

は規則のために良い感じを与える必要があります。

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

あなたは属性が表示されます、すべての（あなたがlayout_慣習を理解与えられた）は非常に一貫性がある、ドローアブルがありますすべてunderscore_separatedなど

出典

2011-09-01 16:48:28 hackbod

2

Androidのドキュメントでは、「ベストプラクティス」についてさまざまな言及がありますが、具体的なルールはありません。たとえば、Icon Design Guidelinesには、「ic_」という接頭辞が付いた名前の付いたアイコンが表示されます。

開始するのに適した場所はProviding Resourcesです。

また、Googleの開発者のしくみを見たい場合は、SDKのソース/例やAndroid Developers Blogを参照してください。

出典

2011-09-02 03:05:44 NuSkooler

0

私は一般的に（ないファイル用のファイルのための）リソースIDのJavaの命名規則に従っ私は例えばIDの前にある「X」を追加除きます。java で

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

を我々はそれをシンプルな使用することができますアンドロイドのTextViewのID（xはXMLのためのもの）の一部として、レイアウトファイルで指定されたmTvName（これは、一般的なアンドロイドで命名規則が示唆される）とxTvNameここ

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

を（我々はまた、単純なrememberinことができます）、私はこれを踏襲しましたの命名規則のタイプなどのボタンとのEditTextとして、ビュー・オブジェクトのXML IDSで

：Javaで

xViewTypeSpecificName：私は複雑なレイアウトを作成するときにmViewTypeSpeficName

上記の規則は、私の人生が容易になります。あなたの名前を可能な限り短くしようとすると、他の共同開発者にとって理解して意味のある方が良いですが（毎回可能ではないかもしれません）、私の経験が他の人に助けてくれることを願っています。。

出典

2011-09-02 14:48:21 sunriser

23

出所：Android's documentation。主題にはもっと多くのものがあります。私たちのアンドロイドプロジェクトで

出典

2013-01-02 09:53:29

+12

私の2セント： * ic *プレフィックスが好きではありません –

+1

"共有プレフィックスを使用する必要はありません。あなたの便宜のためだけです。これはこのチャートの下の行です。プレフィックスは選択の問題です。 –

+0

プレーンストリングの命名規則はどのようになりますか？私は私のアプリケーションで使用する約30000の文字列を持っています。それは気が狂っている。 – User3

0

ボタン、ラベル、テキストボックスなどのコンポーネントがたくさんあります。例えば「名前」のような単純な名前は、ラベルやテキストボックスである「名前」を識別するのが非常に混乱しています。主に、他の開発者によって開発されたプロジェクトを維持しているときに起こります。

btnName 
labName 
txtName 
listName

これはあなたのための役に立つかもしれませ：だから混乱のこの種の私はボタンのTextBoxのために次の名前を使用したり

例は、ラベルを避けるために

。デザイナーと開発者のための

出典

2014-04-30 14:38:01

3

便利なリンク - here

ように規則、スタイルやテーマ、9-パッチと命名寸法やサイズ、。

出典

2014-05-14 08:02:14 validcat

+0

非常に良いリソース！ありがとう！ –

2

短い答え：あなたがAndroidの開発者から学びたい場合は、良い例が、そうでなければサポートライブラリV7（https://dl-ssl.google.com/android/repository/support_r21.zip）

で、ここで私はリソースに名前を付けるために考えられてきたものです：
1発見リソースは、簡単に翻訳するための有用な名前を作成するコード
3.（R.string.*リソースのみ）<include/>（R.id.*リソースの競合）と
4.再利用するレイアウトを読むとき
2.理解リソース簡単コードを書くとき 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の2番目の "string"は冗長です）特にそうです。ただし、明示的にタイプを追加すると、理解を深めることができます（たとえば、翻訳者がトーストやラベルを区別するのに役立ちます）。場合によっては、「名前」と「タイプ」の部分をスワップしてタイプベースのフィルタリングを行うことができます（R.string.photo_menu_*は、写真コンポーネントのメニュー関連項目のみを表示します）。

写真を撮るためのアクティビティ、クラスcom.example.myapp.photo .PhotoActivityを作成しています。私たちのリソースは、この（コンポーネント "写真" でグループ化された）のようになります。

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

例えば

、clear_playlist_text、delete_song_message、update_playlist_positivebutton_text：

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

私は、文字列のための便利な次の命名規則を発見しました。ここでの「行動」はオプションです。

出典

2015-06-17 11:24:32 andrei

14

質問に答える：はい、あります。

これらの多くは、たとえばgoogle searchで見つけることができます。そして、最高の命名規則のようなものはありません。常にあなたのニーズとプロジェクトの属性（最も重要なのはスコープ）に依存します。

最近、私はイェルーンモルからAndroidのXML内のリソースを命名についてblog postかなり良い読みました。著者は、すべてのリソースが従うべき基本原則と、各リソースタイプにこの規約がどのように適用されるかについて述べています。両方がAndroid resource naming cheat sheetで説明：

を彼が次に詳細に各要素および各リソースの種類を記載しています。

私は小規模から中規模のプロジェクト（個人用、数ヶ月契約アプリケーション）からこのコンベンションを使用することができます。しかし、私は、50 +アクティビティや1000 +文字列のような長い時間プロジェクトにはお勧めしません。

このような大規模なプロジェクトでのリソース値の表記規則では、それらの使用方法についてより多くの調査が必要です。たとえば文字列を取ります。チームのサイズ、使用している翻訳センター（ある場合）、使用しているVCSなど（マージの競合を避けるため）などの影響を受ける可能性があります。文字列を複数のファイルに分割することも考えられます。

私はあなたが何かを探していると仮定します。だから、私が言及したブログ記事をお勧めします。初心者には良いことですが、あなた自身の良い命名規則を作成するために、それをインスピレーションとして間違いなく使うことができます。

プロジェクトが成長するにつれて、多くのニーズと要件が時間の経過とともに変化する可能性があることにも留意してください。したがって、初めに適した命名規則が2年後には適切でないということは、完全に正常です。そしてそれは完全にうまいです。将来を予測しようとすべきではありません。大会を選んでそれに従ってください。あなたとあなたのプロジェクトに適しているかどうかがわかります。そうでない場合は、それが適切でない理由を考えて、何か他のものを使用し始める。

出典

2016-10-05 06:18:38 arenaq

リソースに名前を付ける方法には規則がありますか？

答えて

関連する問題