Androidの命名規則

Androidの命名規則に関する徹底的な提案を探しています。私はここで少し見つけました：

http://source.android.com/source/code-style.html#follow-field-naming-conventions

それは言う：

• 非公開、非静的フィールド名はmで始まります。
• 静的フィールド名はsで始まります。
• 他のフィールドは小文字で始まります。
• パブリック静的最終フィールド（定数）はALL_CAPS_WITH_UNDERSCORESです。

それでも私はAndroidのすべての側面をカバーするもっと広範囲なものを探しています：

• 内のレイアウトとビューに名前を付ける方法、
• メニューに名前を付ける方法
• スタイルに名前を付ける方法
• データベーステーブル（単数形、複数形）および内のフィールドに名前を付ける方法
• 等

一般的に受け入れられている提案がある場合は、それに従ってください。すべてのSDKは独自の方法で動作しているように見えるので、Androidの方法に特に興味があります。

ribotのAndroidガイドラインは、標準の命名規則の良い例です。

XMLファイルの命名規則：

activity_<ACTIVITY NAME>.xml - for all activities
dialog_<DIALOG NAME>.xml - for all custom dialogs
row_<LIST_NAME>.xml - for custom row for listview
fragment_<FRAGMENT_NAME>.xml - for all fragments

xmlファイルのコンポーネント/ウィジェットの命名規則：

すべてのコンポーネントXの活動は、すべてのコンポーネントのような接頭辞または短い名前が必要アクティビティ名で開始する必要がありますBTNのためにButton たとえば、ログイン・アクティビティー・コンポーネントの名前は次のようにする必要があります。

activity_login_btn_login
activity_login_et_username
activity_login_et_password

主要コンポーネントの短縮名：

Button - btn
EditText - et
TextView - tv
ProgressBar - pb
Checkbox - chk
RadioButton - rb
ToggleButton - tb
Spinner - spn
Menu - mnu
ListView - lv
GalleryView - gv
LinearLayout -ll
RelativeLayout - rl

これは、開始するためのベストプラクティスの優れたコレクションです：https： //github.com/futurice/android-best-practices

これが私が使っているものです。そのリンクからもコピーします。

オブジェクトの命名

• Googleのガイドラインに従って、mまたはsプレフィックスを使用しないでください。私は何年も立ち止まっていて、彼らがいなくても簡単だと思います。IDEは、プライベートまたは静的なものを使用しているときに通知します。それは時代遅れの慣習のようです。
• 定数はキャップで始まります
• 頭字語は最初の文字のみを大文字にする必要があります。たとえば、functionUrlおよびunitId。ありませんunitID。
• オブジェクトのタイプのプレフィックス。たとえば、名前を含むTextViewはtvName。パスワード付きのEditViewはになりますetPass。
• 通常、アクティビティで1回だけ使用されるもの（ListViewなど）の場合は、それを呼び出すことを恐れないでくださいlv。
• オブジェクトタイプでない場合は、関数で名前を付けてください。たとえば、IDを保持する文字列の場合は、idstringIdではなく、という名前を付けます。IDEは、文字列、フロート、またはロングのいずれであるかを通知します。
• 読みやすくしてください。のPass代わりにのようなものを使用してくださいPassword。
• XMLの中で、名前は例えば、無大文字とアンダースコアでなければなりませんtv_nameし、et_pass
• 入れandroid:idXMLの最初の属性として。

ファイルの命名

• レイアウトの前にタイプを付けます。例えばfragment_contact_details.xml、view_primary_button.xml、activity_main.xml。
• クラスについては、フォルダーに分類しますが、サフィックスを使用します。たとえば、/activities/MainActivity.javaまたは/fragments/DeleteDialog.java。私のフォルダーは、アクティビティ、フラグメント、アダプター、モデル、およびutilsです。
• アダプターは、いつどのように使用するかを指示する必要があります。したがって、ChatActivity用のListViewアダプターが呼び出される場合がありますChatListAdapter。

パレットとしてのcolors.xmlおよびdimens.xml

• 色には、gray_lightではなく、などの名前を使用しますbutton_foreground。

• 寸法には、spacing_largeではなく、のような名前を使用しますbutton_upper_padding。

• ボタンの色やパディングに固有の設定を行う場合は、スタイルファイルを使用してください。

strings.xml

• 名前空間に似たキーを使用して文字列に名前を付け、2つ以上のキーの値を繰り返すことを恐れないでください。

• error.message.networkではなく、を使用してくださいnetwork_error。

推論

命名規則の目的は、すべてをきちんと一貫性のあるものにすることではありません。起こりうる間違いにフラグを立て、ワークフローを改善するためにあります。これらのほとんどは、キーボードショートカットに便利になるように設計されています。見栄えを良くするのではなく、バグの最小化とワークフローの改善に重点を置くようにしてください。

プレフィックスは、「そのTextViewの名前は何ですか？」という人に最適です。瞬間。

接尾辞は、そのような方法であまり頻繁にアクセスしないもののためにありますが、混乱する可能性があります。たとえば、コードをそのページのアクティビティ、フラグメント、またはアダプタのいずれに配置したかわからない場合があります。必要に応じてドロップできます。

XML IDは小文字であることが多く、誰もがこのようにしているように見えるという理由だけでアンダースコアを使用しています。

一貫性
（チームで作業する場合を除いて）全員が独自の規則を持ち、どちらを選択するかは重要ではありません。アプリケーション全体で一貫していることを確認することが重要です。


構造
個人的には、クラス名からコンポーネントまで実行され、xml全体で一貫しているため、次のような命名規則を使用します。

• クラス：<ClassName>
• 活動：<ClassName>**Activity**
• レイアウト：classname_activity
• コンポーネントID：classname_activity_component_name

この例は次のようになりOrderActivity.class、order_activity.xml、order_activity_bn_cancel。すべてのXMLが小文字であることに注意してください。

レイアウトの省略
コードを整理するために短い名前を使用したい場合。次に、別の方法として、XML内のすべての名前とレイアウトを省略できます。

この例は、OrderActivity .class：ord_act .xml、ord_act _bt_can、ord_act _ti_nam、ord_act_tv_namです。私は名前を3つに分けますが、これはあなたが持っている類似した名前の数に依存します

コンポーネントタイプの省略
コンポーネントの種類を略した場合は、あまりにもこれらの一貫性を維持しようとします。私は通常、コンポーネントタイプに2文字、名前に3文字を使用します。ただし、それがレイアウト内のそのタイプの唯一の要素である場合は、名前が必要ない場合があります。IDの原則は一意であることです

• コンポーネントID：nam_act_component_nam

コンポーネントタイプの略語（このリストには十分な2文字が表示されます）
フレームレイアウト： fl
線形レイアウト： ll
テーブルレイアウト： tl
テーブル行： tr
グリッドレイアウト： gl
相対レイアウト： rl

テキストビュー： tv
ボタン： bt
チェックボックス： cb
スイッチ： sw
トグルボタン： tb
画像ボタン： ib
画像ビュー： iv
プログレスバー： pb
シークバー： sb
評価バー： rb
スピナー： sp
Webビュー： wv
テキストの編集： et

ラジオグループ： rg
リストビュー： lv
グリッドビュー： gv
拡張可能なリストビュー： el
スクロールビュー： sv
水平スクロールビュー： hs
検索ビュー：* se
タブホスト： th
ビデオビュー： vv
ダイヤラーフィルター： df

インクルード： ic
フラグメント： fr
カスタムビュー（その他）： cv

これについてはまだ慣例はないと思います。それぞれの会社には独自のルールがあり、ここでは誰もそれを気にしないと思います。

私にとっては、名前をコンテキストにバインドすることを好みます。たとえば、「MainActivity」というアクティビティがある場合、そのレイアウト名は「main_activity.xml」になり、このアクティビティに関連付けられているリソースごとに、プレフィックス「main_activity」を追加して、それが使用されていることを確認します。このアクティビティに使用されるIDについても同じことが言えます。

私がこれらの名前を使用する理由は、名前が非常に一意であるため、Androidライブラリを使用すると、それらを見つけて必要に応じて削除するのが簡単であり、他の名前に置き換えられないためです。

また、できるだけ意味のある名前を付けるようにしています。そのため、通常、IDとして「listView」や「imageView2」は表示されませんが、「contactsListView」や「contactImageView」などが表示されます。同じ名前（または類似の名前）も、見つけやすくするために、Javaコード内の変数と一致します。

つまり、私のヒントは次のとおりです。

• 名前の中の数字は避けてください。これらは通常あまり意味がなく、UIデザイナにドラッグアンドドロップのみを使用したことを示しています。

• デモ、POC、およびここでの質問については、名前を気にする必要はありません。

• リソースのすべての名前（IDを含む）にプレフィックスを追加して、リソースが属するコンテキストを示し、一意性を実現してください。

• 可能な限り意味のある名前を付けてください。

最新のAndroidEclipseプラグインは、新しいプロジェクトを作成するときに、言及したファイルの一部を自動的に作成します。それから、命名はそのようなものです：

layout/activity_main.xml
menu/activity_main.xml
...

私はこのスキームに従いました。

layout/fragment_a.xml
layout/fragment_b.xml
...

つまり、一般的なものから詳細なものまで、パッケージ名のようなものです。また、きちんとした並べ替えが可能です。

すべての体は自分自身を使用します。主な目標は、特に他の人があなたのコードを読むときに、間違いや誤解を避けることです。構文の強調表示、および最新のIDEの自動コード検査により、ポイントはかなり少なくなります。

ただし、これらの命名規則により、コード補完がオンになっている場合にも非常に便利です。たとえば、入力mしてオートコンプリートするだけで、クラスフィールドのリストが表示されます。

しかし、多くの場合、そのような規則を使用しない他のコードを使用する必要があります。このような保護された変数とオーバーライドされたメソッドパラメータは、混乱を助長します。

いくつかの例：

• クラス変数の前にmを付け、静的ファイナル変数をすべて大文字にし、_単語を区切ります。スコープ変数の下位に接頭辞を付けないでください。

• UIの親の後に名前のレイアウト、例えばact_main.xml、frg_detail.xml、itm__act_main__list1.xml、アクティビティのMainActivity場合、フラグメントDetailFragment、IDを持つListViewinのアイテムレイアウト。MainActivitylist1

• 次のようなxmlレイアウトの名前要素ID：lsv__act_main__list1ListViewおよびbtn__act_main__submit`Button要素の場合。これにより、オートコンプリートで簡単に見つけることができます。

命名規則やベストプラクティスに関しては、プロジェクトとコーディングのガイドラインが含まれているgithubのribot / android-guidelinesリポジトリのこのmdファイルに従うことがよくあります。