Konwencja nazewnictwa Androida

Szukam dokładnej sugestii dotyczącej konwencji nazewnictwa Androida. Znalazłem trochę tutaj:

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

który mówi:

• Niepubliczne, niestatyczne nazwy pól zaczynają się od m.
• Nazwy pól statycznych zaczynają się od s.
• Pozostałe pola zaczynają się od małej litery.
• Publiczne statyczne pola końcowe (stałe) to ALL_CAPS_WITH_UNDERSCORES.

Jednak szukam czegoś znacznie bardziej rozbudowanego obejmującego wszystkie aspekty Androida:

• jak nazywać układy i widoki w ramach,
• jak nazywać menu
• jak nazywać style
• jak nazwać tabele bazy danych (liczba pojedyncza, liczba mnoga) i pola w obrębie
• itp

Jeśli jest jakaś ogólnie akceptowana sugestia, chciałbym po prostu ją zastosować. Wydaje się, że wszystkie zestawy SDK podążają własną drogą, więc jestem szczególnie zainteresowany sposobem, w jaki to robi Android.

Wytyczne firmy ribot dla systemu Android są dobrym przykładem standardowych konwencji nazewnictwa:

Konwencja nazewnictwa dla plików 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

Konwencja nazewnictwa dla komponentu / widżetu w plikach xml:

Wszystkie komponenty dla aktywności X muszą zaczynać się od nazwy aktywności, wszystkie komponenty powinny mieć prefiks lub nazwę skróconą, taką jak btn na Button przykład, nazwa komponentu aktywności logowania powinna wyglądać następująco.

activity_login_btn_login
activity_login_et_username
activity_login_et_password

Krótka nazwa głównych komponentów:

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

To doskonały zbiór najlepszych praktyk, od których można zacząć: https://github.com/futurice/android-best-practices

Oto czego używam. Skopiuję również z tego linku.

Nazewnictwo obiektów

• Nie używaj przedrostka mlub szgodnie z wytycznymi Google. Przestałem od lat i bez nich jest mi łatwiej. IDE poinformuje Cię, kiedy używasz czegoś prywatnego lub statycznego; wygląda na przestarzałą konwencję.
• STAŁE zaczynają się od wielkich liter
• Akronimy powinny składać się tylko z pierwszej litery. Na przykład functionUrli unitId. Nie unitID.
• Przedrostek określający typ obiektu. Na przykład TextView, który zawiera nazwę, to tvName. EditView z hasłem byłby etPass.
• Jeśli jest to coś, co zwykle jest używane tylko raz w działaniu (np. ListView), nie bój się tego po prostu nazwać lv.
• Jeśli nie jest to typ obiektu, po prostu nazwij go według funkcji. Na przykład, jeśli jest to ciąg zawierający identyfikator, nazwij go jako id, a nie stringId. IDE powie ci, kiedy jest to string, float lub long.
• Zachowaj czytelność. Użyj czegoś takiego jak Passzamiast Password.
• W pliku XML nazwa powinna być podkreślona bez wielkich liter, np. tv_nameIet_pass
• Umieść android:idjako pierwszy atrybut w pliku XML.

Nazewnictwo plików

• Poprzedź układy odpowiednim typem. Np fragment_contact_details.xml, view_primary_button.xml, activity_main.xml.
• W przypadku klas podziel je na foldery, ale użyj przyrostków. Na przykład /activities/MainActivity.javalub /fragments/DeleteDialog.java. Moje foldery są działania, fragmenty, adaptery, modele i utils .
• Adaptery powinny informować, jak i kiedy są używane. Można więc wywołać adapter ListView dla ChatActivity ChatListAdapter.

colors.xml i dimens.xml jako paleta

• W przypadku koloru użyj nazw takich jak gray_light, nie button_foreground.

• W przypadku wymiarów użyj nazw takich jak spacing_large, nie button_upper_padding.

• Jeśli chcesz ustawić coś konkretnego dla koloru lub wypełnienia przycisku, użyj pliku stylu.

strings.xml

• Nazwij swoje ciągi kluczami, które przypominają przestrzenie nazw i nie bój się powtarzać wartości dla dwóch lub więcej kluczy.

• Użyj error.message.network, nie network_error.

Rozumowanie

Celem konwencji nazewnictwa nie jest uczynienie wszystkiego schludnym i spójnym . Ma na celu oznaczenie możliwych błędów i usprawnienie przepływu pracy. Większość z nich została zaprojektowana tak, aby była wygodna w użyciu skrótów klawiaturowych. Zamiast wyglądać ładnie, spróbuj skupić się na minimalizowaniu błędów i poprawianiu przepływu pracy.

Prefiksy świetnie sprawdzają się w przypadku „Jak nazywa się ten TextView?” chwile.

Sufiksy są dostępne dla rzeczy, do których nie masz dostępu tak często w ten sposób, ale mogą być mylące. Na przykład mogę nie być pewien, czy umieściłem kod w Aktywności, fragmencie lub adapterze tej strony. Jeśli chcesz, możesz je upuścić.

Identyfikatory XML są często pisane małymi literami i zawierają podkreślenia tylko dlatego, że wszyscy robią to w ten sposób.

SPÓJNOŚĆ
Każdy (z wyjątkiem pracy w zespołach) będzie miał własną konwencję i nie ma znaczenia, którą z nich wybierzesz. Ważne jest, aby upewnić się, że jest spójny w całej aplikacji.


STRUKTURA
Osobiście używam takiej konwencji nazewnictwa, ponieważ przebiega ona od nazwy klasy do komponentu i jest spójna w całym XML:

• KLASA :<ClassName>
• DZIAŁALNOŚĆ :<ClassName>**Activity**
• UKŁAD :classname_activity
• IDENTYFIKATORY KOMPONENTÓW :classname_activity_component_name

Przykładem tego byłoby OrderActivity.class, order_activity.xml, order_activity_bn_cancel. Zauważ, że cały kod XML jest pisany małymi literami.

SKRÓTY UKŁADÓW
Jeśli chcesz używać krótszych nazw, aby zachować porządek w kodzie; wtedy inną metodą może być skrócenie WSZYSTKICH nazw w XML, a także układów.

Przykładem może być OrderActivity .class: ord_act .xml, ord_act _bt_can, ord_act _ti_nam, ord_act _tv_nam. Podzielę nazwy na trzy, ale to zależy od tego, ile masz podobnych imion

SKRÓCENIE TYPÓW KOMPONENTÓW
Podczas tworzenia skrótów typów komponentów staraj się zachować spójność. Zwykle używam dwóch liter dla typu elementu i trzech liter dla nazwy. Czasami jednak nazwa nie będzie potrzebna, jeśli jest to jedyny tego typu element w układzie. Zasada ID ma być niepowtarzalna

• IDENTYFIKATORY KOMPONENTÓW :nam_act_component_nam

SKRÓTY TYPÓW KOMPONENTÓW (Ta lista zawiera dwie litery, których jest dużo)
Układ ramki: fl
Układ liniowy: ll
Układ tabeli: tl
Wiersz tabeli: tr
Układ siatki: gl
Układ względny: rl

Widok tekstu:
przycisk tv : bt
Pole wyboru: cb
Przełącznik: sw
Przycisk przełącznika: tb
Przycisk obrazu: ib
Widok obrazu: iv
Pasek postępu: pb
Pasek wyszukiwania: sb
Pasek oceny: rb
Pokrętło: sp
WebView: wv
Edytuj tekst: et

Grupa radiowa: rg
Widok listy: lv
Widok siatki: gv
Widok listy rozwijanej: el
Widok przewijania: sv
Widok przewijania poziomego: hs
Widok wyszukiwania: * se
Zakładka Host: th
Widok wideo: vv
Filtr dialera: df

Uwzględnij: ic
Fragment: fr
Widok niestandardowy (inne): cv

Myślę, że nie ma jeszcze na to konwencja. każda firma rządzi się swoimi prawami i nie sądzę, żeby ktoś się tym przejmował.

Dla mnie wolę umieszczać nazwę, aby była związana z kontekstem. na przykład, jeśli istnieje działanie o nazwie „MainActivity”, jego nazwa układu to „main_activity.xml”, a dla każdego zasobu skojarzonego z tym działaniem dodaję przedrostek „main_activity”, aby wiedzieć, że z niego korzysta. to samo dotyczy identyfikatorów używanych w tym działaniu.

Powodem, dla którego używam tych nazw, jest to, że łatwiej je znaleźć, usunąć w razie potrzeby, a nie zastąpisz ich innymi, jeśli używasz bibliotek Androida, ponieważ nazwy są dość unikalne.

Staram się też, jak to tylko możliwe, nadawać znaczące nazwy, więc zwykle nie zobaczysz „listView” lub „imageView2” jako identyfikatorów, ale coś w rodzaju „kontaktówListView” i „contactImageView”. ta sama nazwa (lub podobna) będzie również pasować do zmiennych w kodzie java, aby ułatwić ich znalezienie.

Krótko mówiąc, moje wskazówki to:

• staraj się unikać liczb w nazwach. zwykle niewiele znaczą i pokazują, że projektant interfejsu użytkownika używał tylko metody przeciągnij i upuść.

• w przypadku wersji demonstracyjnych, POC i pytań tutaj, nie martw się o nazewnictwo.

• spróbuj dodać przedrostek do wszystkich nazw zasobów (w tym identyfikatorów), aby pokazać, do jakiego kontekstu należą, i uzyskać niepowtarzalność.

• jeśli to możliwe, podawaj znaczące nazwy.

Najnowsze wtyczki Android Eclipse tworzą niektóre wspomniane pliki automatycznie podczas tworzenia nowego projektu. Stąd nazewnictwo wygląda mniej więcej tak:

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

Podążałem za tym schematem np

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

Jest to więc coś podobnego do nazw pakietów, od ogólnych do szczegółowych. Pozwala również na schludne sortowanie.

Każdy organizm używa swojego własnego. Głównym celem jest uniknięcie błędów i błędnych interpretacji, zwłaszcza gdy inni czytają Twój kod. Chociaż podświetlanie składni i automatyczna inspekcja kodu w nowoczesnych IDE sprawia, że ​​jest to mniej warte.

Ale te konwencje nazewnictwa sprawiają, że jest to również bardzo wygodne, gdy jest włączone uzupełnianie kodu. Na przykład po prostu wpisz, ma autouzupełnianie pokaże listę pól klas.

Ale często trzeba pracować z innym kodem, który nie używa takiej konwencji. takie chronione zmienne i nadpisane parametry metody po prostu zwiększają zamieszanie.

Kilka przykładów:

• Prefiks zmiennych klasowych za pomocą m i sprawienie, aby statyczne finały zmienne były wszystkie wielkie litery, _oddzielając słowa. Nie poprzedzaj niczego przed zmiennymi o niższym zakresie.

• Układ nazwa po UI rodzica, na przykład act_main.xml, frg_detail.xml, itm__act_main__list1.xml; dla działania MainActivityodpowiednio fragment DetailFragment, układ elementu dla ListViewin MainActivityz id list1.

• Identyfikatory elementu nazwy w układach XML, takich jak: lsv__act_main__list1dla ListView i btn__act_main__submitdla elementu `` Button. Dzięki temu łatwiej je znaleźć dzięki funkcji autouzupełniania.

Jeśli chodzi o konwencje nazewnictwa i / lub najlepsze praktyki, często korzystam z tego pliku md repozytorium ribot / android-Guidelines na githubie, które zawiera wytyczne dotyczące projektów i kodowania.