Convención de nomenclatura de ID de Android: minúsculas con subrayado frente a caso camel

89

Actualmente estoy programando una aplicación para Android. Ahora lo que descubrí es que no puedes colocar objetos de recursos, digamos, una imagen en la carpeta dibujable y nombrarla como "myTestImage.jpg". Esto le dará un error del compilador, ya que la sintaxis de mayúsculas y minúsculas no está permitida, por lo que tendrá que cambiarle el nombre como "my_test_image.jpg".

Pero, ¿qué pasa con los identificadores que define en el archivo XML? Digamos que tiene la siguiente definición

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

Esta es una definición válida, se compila y funciona bien en mi emulador de Android aunque, como puede ver, estoy especificando la identificación en la sintaxis del caso camel.

Ahora, las muestras de Android siempre usan minúsculas y guiones bajos. ¿Es esto solo una convención de nomenclatura para usar minúsculas con subrayado para las identificaciones o puede causar problemas en el dispositivo real?

Gracias

android mobile Juri
fuente

Respuestas:

87

El dispositivo no se quejará si usa nombres de identificación en mayúsculas y minúsculas. Para mi primera aplicación escribí todos los identificadores en camel-case porque creo que se ve mejor en el código Java de esa manera, y funciona bien.

Sin embargo, estoy cambiando lentamente de opinión sobre camel-case, porque terminas con dos convenciones de nomenclatura diferentes, por ejemplo:

// 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);

Yo también me pregunto acerca de los estándares aquí. Google es inconsistente en sus ejemplos; a veces usan todo en minúsculas, a veces insertan guiones bajos y, a veces, usan camel-case.

Dan Lew
fuente
18
Sí, ese es exactamente mi problema. Te obligan a usar la convención de nomenclatura subrayada para los diseños, mientras que puedes usar camel-case o subrayado para los ID que hacen referencia a controles / widgets dentro de las definiciones de diseño XML. Google realmente debería definir algún estándar aquí (si no lo hicieron ya, al menos no encontré nada). Por lo tanto, optar por un solo camino es sin duda lo mejor para ser coherente en toda la aplicación, ya sea que haga referencia a diseños o campos con referencias de identificación.
Juri
Solo por curiosidad: ¿Tiene un enlace donde Google es inconsistente, es decir, dónde usaron la notación de caso de camello para los identificadores?
Juri
6
Para confundir aún más las cosas, los nombres de estilo (que son como ID de estilos) en las plantillas del proyecto usan PascalCase, por ejemplo AppBaseThemey AppTheme.
Edward Brey
4
El método de subrayado generalmente se considera mucho menos legible en los equipos en los que he estado involucrado. La limitación algo extraña de los nombres de los archivos de recursos que no se permiten en camel case no debería contaminar su pensamiento para el resto de las interfaces de Java: camelCase es firmemente arraigado y no creo que nadie te agradecería por imponer un nuevo estilo "_" en las convenciones de nomenclatura.
RichieHH
3
@RichardRiley Me parece interesante, ya que con los subrayados los límites de las palabras están correctamente definidos, mientras que con el caso de camello están aplastados, por lo que me resulta más fácil analizar los nombres separados por subrayado que los de camello.
JAB
13

Si miras los android.R.id.*campos, notarás que todos están en caja de camello. Entonces, si los identificadores de Android están escritos en camel-case, supongo que tenemos que seguir esta convención :)

Kiril Aleksandrov
fuente
Están en el estuche de camello porque fueron creados en camelCase. Esto no establece ningún precedente de estilo de codificación para la comunidad en general y no está vinculado a las convenciones de nomenclatura de los archivos de recursos frente a las de las cadenas de identificación, que es lo que pregunta el autor original.
RichieHH
3
Sí, fueron creados en estuche de camello. Pero estas ID son de la propia API de Android, por lo que si el creador de la API ha usado camel case, supongo que es un buen enfoque seguir su convención.
Kiril Aleksandrov
8
hay widget_framecampo [ developer.android.com/reference/android/R.id.html#widget_frame] también en los android.R.id.*campos. en este campo de uso Google subrayan no camello de los casos lo tanto, su conclusión acerca de camello caso convención es correcto elegir para la convención de identificación puede ser falso
Ahmed Hamdy
4

Creo que es bueno si usamos todas las letras minúsculas con guiones bajos.

Solo mira esto (agregando a lo que Daniel había respondido)

  // Camel Case
    TextView tvUserName = (TextView) findViewById(R.id.tvUserName);

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

en mi propia experiencia, tiendo a confundirme un poco con la convención de caso camel en xml porque cuando lo vincula a Java, que también usa caso camel (porque es el estándar), parece un doppleganger.

Rogene Sagmit
fuente
Esto es muy subjetivo y no responde a la pregunta de por qué no puede nombrar archivos de recursos de manera similar como puede identificar cadenas.
RichieHH
3

Creo que si usamos la convención de subrayado para la identificación en archivos xml y la convención de caso camel para los campos de clase, entonces todos los desarrolladores tendrán una mejor visibilidad para distinguir entre los identificadores xml y los campos de clase.

Yasir Ali
fuente
3

Si observa algunas de las muestras de aplicaciones de Google, como:

https://github.com/google/iosched

Usan guiones bajos. Entonces ... ¿tal vez así es como deberíamos hacerlo?

Micro
fuente
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));

En primer lugar, no existe un estándar seguro para definir cuál es más adecuado, pero tengo mi propia idea al respecto. Mi idea es razonable para mantener la identificación XML y la variable java exactamente con el mismo nombre con la convención camel-case.

  1. Es fácil llegar a la variable buscando el proyecto tanto en XML como en java.

  2. Definición de biblioteca butterKnife

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

Es más apropiado mantenerlo así.

Samet ÖZTOPRAK
fuente
3
El enlace de vista de Kotlin devuelve lo mismo que butterKnife, por lo que descarto snake_case por completo.
Rik Martins
1

Los nombres de archivo xml (que es lo que se usa en la carpeta dibujable) deben estar todos en minúscula separados por el carácter de subrayado _ ya que los nombres de archivo en mayúsculas no son compatibles con xml.

Paul
fuente
1
No se trata de nombres de archivos y, además, algunas personas prefieren no poner en mayúscula la primera letra cuando se coloca en mayúsculas.
Jesper
En mi opinión, es un problema extraño e inconsecuente. No puede distinguir entre mayúsculas y minúsculas para distinguir, no, pero ¿por qué no prohibir los archivos de recursos que tienen el mismo nombre del componente raíz en el mismo directorio?
RichieHH
(Por cierto, se trata de nombres de archivos frente a ID de recursos: vuelva a
verificar
0

Si el compilador de Android realmente está haciendo lo que dices al restringir el caso de camello (que parece bastante extraño), entonces debes ceñirte a las convenciones establecidas.

Ir en contra de la corriente solo provocará una confusión innecesaria. Mantenga las cosas consistentes en todos los lugares donde sea posible.

Brock Woolf
fuente
Probablemente entendiste mal lo que estaba tratando de decir. El compilador se quejará si pones recursos como un archivo y lo escribes en caso de camello. Sin embargo, el otro caso es cuando especifica ID en los archivos de diseño XML. Allí tiene la posibilidad de colocar nombres de identificación de caso de camello y el emulador funciona bien. Ahora, como mencioné, las muestras de Google tienen el formato my_id_name, pero hay muchas otras muestras en torno a tener nombres de identificación de casos de camello ...
Juri