guideline - Convención de nomenclatura de Android

android project naming convention (6)

Cada cuerpo usa el suyo. El objetivo principal es evitar errores y malas interpretaciones, especialmente cuando otros leen su código. Aunque el resaltado de sintaxis y la inspección del código automático en IDE modernos lo hacen bastante menos atractivo.

Pero estas convenciones de nomenclatura también lo hacen muy conveniente cuando se activa la finalización del código. Por ejemplo, simplemente escriba m y autocompletar le mostrará una lista de campos de clase.

Pero muchas veces tienes que trabajar con el código de otro, que no usa esa convención. tales variables protegidas y parámetros de método anulados solo agregan confusión.

Algunos ejemplos:

Prefique las variables de clase con m, y convierta todas las variables estáticas en mayúsculas, con _ palabras separadas. No prefija nada a variables de menor alcance.
El diseño del nombre después del elemento primario de la interfaz de usuario, por ejemplo, frg_detail.xml , itm__act_main__list1.xml , itm__act_main__list1.xml ; para una actividad MainActivity , un fragmento DetailFragment , diseño de elemento para un ListView en MainActivity con id list1 , respectivamente.
Id del elemento de nombre en diseños xml como: lsv__act_main__list1 para un ListView y btn__act_main__submit para un elemento de botón `. Esto los hace mucho más fáciles de encontrar con autocompletar.

Estoy buscando una sugerencia completa de convención de nomenclatura de Android. Encontré un poco aquí:

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

que dice:

Los nombres de los campos no públicos y no estáticos comienzan con m.
Los nombres de los campos estáticos comienzan con s.
Otros campos comienzan con una letra minúscula.
Los campos finales públicos estáticos (constantes) son ALL_CAPS_WITH_UNDERSCORES.

Sin embargo, estoy buscando algo mucho más extenso que abarque todos los aspectos de Android:

cómo nombrar diseños y vistas dentro de,
cómo nombrar menús
cómo nombrar estilos
cómo nombrar las tablas de la base de datos (singular, plural) y los campos dentro de
etc

Si hay alguna sugerencia generalmente aceptada, me encantaría seguir eso. Todos los SDK parecen seguir su propio camino, por lo que estoy particularmente interesado en la forma Android de hacerlo.

Esta es una excelente colección de mejores prácticas para comenzar: https://github.com/futurice/android-best-practices

Esto es lo que uso. También copiaré de ese enlace.

Nombramiento de objetos

No use el prefijo m o s según las pautas de Google. Me detuve durante años y me resulta más fácil sin ellos. El IDE le dirá cuándo está usando algo privado o estático; parece una convención obsoleta.
CONSTANTES comienzan con tapas
Los acrónimos solo deben escribir en mayúscula la primera letra. Por ejemplo, functionUrl y unitId . No unitID .
Prefijo con el tipo de objeto. Por ejemplo, un TextView que contiene un nombre sería tvName . Un EditView con una contraseña sería etPass .
Si se trata de algo que solo se usa una vez en una actividad (por ejemplo, ListView), no tema llamarlo lv .
Si no es un tipo de objeto, simplemente indíquelo por su función. Por ejemplo, si se trata de una cadena que contiene la ID, asígnele el nombre id , no stringId. El IDE le dirá cuándo es una cadena o un flotador o un largo.
Mantenlo legible. Use algo como Pass lugar de Password .
Dentro del XML, el nombre debe ser subrayado sin mayúsculas, por ejemplo, tv_name y et_pass
Coloque el android:id como el primer atributo en el XML.

Nombramiento de archivos

Prefijo diseños con el tipo que es. Ej fragment_contact_details.xml , view_primary_button.xml , activity_main.xml .
Para las clases, categorícelas en carpetas, pero use sufijos. Por ejemplo, /activities/MainActivity.java o /fragments/DeleteDialog.java . Mis carpetas son actividades, fragmentos, adaptadores, modelos y utilidades .
Los adaptadores deben decir cómo y cuándo se usan. Entonces, un adaptador ListView para ChatActivity podría llamarse ChatListAdapter .

colors.xml y dimens.xml como una paleta

Para el color, use nombres como gray_light , not button_foreground .
Para dimens, use nombres como spacing_large , not button_upper_padding .
Si desea establecer algo específico para el color o el relleno de su botón, use un archivo de estilo.

strings.xml

Nombre sus cadenas con claves que se asemejan a espacios de nombres, y no tenga miedo de repetir un valor para dos o más claves.
Use error.message.network , no network_error .

Razonamiento

El propósito de nombrar convenciones no es hacer todo ordenado y consistente . Está ahí para señalar posibles errores y mejorar el flujo de trabajo. La mayoría de estos están diseñados para ser convenientes para atajos de teclado. Trate de enfocarse en minimizar errores y mejorar el flujo de trabajo en lugar de verse bien.

Los prefijos son geniales para aquellos, "¿Cuál es el nombre de ese TextView?" momentos.

Los sufijos están ahí para las cosas a las que no accede tan a menudo de esa manera, pero pueden ser confusas. Por ejemplo, no estoy seguro de si coloco mi código en la Actividad, Fragmento o Adaptador de esa página. Se pueden soltar si quieres.

Los ID XML a menudo están en minúscula y usan guiones bajos simplemente porque todos parecen hacerlo de esta manera.

Los nuevos complementos de Android Eclipse crean algunos de los archivos que mencionas automáticamente cuando creas un nuevo proyecto. A partir de eso, la denominación es algo así:

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

Seguí este esquema con, por ejemplo

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

Por lo tanto, es algo así como los nombres de los paquetes, desde los generales hasta los detallados. También permite una ordenación ordenada.

No creo que haya una convención para esto todavía. cada empresa tiene sus propias reglas y no creo que a nadie le importe mucho aquí.

Para mí, prefiero poner el nombre para estar vinculado al contexto. por ejemplo, si hay una actividad llamada "MainActivity", su nombre de diseño sería "main_activity.xml", y para cada recurso asociado con esta actividad, agrego un prefijo "main_activity" para que sepa que lo usa. Lo mismo ocurre con los identificadores utilizados para esta actividad.

La razón por la que uso esos nombres es que es más fácil encontrarlos, eliminarlos si es necesario y no los reemplazará con otros si usa bibliotecas de Android, ya que los nombres son bastante únicos.

También intento tanto como sea posible para dar nombres significativos, por lo que normalmente no verás "listView" o "imageView2" como ids, sino algo así como "contactsListView" y "contactImageView". el mismo nombre (o similar) también coincidiría con las variables dentro del código java, para que sea más fácil de encontrar.

Entonces, en resumen, mis consejos son:

trata de evitar los números dentro de los nombres. por lo general, no significan mucho, y muestran que solo has usado arrastrar y soltar para el diseñador de UI.
para demos, POC y para preguntas aquí, no se preocupe por nombrar.
intente agregar un prefijo a todos los nombres de los recursos (incluidos los identificadores) para mostrar a qué contexto pertenecen y para lograr la exclusividad.
dar nombres significativos siempre que sea posible.

Las pautas de Android de ribot son un buen ejemplo de las convenciones de nomenclatura estándar:

Convención de nombres para archivos 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

Convención de nomenclatura para componente / widget en archivos xml:

Todos los componentes para la actividad X deben comenzar con el nombre de la actividad. Todos los componentes deben tener un prefijo o un nombre corto como btn para Button Por ejemplo, el nombre para el componente de actividad de inicio de sesión debe ser similar al siguiente.

activity_login_btn_login activity_login_et_username activity_login_et_password

Nombre corto de los componentes principales:

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

CONSISTENCIA
Todos (a menos que trabajen en equipos) tendrán su propia convención y cuál elegir no importa. Asegurarse de que sea consistente durante toda la aplicación sí importa.

ESTRUCTURA
Personalmente, utilizo una convención de nomenclatura como esta, ya que se ejecuta desde el nombre de la clase hasta el componente y es coherente en todo el xml:

CLASE : <ClassName>
ACTIVIDAD : <ClassName>**Activity**
DISEÑO : classname_activity
IDENTIFICADOR DE COMPONENTES : classname_activity_component_name

Un ejemplo de esto sería OrderActivity.class , order_activity.xml , order_activity_bn_cancel . Observe que todo el XML está en minúsculas.

ABREVIATURA DE DISEÑOS
Si desea utilizar nombres más cortos para mantener el código más ordenado; luego otro método puede ser abreviar TODOS los nombres en XML así como los diseños.

Un ejemplo de esto sería OrderActivity .class: ord_act .xml, ord_act _bt_can, ord_act _ti_nam, ord_act _tv_nam. Desglose los nombres en tres, pero esto depende de cuántos nombres similares tenga

ABREVIATAR TIPOS DE COMPONENTES
Al abreviar los tipos de componentes, trate de mantenerlos consistentes también. Normalmente uso dos letras para el tipo de componente y tres letras para el nombre. Sin embargo, a veces el nombre no será necesario si ese es el único elemento de ese tipo en el diseño. El principio de la ID es ser único

nam_act_component_nam COMPONENTES : nam_act_component_nam

ABREVIATURAS DEL TIPO DE COMPONENTE (Esta lista muestra dos letras que son abundantes)
Diseño del marco: fl
Diseño lineal: ll
Diseño de tabla: tl
Fila de tabla: tr
Diseño de cuadrícula: gl
Diseño relativo: rl

Vista de texto: tv
Botón: bt
Casilla de verificación: cb
Switch: sw
Botón de alternancia : tb
Botón de imagen: ib
Vista de imagen: iv
Barra de progreso: pb
Seek Bar: sb
Barra de clasificación: rb
Spinner: sp
WebView: wv
Editar texto: et

Grupo de radio: rg
Vista de lista: lv
Vista de cuadrícula: gv
Vista ampliable de la lista: el
Vista de desplazamiento: sv
Vista de desplazamiento horizontal: hs
Vista de búsqueda: * se
Tab Host: th
Video View: vv
Dialer Filter: df

Incluye: ic
Fragmento: fr
Vista personalizada (otro): cv