Convention d'appellation Android

Question

Je suis à la recherche d'une suggestion de convention de nommage pour Android. J'en ai trouvé un peu ici :

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

qui dit :

• Les noms de champs non publics et non statiques commencent par m.
• Les noms des champs statiques commencent par s.
• Les autres champs commencent par une lettre minuscule.
• Les champs statiques publics finaux (constantes) sont ALL_CAPS_WITH_UNDERSCORES .

Cependant, je suis à la recherche de quelque chose de beaucoup plus complet, couvrant tous les aspects d'Android :

• comment nommer les présentations et les vues dans,
• comment nommer les menus
• comment nommer les styles
• comment nommer les tables de la base de données (au singulier et au pluriel) et les champs qu'elles contiennent
• etc.

S'il existe une suggestion généralement acceptée, j'aimerais beaucoup la suivre. Tous les SDK semblent suivre leur propre voie, je suis donc particulièrement intéressé par la façon de faire d'Android.

Answer 1

Lignes directrices Android de ribot sont un bon exemple de conventions d'appellation standard :

Convention de dénomination des fichiers 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

Convention de nommage pour les composants/widgets dans les fichiers xml :

Tous les composants pour X l'activité doit commencer par le nom de l'activité tous les composants doivent avoir un préfixe ou un nom court comme btn para Button Par exemple, le nom du composant d'activité de connexion doit être le suivant.

activity_login_btn_login
activity_login_et_username
activity_login_et_password

Nom abrégé des principaux composants :

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

Answer 2

CONSISTANCE
Chacun (à moins de travailler en équipe) aura sa propre convention et celle que vous choisirez n'a pas d'importance. Veiller à ce qu'elle soit cohérent dans l'ensemble de l'application.

STRUCTURE
Personnellement, j'utilise une convention de dénomination comme celle-ci, qui va du nom de la classe jusqu'au composant et qui est cohérente dans tout le xml :

• CLASSE : <ClassName>
• ACTIVITÉ : <ClassName>**Activity**
• PRÉSENTATION : classname_activity
• COMPOSANT IDS : classname_activity_component_name

En voici un exemple OrderActivity.class , order_activity.xml , order_activity_bn_cancel . Remarquez que tout le XML est en minuscules.

ABRÉGER LES PRÉSENTATIONS
Si vous souhaitez utiliser des noms plus courts pour garder le code plus ordonné, une autre méthode consiste à abréger les noms suivants TOUS les noms en XML ainsi que les présentations.

En voici un exemple Activité de commande .classe : ord_act .xml, ord_act _bt_can, ord_act _ti_nam, ord_act _tv_nam. Je divise les noms en trois, mais cela dépend du nombre de noms similaires que vous avez.

ABRÉVIATION DES TYPES DE COMPOSANTS
Lorsque vous abrégez les types de composants, essayez de les rendre cohérents. J'utilise normalement deux lettres pour le type de composant et trois lettres pour le nom. Cependant, il arrive que le nom ne soit pas nécessaire s'il s'agit du seul élément de ce type dans la mise en page. Le principe de l'ID est d'être unique

• COMPOSANT IDS : nam_act_component_nam

ABRÉVIATIONS DES TYPES DE COMPOSANTS (Cette liste présente deux lettres, ce qui est amplement suffisant)
Disposition du cadre : fl
Disposition linéaire : ll
Mise en page du tableau : tl
Tableau Row : tr
Disposition de la grille : gl
Disposition relative : rl

Affichage du texte : TV
Bouton : bt
Case à cocher : cb
Interrupteur : sw
Bouton de basculement : tb
Bouton d'image : ib
Vue de l'image : iv
Barre de progression : pb
Cherchez le bar : sb
Barre d'évaluation : rb
Spinner : sp
WebView : wv
Modifier le texte : et

Groupe radio : rg
Vue en liste : lv
Vue en grille : gv
Vue en liste extensible : el
Vue par défilement : sv
Vue de défilement horizontal : hs
Vue de la recherche:* se
Onglet Hôte : th
Visualisation de la vidéo : vv
Filtre de numérotation : df

Inclure : ic
Fragment : fr
Vue personnalisée (autre) : cv

Answer 3

Je ne pense pas qu'il y ait encore de convention à ce sujet. Chaque entreprise a ses propres règles et je ne pense pas que quelqu'un s'en préoccupe beaucoup ici.

Pour ma part, je préfère que le nom soit lié au contexte. Par exemple, s'il existe une activité appelée "MainActivity", son nom de présentation serait "main_activity.xml", et pour chaque ressource associée à cette activité, j'ajoute le préfixe "main_activity" afin de savoir qu'elle l'utilise. il en va de même pour les identifiants utilisés pour cette activité.

La raison pour laquelle j'utilise ces noms est qu'il est plus facile de les trouver, de les supprimer si nécessaire, et qu'ils ne seront pas remplacés par d'autres si vous utilisez les bibliothèques Android, car les noms sont assez uniques.

J'essaie également, dans la mesure du possible, de donner des noms significatifs, de sorte que vous ne verrez généralement pas "listView" ou "imageView2" comme identifiants, mais quelque chose comme "contactsListView" et "contactImageView". Le même nom (ou similaire) correspondrait également aux variables dans le code Java, afin de les rendre plus faciles à trouver.

En résumé, mes conseils sont les suivants :

• Essayez d'éviter les nombres à l'intérieur des noms. Ils ne signifient généralement pas grand chose et montrent que vous n'avez utilisé le glisser-déposer que pour le concepteur de l'interface utilisateur.

• pour les démos, les POCs et pour les questions ici, ne vous souciez pas du nom.

• essaie d'ajouter un préfixe à tous les noms de ressources (y compris les identifiants) pour indiquer à quel contexte ils appartiennent et pour assurer l'unicité.

• donner des noms significatifs dans la mesure du possible .

Answer 4

Les derniers plugins Android Eclipse créent automatiquement certains des fichiers que vous mentionnez lorsque vous créez un nouveau projet. A partir de là, le nommage est à peu près le suivant :

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

J'ai suivi ce schéma avec par exemple

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

C'est donc un peu comme pour les noms de paquets, du plus général au plus détaillé. Cela permet également de faire un tri précis.

Answer 5

L'objectif principal est d'éviter les erreurs et les mauvaises interprétations, en particulier lorsque d'autres personnes lisent votre code. Bien que la mise en évidence de la syntaxe et l'inspection automatique du code dans les IDE modernes permettent de réduire considérablement le nombre d'erreurs.

Mais ces conventions de dénomination sont également très pratiques lorsque la complétion de code est activée. Par exemple, il suffit de taper m et l'auto-complétion vous montrera une liste de champs de classe.

Mais il arrive souvent que l'on doive travailler avec le code d'autres personnes, qui n'utilisent pas cette convention. Les variables protégées et les paramètres de méthode surchargés ne font qu'ajouter à la confusion.

Quelques exemples :

• Les variables de classe sont préfixées par m et les variables finales statiques sont en majuscules, avec _ séparer les mots. Ne préfixez rien aux variables de portée inférieure.

• Nommez la disposition d'après le parent de l'interface utilisateur, par exemple act_main.xml , frg_detail.xml , itm__act_main__list1.xml pour une activité MainActivity , un fragment DetailFragment , la présentation du poste pour un ListView en MainActivity avec id list1 respectivement.

• Nom de l'élément Id's dans les mises en page xml comme : lsv__act_main__list1 pour un ListView et btn__act_main__submit pour un élément `Button'. Cela les rend beaucoup plus faciles à trouver avec l'auto-complétion.