公式の推奨事項があるかどうかはわかりません。
ウィジェットとコンテナを使用したレイアウトのIDには、次の規則を使用します。
<layout>_<widget/container>_<name>
これらのレイアウトで使用する寸法、文字列、数字、色についても同じ戦略を実行します。ただし、一般化してみます。たとえば、すべてのボタンに共通のtextColorがある場合、名前の前にレイアウトを付けません。リソース名は「button_textColor」です。すべてのtextColorが同じリソースを使用している場合、「textColor」という名前が付けられます。スタイルの場合、これも通常のケースです。
私が使用するメニューリソースの場合：
menu_<activity>_<name>
大文字は使用できないため、アニメーションは異なります。ドローアブルxmlリソースについても同じことが言えます。
Android SDKは開始するのに適した場所です。
たとえば、アクティビティ内でIDをスコープしようとします。
ListViewがあれば、単に@Android:id/listすべてのアクティビティで。
ただし、リストが2つある場合は、より具体的な@id/list_Appleおよび@id/list_orange
したがって、ジェネリック（ids、...）はR.Java fileユニークなもの（再利用されることもある）には一般的なものが前に付けられますアンダースコアで区切られます。
アンダースコアは一つのことです、例えば、私は観察しました：
レイアウトの幅はlayout_width in xmlおよびlayoutWidth in codeなので、list_Apple
したがって、ログインボタンはloginになりますが、ログインが2つある場合 then login_fooおよびlogin_bar。
Androidのドキュメント から取得。主題にもっとあります。
あなたの質問に答えるには：はい、あります。
それらの多くは google search などで見つけることができます。そして、最高の命名規則などはありません。それは常にあなたのニーズとプロジェクトの属性（最も重要なことにはスコープ）に依存します。
最近、私はかなり読みました ブログ投稿 Android Jeroen MolsからのXMLのリソースの命名について。著者は、すべてのリソースが従うべき基本原則と、この規約 Androidリソースの命名に関するチートシート で説明されている両方のリソースタイプに適用されます。
次に、各要素と各リソースタイプについて詳しく説明します。
この規約は、小規模から中規模のプロジェクト（個人使用、数か月の契約申請）で使用できます。ただし、50以上のアクティビティや1000以上の文字列を含む長時間のプロジェクトにはお勧めしません。
このような大規模なプロジェクトでのリソース値の規約では、リソースの使用方法についてさらに調査する必要があります。文字列を例にとります。チームのサイズ、使用している翻訳センター（存在する場合）、 [〜＃〜] vcs [〜＃〜] を使用している場合があります（たとえば、マージの競合を避けるため） 。文字列を複数のファイルに分割することも考えられます。
何かを探していると思います。ですから、私が言及したブログ投稿をお勧めします。これは初心者に適しています。独自の命名規則を作成するためのインスピレーションとして間違いなく使用できます。
また、プロジェクトが成長するにつれて、多くのニーズと要件が時間とともに変化する可能性があることにも留意してください。そのため、最初は適切だった命名規則が2年後には適切ではなくなるというのは完全に通常のことです。そして、それは完全に大丈夫です。未来を予測しようとしないでください。規約を選択して、それに従ってください。あなたとあなたのプロジェクトに適しているかどうかがわかります。そうでない場合は、なぜそれが適切でないのかを考え、他の何かを使い始めます。
リソースで使用されるいくつかの規則があります。
- 別個のファイルとして存在するリソースの場合、lower_case_underscore_separatedである必要があります。 apptツールは、大文字と小文字が混在するファイルシステムで問題が発生する可能性があるため、ファイルが小文字のみであることを確認します。
- Values/...（属性、文字列など）でのみ宣言されたリソースの場合、規則は通常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などです。
これはあらゆる言語やフレームワークに共通の問題ですが、予約語を避けている限り、あなたが物事と呼んだものを覚えていると仮定して大丈夫です。
Androidはxmlリソースファイル名に制限を設定しますが、アンダースコアは問題ないようです。ADTは実際に述べています
ファイルベースのリソース名には、小文字のa〜z、0〜9、または_のみを含める必要があります。
最初に私をつまずかせたのは、IDの名前空間がないことでしたが、同じAndroidは定義されたIDを再利用するだけの2つの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を使用して少し間隔を追加することを好む場合は、古い習慣を破ることができるなら、おそらくこれを行うでしょう。
これらを省略することは理想的ではないと主張する人もいますし、純粋主義者はフルネームを使用するべきだと主張するでしょうが、数十のコントロールに名前を付け、異なるシステムやフレームワーク間で変更すると、フルネームは意味を失います、 VB、C++、ASP.NET、C＃およびVB.NETのWinForms、AndroidおよびPython。10年以上にわたってこれらを使用しています。Androidそれをテキストボックスまたはエディットテキストと呼びますlblFooが静的ラベルであり、txtFooがユーザーが入力するものであるということを知る必要があるだけです。
最後の注意点は、重要なことを決定する規則に関係なく、コントロールに適切かつ一貫して名前を付けることであるため、漠然としたデフォルトID（TextView5や異なる規則の混合など）に取り組む必要はありません
デザイナーと開発者のための便利なリンク- ここ
寸法とサイズ、命名規則、スタイルとテーマ、9パッチなど。
Googleが推進している標準的なコンベンションはないと思います。さまざまな公式のGoogleアプリ内であっても、さまざまな方法で人が名前を付ける方法を見てきました。
1つのディレクトリ階層にある100個のレイアウト（またはドロアブル、メニューなど）ファイルの意味を理解しようとするときに最も役立つものは何でも。
短い答え：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の2番目の「文字列」は冗長です）。ただし、タイプを明示的に追加すると、理解が向上します（たとえば、翻訳者がトーストまたはラベルを区別するのに役立つ場合があります）。場合によっては、「名前」と「タイプ」の部分を交換して、タイプベースのフィルタリングを可能にすることができます（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
Androidのドキュメントを調べてみると、「ベストプラクティス」に関するさまざまな言及がありますが、具体的なルールは確かにありません。たとえば、 Icon Design Guidelines では、「ic_」プレフィックスを付けてアイコンに名前を付けることをお勧めします。
始めるのに適した場所は Providing Resources です。
また、Googleの開発者がどのように行っているかを知りたい場合は、SDKのソース/サンプルと Android Developers Blog を調べてください。
文字列の便利な次の命名規則を見つけました：
[<action>]_<object>_<purpose>
たとえば、clear_playlist_text、delete_song_message、update_playlist_positivebutton_textなどです。そして、ここでの「アクション」はオプションです。
Androidプロジェクトには、ボタン、ラベル、テキストボックスなどのコンポーネントがたくさんあります。たとえば、「名前」のような単純な名前は、「名前」がラベルまたはテキストボックスであることを識別するのは非常にわかりにくいです。主に他の開発者が開発したプロジェクトを管理しているときに起こります。
この種の混乱を避けるため、Buttons TextBoxesまたはLabelsには次の名前を使用しました
例：
btnName
labName
txtName
listName
これはあなたに役立つかもしれません。
私は通常、リソース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's Id（xがXMLを意味する）の一部としてレイアウトファイルで命名されました） 、ButtonsやEditTextなどのビューオブジェクトのこのタイプの命名規則に従いました。
xML IDS：xViewTypeSpecificName
javaの場合：mViewTypeSpeficName
上記の規則は、複雑なレイアウトを作成するときに私の生活を楽にします。名前をできるだけ短くするようにしてください。他の共同開発者が理解し、意味のあるものにした方が良いです（ただし、毎回不可能な場合もあります）。私の経験が他の人に役立つことを願って、提案を歓迎します。
あなたはアイデアを得るためにコードスタイルのGoogleドキュメントを読むことができます here