人々が思いついたレイアウトファイルの命名規則にはどのようなものがありますか。
オンラインでは何も見つかりませんでしたが、次の規則を使用することを考えました。
みんなどう思いますか?
- activity_*
- dialog_*
- list_item_*
私がこれまで取り組んできたのはこれだけです。
また、そのレイアウトに対するアクティビティの命名についてはどうですか?例えば:
-> res
-> layout
-> activity_about_us.xml
-> src
-> activity
-> AboutUs.Java
不思議なことに、この質問をグーグルしようとすると、このページだけが意味のある結果になります...過去半年間、私はあなたのそれに似た命名規則を使用していますが、接頭辞は短くなっています。例:「About us」画面を表示するアクティビティの場合:
クラス名:ActAboutUs
。接頭辞クラスは一種のやり過ぎですが、アクティビティクラスを他のクラスと明確に区別します。最初はすべてのアクティビティ(アプローチと同様)に個別のディレクトリを使用しましたが、しばらくしてから、大きなアプリの場合はスーパークラス(つまり、アクティビティ)よりも機能ごとにディレクトリをグループ化するほうがよいことに気づきました。設定で作業する場合、_/src/settings/
_などの単一のディレクトリで作業する方が簡単です。そうすれば、必要なすべてのJavaファイルが1つのディレクトリにあるため、あちこち移動する必要がありません。
_/src/settings/ActSettingsGlobal.Java
/src/settings/ActSettingsNet.Java
/src/settings/Settings.Java
/src/settings/SettingsDBAdapter.Java
/src/settings/etc...
_
このアプローチは、異なる開発者間で作業を分割するのにも役立ちます。つまり、各開発者は別の機能で自分のディレクトリで作業しているため、お互いの足を踏み入れることはありません:-)。
一部の人は接尾辞を優先しますが、私はそれらがあまり役に立たないことに気づきました。接頭辞は、上記の例のように、アルファベット順にグループ化するのに役立ちます。_Act*
_接頭辞が最初にソートされるため、すべてのアクティビティが先頭に来るので便利です。
Java命名規則と競合しますが、より読みやすい接頭辞として_Act_
_を使用することを検討しています。
レイアウトファイル名:_act_about_us.xml
_。 _res/layout/
_には、残念なことにサブディレクトリの「贅沢」はありません。したがって、物事をグループ化する唯一の方法は、_act_
_、_dlg_
_などの適切な接頭辞を使用することです...
文字列ID:_<string name="act_about_us_dlg_help1_title" ...
_ _string.xml
_は、重複するname
sで最も問題が発生する場所です。 _activity_element_item
_のような命名規則が使用されていない場合、複製を作成するのは非常に簡単です。それは多くの追加のタイピングを追加しますが、それは後で多くの混乱からあなたを救います。グローバル(アプリケーション全体)文字列の場合、_"global_"
_、_global_btn_ok
_のように、プレフィックス_global_msg_no_inet_conn
_を使用します。通常、すべての_global_
_文字列は1人で担当するので、誰かが新しい文字列や変更を必要とする場合、混乱を避けるために彼と同期する必要があります。
(今、私は_activity__element__item
_(2つのアンダースコア)が_activity_element_item
_よりも明確で読みやすいことに気付いています)
全体として、Googleの開発者がファイル、ID、名前などの操作に関して、このような不便なフレームワークを作成したとは信じられないので、私のアプローチに何か問題があるという感覚を取り除くことはできません。 。
私は次の命名規則に従うべきだと思います
活動のために
アクティビティ名が
DisplayListActivity
次に、レイアウト名は
display_list_activity.xml
リストアイテムの場合、リストアイテムのレイアウト名にカテゴリを含めることができます
country_list_item.xml
ダイアログボックスの場合、それらのアクションを含めることができます
delete_country_dialog.xml
レイアウトのグループを探すとき、それは私がそれらに取り組む傾向があるので、私は常にクラス名を先頭に追加し、すべてのサブレイアウトでフォローアップすることが効果的であるとわかりました。例えば:
クラス名:AboutActivity.Java
レイアウト名:about_activity.xml
サブレイアウト名:about_activity_menu.xml
サブサブレイアウト名:about_activity_menu_item.xml
あなたの活動は常に各グループの一番上にあり、非活動のための狩猟は面倒ではなくなります。サブフォルダがまだ存在しない理由を誰かが知っていますか?私はバックエンドでの効率とシンプルさを期待していますが、それがそれほど害になることはないと思います。
これは良い読み物です https://jeroenmols.com/blog/2016/03/07/resourcenaming/
基本的に、あなたはWHAT WHERE DESCRIPTION SIZE
たとえば、レイアウトファイル
文字列
ドローアブル-all_infoicon_large:一般的な情報アイコンの大きなバージョン-all_infoicon_24dp:一般的な情報アイコンの24dpバージョン
レイアウトファイル名の最初の部分は、常に対応するクラスのタイプである必要があります。たとえば、クラスMainActivity
(この場合、タイプはActivity
)がある場合、対応するレイアウトファイルはactivity_main.xml
つまり、WarningDialog
というダイアログがあるとします。対応するレイアウトファイルはdialog_warning.xml
、フラグメントなども同様です。
これはactivity/layout
ファイルは、Android Studio(MainActivity
-> activity_main.xml
)。
私にとって、ネーミングは2つの重要な要件を修正する必要があります。
2番目の要件では、ほとんどの人が「関連」をタイプ関連として定義し、次のようなものを提供します。
activity_login
activity_movie_list
activity_user_list
activity_settings
fragment_movie_list
fragment_user_list
item_movie
item_user
等.
すべてのアクティビティまたはすべてのフラグメントに取り組むことはほとんどないので、機能ごとにグループ化することをお勧めしますが、代わりに映画機能または設定機能に取り組みます。
だから、私が好む方法はこれです:
login_activity
movie_list_activity
movie_list_fragment
movie_list_item
user_list_activity
user_list_fragment
user_list_item
settings_activity
ソースファイルはxml命名に従っていますが、CamelCaseにあるため、
LoginActivity
MovieListActivity
MovieFragment
etc.