Convention de dénomination des identifiants Android: minuscules avec trait de soulignement vs casse camel

89

Je programme actuellement une application pour Android. Maintenant, ce que j'ai découvert, c'est que vous ne pouvez pas placer des objets de ressources, par exemple une image dans le dossier pouvant être dessiné et le nommer comme "myTestImage.jpg". Cela vous donnera une erreur de compilation car la syntaxe de la casse camel n'est pas autorisée, vous devrez donc la renommer comme "my_test_image.jpg".

Mais qu'en est-il des identifiants que vous définissez dans le fichier XML. Disons que vous avez la définition suivante

<TextView android:id="@+id/myTextViewFirstname"
              android:layout_width="wrap_content"
              android:layout_height="wrap_content"
              android:text="Firstname" />

Ceci est une définition valide, compile et fonctionne très bien sur mon émulateur Android bien que - comme vous le voyez - je spécifie l'id dans la syntaxe de cas de camel.

Désormais, les exemples Android utilisent toujours des minuscules et des traits de soulignement. Est-ce juste une convention de dénomination pour utiliser des minuscules avec un trait de soulignement pour les identifiants ou cela peut-il causer des problèmes sur le périphérique réel?

THX

android mobile Juri
la source

Réponses:

87

L'appareil ne se plaindra pas si vous utilisez des noms d'identifiants camel-case. Pour ma première application, j'ai écrit tous les identifiants dans camel-case car je pense que cela apparaît mieux dans le code Java de cette façon, et cela fonctionne très bien.

Je change lentement d'avis sur camel-case, cependant, car vous vous retrouvez avec deux conventions de dénomination différentes - par exemple:

// This must be undescored due to naming constrictions
setContentView(R.layout.my_long_layout_name);

// Now this looks a little out of place
findViewById(R.id.myLongSpecificId);

Moi aussi, je m'interroge sur les normes ici. Google est incohérent dans ses exemples; parfois ils utilisent toutes les minuscules, parfois ils insèrent des traits de soulignement, et parfois ils utilisent des cas de chameau.

Dan Lew
la source
18
Oui, c'est exactement mon problème. Ils vous obligent à utiliser la convention de dénomination soulignée pour les mises en page, tandis que vous pouvez utiliser soit camel-case soit souligné pour les identifiants référençant des contrôles / widgets dans les définitions de mise en page XML. Google devrait vraiment définir une norme ici (si ce n'est déjà fait, au moins je n'ai rien trouvé). Donc, aller dans un sens est certainement le meilleur pour être cohérent dans toute l'application, que vous référeniez des mises en page ou des champs référencés par identifiant.
Juri
Juste pour la curiosité: avez-vous un lien où Google est incohérent, c'est-à-dire où ils ont utilisé la notation camel-case pour les identifiants?
Juri
6
Pour compliquer davantage les choses, les noms de style (qui sont comme des ID pour les styles) dans les modèles de projet utilisent PascalCase, par exemple AppBaseThemeet AppTheme.
Edward Brey
4
La méthode de soulignement est généralement considérée comme beaucoup moins lisible dans les équipes dans lesquelles j'ai été impliqué. La limitation quelque peu étrange des noms de fichiers de ressources qui ne sont pas autorisés à être dans le cas de chameau ne devrait pas polluer votre réflexion pour le reste des interfaces Java - camelCase est fermement ancré et je ne pense pas que quiconque vous remercierait d'avoir imposé un nouveau style "_" dans les conventions de nommage.
RichieHH
3
@RichardRiley Je trouve cela intéressant, car avec les traits de soulignement, les limites des mots sont correctement définies tandis qu'avec la casse de chameau, elles sont écrasées ensemble, donc j'ai plus de facilité à analyser les noms séparés par des traits de soulignement que ceux à cas de chameau.
JAB
13

Si vous regardez les android.R.id.*champs, vous remarquerez qu'ils sont tous en cas de chameau. Donc, si les identifiants Android sont écrits en camel-case, je suppose que nous devons suivre cette convention :)

Kiril Aleksandrov
la source
Ils sont en cas de chameau là-bas car ils ont été créés en camelCase. Cela ne définit aucun précédent de style de codage pour la communauté dans son ensemble et cela n'est pas lié aux conventions de dénomination des fichiers de ressources par rapport à celles des chaînes d'identification, ce que le poster original demande.
RichieHH
3
Oui, ils ont été créés dans un étui à chameau. Mais ces identifiants proviennent de l'API Android elle-même, donc si le créateur de l'API a utilisé un boîtier camel, je suppose que c'est une bonne approche de suivre sa convention.
Kiril Aleksandrov
8
il widget_framechamp [ developer.android.com/reference/android/R.id.html#widget_frame] également dans les android.R.id.*champs. dans ce domaine utiliser Google ne chameau souligner le cas donc votre conclusion au sujet de la convention de chameau cas est bon pour choisir convention ID peut être faux
ahmed hamdy
4

Je pense que c'est bien si nous utilisons toutes les petites lettres avec des traits de soulignement.

Regarde juste ça

  // Camel Case
    TextView tvUserName = (TextView) findViewById(R.id.tvUserName);
    // Small Caps and Underscores
    TextView tvUserName = (TextView) findViewById(R.id.tv_user_name);

dans ma propre expérience, j'ai tendance à être un peu confus avec la convention de cas de chameau en xml parce que quand vous le liez à Java qui utilise également le cas de chameau (parce que c'est la norme), cela ressemble à un doppleganger.

Rogene Sagmit
la source
Ceci est très subjectif et ne répond pas à la question de savoir pourquoi vous ne pouvez pas nommer les fichiers de ressources de la même manière que vous pouvez identifier des chaînes.
RichieHH
3

Je pense que si nous utilisons la convention de soulignement pour l'identifiant dans les fichiers xml et la convention de cas de camel pour les champs de classe, cela donnera une meilleure visibilité à chaque développeur pour faire la distinction entre les identifiants xml et les champs de classe.

Yasir Ali
la source
3

Si vous regardez certains exemples d'applications Google, tels que:

https://github.com/google/iosched

Ils utilisent des traits de soulignement. Alors ... c'est peut-être ainsi que nous devrions le faire?

Micro
la source
3 
android:id="@+id/frag_account_button"
frag_account_button = ((ListView)view.findViewById(R.id.frag_account_button));

android:id="@+id/fragAccountButton"
fragAccountButton = ((ListView)view.findViewById(R.id.fragAccountButton));

Tout d'abord, il n'y a pas de norme certaine pour définir laquelle est la plus appropriée, mais j'ai ma propre idée à ce sujet. Mon idée est raisonnable de garder l'identifiant XML et la variable java exactement dans le même nom avec la convention camel-case.

  1. Il est facile d'accéder à la variable en recherchant le projet à la fois côté XML et côté Java.

  2. ButterKnife définition de la bibliothèque

    @BindView (R.id.infoTextView) TextViewFont infoTextView;

Il est plus convenable de continuer ainsi.

Samet ÖZTOPRAK
la source
3
La liaison de vue de Kotlin retourne la même chose que butterKnife, donc je supprime complètement snake_case.
Rik Martins
1

Les noms de fichiers xml (qui sont utilisés dans le dossier dessiné) doivent être tous en minuscules séparés par le caractère de soulignement _ car les noms de fichiers en majuscules ne sont pas pris en charge dans xml.

Paul
la source
1
Il ne s'agit pas de noms de fichiers, et d'ailleurs, certaines personnes préfèrent ne pas mettre en majuscule la première lettre lors de l'enveloppe de chameau.
Jesper
C'est une question étrange et inconciliable IMO. Vous ne pouvez pas faire la distinction entre les majuscules et les minuscules, non, mais pourquoi ne pas simplement interdire les fichiers de ressources ayant le même nom de composant racine dans le même répertoire.
RichieHH
(Par ailleurs, il s'agit des noms de fichiers par rapport aux ID de ressources: revérifiez l'OP)
RichieHH
0

Si le compilateur d'Android fait vraiment ce que vous dites en limitant le cas du chameau (ce qui semble plutôt étrange), vous devez vous en tenir aux conventions établies.

Aller à contre-courant ne causera qu'une confusion inutile. Gardez les choses cohérentes partout où cela est possible.

Brock Woolf
la source
Vous avez probablement mal compris ce que j'essayais de dire. Le compilateur se plaindra si vous mettez des ressources comme un fichier et l'écrivez dans le cas du camel. L'autre cas est cependant lorsque vous spécifiez des ID dans les fichiers de mise en page XML. Là, vous avez la possibilité de placer des noms d'identifiant camel-case et l'émulateur fonctionne très bien. Maintenant, comme je l'ai mentionné, les exemples Google sont tous sous la forme my_id_name, mais il y a beaucoup d'autres exemples autour des noms d'identifiants de cas de chameau ...
Juri