web-dev-qa-db-de.com

Namenskonventionen für Layoutdateien?

Welche Namenskonventionen für Layoutdateien haben sich die Leute ausgedacht?.

Ich habe online nichts gefunden, habe aber über die Verwendung der folgenden Konvention nachgedacht.

Was denkt jeder?

 - activity_* 
 - dialog_*
 - list_item_*

Damit habe ich bisher nur gearbeitet.

Was ist auch mit der Benennung der Aktivität anhand ihres Layouts? Zum Beispiel:

-> res
    -> layout
        -> activity_about_us.xml
-> src
    -> activity
        -> AboutUs.Java
38
Salsero69

Seltsamerweise bringt der Versuch, diese Frage zu googeln, nur diese Seite als bedeutungsvolles Ergebnis ... Im letzten halben Jahr verwende ich eine Namenskonvention, die Ihrer ähnelt, jedoch mit kürzeren Präfixen. Zum Beispiel: Für Aktivitäten, die den Bildschirm "Über uns" anzeigen:

Klassenname : ActAboutUs. Die Präfix-Klasse ist eine Art Overkill, unterscheidet jedoch die Aktivitätsklassen deutlich von den anderen. Anfangs habe ich ein separates Verzeichnis für alle Aktivitäten verwendet (ähnlich wie bei Ihrem Ansatz), aber nach einiger Zeit wurde mir klar, dass es für größere Apps möglicherweise besser ist, Verzeichnisse nach Merkmalen zu gruppieren als nach Superklassen (d. H. Aktivität). Es ist einfacher für mich, in einem einzelnen Verzeichnis zu arbeiten, zum Beispiel /src/settings/, wenn ich mit Einstellungen arbeite. Auf diese Weise befinden sich alle Java-Dateien, die ich benötige, in einem einzigen Verzeichnis, sodass ich nicht herumwandern muss:

/src/settings/ActSettingsGlobal.Java
/src/settings/ActSettingsNet.Java
/src/settings/Settings.Java
/src/settings/SettingsDBAdapter.Java
/src/settings/etc...

Dieser Ansatz trägt auch dazu bei, die Arbeit zwischen verschiedenen Entwicklern aufzuteilen, d. H. Jeder arbeitet in seinem eigenen Verzeichnis an separaten Funktionen, so dass man sich nicht auf die Füße tritt :-).

Einige Leute bevorzugen Suffixe, aber ich fand sie weniger nützlich. Präfixe helfen, die Dinge alphabetisch wie im obigen Beispiel zu gruppieren: Das Präfix Act* wird zuerst sortiert, sodass alle Aktivitäten bequem oben stehen.

Ich überlege sogar, Act_ als Präfix zu verwenden, das besser lesbar ist, obwohl es mit den Java-Namenskonventionen in Konflikt steht ...

Dateiname des Layouts : act_about_us.xml. In res/layout/ haben wir nicht den "Luxus" von Subdirs, was ziemlich unglücklich ist. Die einzige Möglichkeit, Dinge zu gruppieren, ist die Verwendung eines geeigneten Präfixes wie act_, dlg_ usw. 

String IDs : <string name="act_about_us_dlg_help1_title" ...string.xml ist der Ort, an dem wir die meisten Probleme mit doppelten names haben. Duplikate können sehr einfach erstellt werden, wenn keine Namenskonvention wie activity_element_item verwendet wird. Es fügt viele zusätzliche Schreibvorgänge hinzu, erspart Ihnen später jedoch jede Menge Verwirrung. Für globale (anwendungsweite) Zeichenfolgen verwenden wir das Präfix "global_", beispielsweise global_btn_ok, global_msg_no_inet_conn. Normalerweise machen wir eine Person für alle global_-Zeichenfolgen verantwortlich. Wenn also jemand eine neue Zeichenfolge oder Änderung benötigt, muss er mit ihm synchronisiert werden, um Verwirrung zu vermeiden.

(jetzt merke ich, dass activity__element__item (zwei Unterstriche) klarer und lesbarer ist als activity_element_item)

Alles in allem kann ich immer noch nicht das Gefühl loswerden, dass bei meinem Ansatz etwas nicht stimmt, da ich nicht glauben kann, dass Google-Entwickler ein so unbequemes Rahmenwerk geschaffen haben, wenn es um die Arbeit mit Dateien, IDs, Namen usw. geht. .

28
Ognyan

ich denke, die folgende Namenskonvention sollte folgen

für Aktivität 

wenn unser Tätigkeitsname ist

DisplayListActivity

dann sollte unser layoutname sein

display_list_activity.xml

für Listenelemente können wir eine Kategorie in den Layoutnamen der Listenelemente aufnehmen

country_list_item.xml

und für Dialogfelder kann ihre Aktion eingeschlossen werden

delete_country_dialog.xml
9
Sunil Pandey

Wenn ich nach einer Gruppe von Layouts suche, so neige ich dazu, an ihnen zu arbeiten, finde ich es gut, immer den Klassennamen vorzustellen und alle Unterlayouts zu verfolgen. Zum Beispiel:

Klassenname: AboutActivity.Java
Layoutname: about_activity.xml
Name des Unterlayouts: about_activity_menu.xml
Name des Unterlayouts: about_activity_menu_item.xml

Ihre Aktivität steht immer an oberster Stelle jeder Gruppe, und die Suche nach Nicht-Aktivitäten wird weniger lästig. Weiß jemand, warum Unterordner noch nichts sind? Ich erwarte Effizienz und Einfachheit im Backend, aber ich kann mir vorstellen, dass es nicht zu sehr schaden würde.

6
Molimo

Dies ist eine gute Lektüre https://jeroenmols.com/blog/2016/03/07/resourcenaming/

Grundsätzlich folgen Sie WHAT WHERE DESCRIPTION SIZE

Zum Beispiel Layoutdatei

  • activity_main: Inhaltsansicht der MainActivity
  • fragment_articledetail: Ansicht für das ArticleDetailFragment

streicher

  • articledetail_title: Titel von ArticleDetailFragment
  • feedback_explanation: Feedback-Erklärung in FeedbackFragment

drawable - all_infoicon_large: große Version des generischen Info-Symbols - all_infoicon_24dp: 24dp-Version des generischen Info-Symbols

2
onmyway133

Der erste Teil eines Layoutdateinamens sollte immer der Typ der entsprechenden Klasse sein. Wenn wir beispielsweise eine Klasse MainActivity haben (Typ ist in diesem Fall Activity), sollte die entsprechende Layoutdatei activity_main.xml heißen. 

Das heißt, sagen wir, wir haben einen Dialog namens WarningDialog, die entsprechende Layoutdatei sollte dialog_warning.xml heißen, das gleiche gilt für Fragmente usw.

Das mag Ihnen bekannt vorkommen, denn so werden auch die activity/layout-Dateien benannt, wenn Sie ein neues Projekt in Android Studio erstellen (MainActivity -> activity_main.xml).

1
Jeffalee

Für mich sollte die Benennung zwei wichtige Anforderungen regeln:

  1. es sollte Ihnen einen Hinweis zum Inhalt und Typ der Dateien geben (z. B. activity_login/login_activity oder movie_list_item/list_item_movie).
  2. es sollte verwandte Elemente gruppieren, um das Hin- und Herspringen zu minimieren

Für die zweite Anforderung definieren die meisten Leute "verwandt" als typbezogen, was ungefähr so ​​aussieht:

activity_login
activity_movie_list
activity_user_list
activity_settings
fragment_movie_list
fragment_user_list
item_movie 
item_user

usw.

Ich bevorzuge die Gruppierung nach Funktionen, da Sie so gut wie nie an allen Aktivitäten oder Fragmenten arbeiten, sondern stattdessen an Filmen oder Einstellungsfunktionen.

mein bevorzugter Weg ist also:

login_activity
movie_list_activity
movie_list_fragment
movie_list_item 
user_list_activity
user_list_fragment
user_list_item
settings_activity

Quelldateien folgen der XML-Benennung, befinden sich jedoch in CamelCase

LoginActivity
MovieListActivity
MovieFragment 
etc.
0
daneejela