Convención de nomenclatura de Android

Estoy buscando una sugerencia completa de la 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 campo 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 estáticos públicos (constantes) son ALL_CAPS_WITH_UNDERSCORES.

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

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

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

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

Convención de nomenclatura 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 de X actividad debe comenzar con el nombre de la actividad de todo componente debe tener prefijo o nombre corto como BTN para Button Por ejemplo, el nombre de componente de actividad de inicio de sesión debe ser como la 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

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.

Nomenclatura de objetos

• No use el prefijo mo ssegún las pautas de Google. He parado durante años y me resulta más fácil sin ellos. El IDE le dirá cuando esté usando algo privado o estático; parece una convención obsoleta.
• Las CONSTANTES comienzan con mayúsculas
• Los acrónimos solo deben escribir en mayúscula la primera letra. Por ejemplo, functionUrly unitId. No unitID.
• Prefijo con el tipo de objeto. Por ejemplo, un TextView que contiene un nombre sería tvName. Un EditView con contraseña sería etPass.
• Si es algo que generalmente se usa solo una vez en una actividad (por ejemplo, ListView), no tenga miedo de llamarlo lv.
• Si no es un tipo de objeto, simplemente nómbrelo por su función. Por ejemplo, si es una cadena que contiene el ID, idasígnele el nombre , no stringId. El IDE le dirá cuándo es una cadena, un flotante o un largo.
• Manténgalo legible. Use algo como en Passlugar de Password.
• Dentro del XML, el nombre debe estar subrayado sin mayúsculas, por ejemplo, tv_nameyet_pass
• Coloque el android:idcomo primer atributo en el XML.

Nombre de archivo

• Prefije diseños con el tipo que es. Por ejemplo 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.javao /fragments/DeleteDialog.java. Mis carpetas son actividades, fragmentos, adaptadores, modelos y utilidades .
• Los adaptadores deben decir cómo y cuándo se utilizan. Por lo tanto, podría llamarse un adaptador ListView para ChatActivityChatListAdapter .

colors.xml y dimens.xml como paleta

• Para el color, use nombres como gray_light, no button_foreground.

• Para dimens, use nombres como spacing_large, no 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

• Nombra tus cadenas con claves que se asemejen a espacios de nombres, y no temas repetir un valor para dos o más claves.

• Use error.message.network, no network_error.

Razonamiento

El propósito de las convenciones de nomenclatura no es hacer que todo sea 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 los atajos de teclado. Intente concentrarse en minimizar los errores y mejorar el flujo de trabajo en lugar de verse bien.

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

Los sufijos están ahí para las cosas a las que no accede con tanta frecuencia de esa manera, pero pueden ser confusas. Por ejemplo, es posible que no esté seguro de si coloco mi código en la Actividad, Fragmento o Adaptador de esa página. Se pueden soltar si lo desea.

Los identificadores XML suelen estar en minúsculas y utilizan guiones bajos solo porque todo el mundo parece hacerlo de esta manera.

CONSISTENCIA
Todos (a menos que trabajen en equipo) tendrán su propia convención y no importa cuál elijas. Es importante asegurarse de que sea coherente en toda la aplicación.


ESTRUCTURA
Personalmente, uso 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
• ID 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.

DISEÑOS ABREVIENTES
Si desea utilizar nombres más cortos para mantener el código más ordenado; entonces otro método puede ser abreviar TODO 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. Divido los nombres en tres, pero esto depende de cuántos nombres similares tenga

ABREVIAR LOS TIPOS DE COMPONENTES
Al abreviar los tipos de componentes, intente mantenerlos consistentes también. Normalmente utilizo 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 identificación es ser único

• ID DE COMPONENTES :nam_act_component_nam

ABREVIATURAS DE TIPO DE COMPONENTE (Esta lista muestra dos letras que son suficientes)
Diseño de 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
Interruptor: sw
Botón de alternancia : tb
Botón de imagen: ib
Vista de imagen: iv
Barra de progreso: pb
Barra de búsqueda: 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 de lista expansible: el
Vista de desplazamiento: sv
Vista de desplazamiento horizontal: hs
Vista de búsqueda: * se
Pestaña Host: th
Vista de video: vv
Filtro de marcador: df

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

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 ligado 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 saber que lo usa. Lo mismo ocurre con los identificadores utilizados para esta actividad.

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

También trato tanto como sea posible de dar nombres significativos, por lo que normalmente no verá "listView" o "imageView2" como identificadores, sino algo 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:

• trate de evitar los números dentro de los nombres. por lo general, no significan mucho y muestran que solo ha utilizado arrastrar y soltar para el diseñador de interfaz de usuario.

• para demostraciones, POC y 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 lograr la singularidad.

• dar nombres significativos siempre que sea posible.

Los complementos más nuevos de Android Eclipse crean algunos de los archivos que menciona automáticamente cuando crea un nuevo proyecto. A partir de eso, el nombre es algo así:

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

Seguí este esquema con eg

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

Es algo así como con los nombres de los paquetes, de general a detallado. También permite una clasificación ordenada.

Cada uno 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 automática de código en los IDE modernos lo hacen bastante menos importante.

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

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

Pocos ejemplos:

• Prefije las variables de clase con m y convierta las variables finales estáticas en mayúsculas, con _palabras de separación. No agregue nada a las variables de alcance inferior.

• Disposición nombre después de que el padre de interfaz de usuario, por ejemplo act_main.xml, frg_detail.xml, itm__act_main__list1.xml; para una actividad MainActivity, un fragmento DetailFragment, disposición artículo para un ListViewen MainActivitycon id list1, respectivamente.

• Nombre los ID de los elementos en diseños xml como: lsv__act_main__list1para un ListView y btn__act_main__submitpara un elemento `Button. Esto los hace mucho más fáciles de encontrar con la función de autocompletar.

En cuanto a las convenciones de nomenclatura y / o las mejores prácticas, a menudo sigo este archivo md del repositorio ribot / android- Guidelines en github que tiene pautas de proyecto y codificación incluidas en él.