Existe-t-il des conventions sur la façon de nommer les ressources ?

Question

Existe-t-il des conventions pour nommer les ressources dans Android ? Par exemple, les boutons, les textViews, les menus, etc.

Answer 1

Le SDK Android sera un bon point de départ.

Par exemple, j'essaie d'étendre les ID au sein de l'activité.

Si j'avais un ListView ce serait tout simplement @android:id/list dans toutes les activités.
Si, toutefois, j'avais deux listes, j'utiliserais la plus spécifique. @id/list_apple et @id/list_orange

Ainsi, les éléments génériques (ids, ...) sont réutilisés dans la section R.java file tandis que ceux qui sont uniques (parfois réutilisés) sont préfixés par des génériques. séparés par un trait de soulignement .

---

Le soulignement est une chose, j'ai observé, par exemple :

La largeur de la mise en page est layout_width en xml et layoutWidth en code alors j'essaie de m'y tenir comme list_apple

Ainsi, un bouton de connexion sera login mais si nous avons deux identifiants puis login_foo et login_bar .

Answer 2

Je ne sais pas s'il existe des recommandations officielles.

Pour les identifiants dans mes mises en page avec widgets et conteneurs, j'utilise la convention :

<layout>_<widget/container>_<name>

Je fais la même stratégie pour tous les dimens, chaînes, chiffres et couleurs que j'utilise dans ces mises en page. Cependant, j'essaie de généraliser. Par exemple, si tous les boutons ont une couleur de texte commune, je ne préfixe pas le nom avec la disposition. Le nom de la ressource sera "button_textColor". Si toutes les textColors utilisent la même ressource, elle sera nommée 'textColor'. C'est également le cas pour les styles.

Pour les ressources du menu, j'utilise :

menu_<activity>_<name>

Les animations sont seulement différentes car vous ne pouvez pas utiliser de lettres majuscules. Il en va de même pour les ressources xml dessinables, je crois.

Answer 3

Tiré de La documentation d'Android . Vous y trouverez plus d'informations sur le sujet.

Answer 4

Il existe quelques conventions utilisées dans les ressources :

• Pour les ressources qui existent sous forme de fichiers séparés, elles doivent être séparées par des minuscules. L'outil appt s'assure que vos fichiers sont uniquement en minuscules, car l'utilisation de majuscules et de minuscules peut causer des problèmes sur les systèmes de fichiers insensibles à la casse.
• Pour les ressources déclarées uniquement en valeurs/... (attributs, chaînes de caractères, etc.), la convention est généralement celle de la casse mixte.
• Une convention est parfois utilisée pour étiqueter les noms avec une "classification" afin d'avoir des espaces de noms simples. C'est par exemple là que vous voyez des choses comme layout_width et layout_alignLeft. Dans un fichier de mise en page, les attributs de la vue et de la gestion de mise en page parente sont mélangés, même s'ils ont des propriétaires différents. La convention "layout_*" garantit qu'il n'y a pas de conflit entre ces noms et qu'il est facile de comprendre quelle entité est concernée par le nom.

Cette convention "layout_blah" a également été utilisée à d'autres endroits. Par exemple, il y a des attributs "state_blah" qui sont les états dessinables qu'une vue peut avoir.

En raison de ces deux conventions (underscore_separated pour les fichiers, mixedCase pour les ressources déclarées), vous trouverez également un certain nombre d'incohérences. Par exemple, les couleurs peuvent être déclarées soit avec des fichiers, soit comme des valeurs explicites. En général, nous aimerions nous en tenir à underscore_separated pour tous ces éléments, mais ce n'est pas toujours le cas.

En fin de compte, nous ne nous préoccupons pas beaucoup des conventions de dénomination des ressources. La plus importante que nous gardons cohérente est "mixedCase" pour les attributs, et l'utilisation de "layout_blah" pour identifier les attributs des paramètres de mise en page.

La consultation des ressources publiques devrait également vous donner une bonne idée des conventions :

http://developer.Android.com/reference/Android/R.html

Vous verrez que les attributs sont tous assez cohérents (si vous comprenez la convention layout_), que les tableaux sont tous séparés par des tirets bas, etc.

Answer 5

Il s'agit d'un problème commun à tous les langages et cadres de travail, mais tant que vous évitez les mots réservés, tout devrait bien se passer, à condition que vous puissiez vous rappeler comment vous avez appelé les choses.

J'ai remarqué qu'Android impose une restriction sur les noms de fichiers de ressources xml, mais les caractères de soulignement semblent convenir. ADT indique en fait

Les noms de ressources basés sur des fichiers ne doivent contenir que des minuscules de a à z, 0 à 9 ou _.

Une chose qui m'a fait trébucher au début était le manque d'espaces de noms avec des identifiants, mais cela peut généralement être ignoré si vous avez deux identifiants identiques, Android réutilisera simplement l'identifiant défini.

Pour les identifiants, j'utilise un qualificatif de 3 lettres suivi de ce à quoi il se réfère en notation camel, par exemple lblFoo pour une étiquette de texte statique (ou textview), txtFoo pour une zone de texte éditable (edittext dans Android). Cela peut sembler étrange au premier abord mais je l'utilise depuis VB6 et ces contrôles étaient appelés label et textbox.

En voici d'autres que j'utilise couramment :

• btnFoo - bouton
• pwdFoo - mot de passe
• lstFoo - liste
• clrFoo - couleur
• tblFoo - table
• colFoo - colonne
• rowFoo - rangée
• imgFoo - image
• dimFoo - dimension
• padFoo - rembourrage
• mrgFoo - marge

J'utilise la même chose dans le code du fichier java pour ne pas avoir à y penser, la portée du paquet le permet sans problème :

Button btnFoo = (Button)findViewById(R.id.btnFoo);

Si vous préférez, vous pouvez ajouter un petit espacement en utilisant le trait de soulignement, par exemple btn_foo... Je le ferais probablement si je pouvais me défaire de mes vieilles habitudes.

Certains diront que l'abréviation n'est pas idéale et les puristes diront qu'il faut utiliser le nom complet, mais lorsque vous nommez des dizaines de contrôles et que vous passez d'un système ou d'un framework à l'autre, les noms complets perdent leur signification. J'utilise ces noms depuis plus de dix ans dans VB, C++, ASP.NET, WinForms en C# et VB.NET, Android et Python. Je n'ai jamais besoin de me rappeler si Android l'appelle textbox ou edittext. Tout ce que j'ai besoin de savoir, c'est que lblFoo est l'étiquette statique et que txtFoo est ce que l'utilisateur saisit.

Une dernière remarque : quelle que soit la convention retenue, l'important est de nommer les contrôles correctement et de manière cohérente, afin de ne pas se débattre avec de vagues identifiants par défaut, par exemple TextView5, ou avec un mélange de différentes conventions.