Convención de nombres de Android

Estoy buscando una exhaustiva sugerencia de convenciones de nomenclatura para Android. Encontré un poco aquí:

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

Que dice:

  • Los nombres de campos no-públicos, no estáticos comienzan con m.
  • Los nombres de 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 abarca 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 base de datos (singular, plural) y campos dentro de
  • Etc

Si hay alguna sugerencia generalmente aceptada me encantaría seguir eso. Todos los SDK parecen ir a su manera, así que estoy particularmente interesado en la forma de Android para hacerlo.

Las guías para 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 para la actividad de X deben comenzar con el nombre de la actividad que todo el componente debe tener prefijo o nombre corto como btn para el Button Por ejemplo, el nombre para el componente de la actividad de la conexión debe ser como siguiente.

 activity_login_btn_login activity_login_et_username activity_login_et_password 

Nombre corto de los principales componentes:

 Button - btn EditText - et TextView - tv 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 prácticas recomendadas para empezar: https://github.com/futurice/android-best-practices

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

Denominación de objetos

  • No utilice el prefijo m o s según las directrices 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.
  • CONSTANTS comienzan con tapas
  • Los acrónimos sólo deben capitalizar la primera letra. Por ejemplo, functionUrl y unitId . No unitID .
  • Prefijo con el tipo de objeto. Por ejemplo, un TextView que contenga un nombre sería tvName . Una EditView con una contraseña sería etPass .
  • Si es algo que usualmente se usa sólo una vez en una actividad (por ejemplo ListView), no tenga miedo de llamarla simplemente lv .
  • Si no es un tipo de objeto sólo el nombre por su función. Por ejemplo, si es una cadena que contiene el ID, póngalo como id , no stringId. El IDE le dirá cuando es una cadena o un flotador o un largo.
  • Manténgala legible. Usa algo como Pass lugar de Password .
  • Dentro del XML, el nombre debe ser subrayado sin mayúsculas, por ejemplo, tv_name y et_pass
  • Ponga el android:id como el primer atributo en el XML.

Nombre de archivo

  • Prefijo de diseños con el tipo que es. Por ejemplo, fragment_contact_details.xml , view_primary_button.xml , activity_main.xml .
  • Para las clases, clasifíquelas en carpetas, pero utilice 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 utilizan. Por lo tanto, un adaptador ListView para ChatActivity podría llamarse ChatListAdapter .

Colors.xml y dimens.xml como pallete

  • 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 del botón, utilice un archivo de estilo.

Strings.xml

  • Asigne nombres a sus cadenas con claves que se asemejen a espacios de nombres, y no tenga miedo de repetir un valor para dos o más claves.

  • Utilice error.message.network , no network_error .

Razonamiento

El propósito de nombrar convenciones 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 conveniente para atajos de teclado. Trate de 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 que no se accede tan a menudo de esa manera, pero puede ser confuso. Por ejemplo, no puedo estar seguro de si pongo mi código en la actividad, fragmento o adaptador de esa página. Pueden dejarse caer si usted tiene gusto.

Los identificadores XML suelen estar en minúsculas y usan subrayados sólo porque todos parecen hacerlo de esta manera.

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 en el 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, borrarlos si es necesario, y no los reemplazarás con otros si usas las bibliotecas de android ya que los nombres son bastante únicos.

También intento tanto como sea posible dar nombres significativos, por lo que normalmente no verá "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 facilitar su búsqueda.

Así que, en resumen, mis consejos son:

  • Tratar de evitar los números dentro de los nombres. Por lo general no significan mucho, y muestran que sólo has utilizado arrastrar y soltar para el diseñador de interfaz de usuario.

  • Para demos, POCs y para preguntas aquí, no te preocupes por nombrar.

  • Intente agregar un prefijo a todos los nombres de los recursos (incluyendo ids) para mostrar a qué contexto pertenecen y para lograr la unicidad.

  • Dar nombres significativos siempre que sea posible.

CONSISTENCIA
Todo el mundo (a menos que trabajen en equipo) tendrá su propia convención y que uno elige no importa. Asegúrese de que es coherente en toda la aplicación es importante.

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 : ClassNameNameActivity
  • LAYOUT : classname_activity
  • COMPONENT IDS : 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.

ABREVIAR LAYUTS
Si desea utilizar nombres más cortos para mantener el código más ordenado; Entonces otro método puede ser abreviar TODOS los nombres en XML aswell 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. Rompo los nombres en tres, pero esto depende de cuántos nombres similares tenga

ABREVIAR TIPOS DE COMPONENTES
Cuando abreviando los tipos de componente tratar de mantener estos coherente 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 ID es ser único

  • COMPONENT IDS : nam_act_component_nam

TIPO DE COMPONENTE ABREVIATURAS (Esta lista muestra dos letras que es abundante)
Diseño del marco: fl | Diseño Lineal: ll | Diseño de la tabla: tl | Fila de la tabla: tr | Disposición de la rejilla: gl | Disposición relativa: rl

Vista del texto: tv | Botón: bt | Casilla de verificación: cb | Interruptor: sw | Botón de alternancia : tb | Botón de imagen: ib | Vista de la imagen: iv | Barra de progreso: pb | Buscar barra: sb | Puntuación: rb | Spinner: sp | WebView: wv | Editar texto: et

Grupo de Radio: rg | Vista de lista: lv | Vista de cuadrícula: gv | Lista de vista ampliable: el | Vista de desplazamiento: sv | Vista de desplazamiento horizontal: hs | Búsqueda Ver: se | Tab Anfitrión: th | Vista de video: vv | Filtro Dialer: df

Incluye: ic | Fragmento: fr | Personalizada Ver otras imagenes : cv

Cada cuerpo utiliza su propio, El objetivo principal es evitar errores y mala interpretación, especialmente cuando otros leen su código. Aunque el resaltado de sintaxis, y la inspección de código automático en IDE moderno hace bastante punto menos.

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

Pero muchas veces usted tiene que trabajar con el código de otros, que no utiliza tal convención. Tales variables protegidas y parámetros de método anulados sólo añadir a la confusión.

Pocos ejemplos:

  • Prefija las variables de clase con m, y haga que las variables finales estáticas sean mayúsculas, con _ palabras separadas. No prefijar nada a las variables de menor alcance.

  • Diseño de nombre después del padre de la interfaz de usuario, por ejemplo act_main.xml , frg_detail.xml , itm__act_main__list1.xml ; Para una actividad MainActivity , un fragmento DetailFragment , el diseño del elemento para un ListView en MainActivity con id list1 , respectivamente.

  • Las Id de elemento de nombre en diseños xml como: lsv__act_main__list1 para un ListView y btn__act_main__submit para un elemento `Button. Esto hace que sea mucho más fácil de encontrar con auto completo.

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

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

He seguido este esquema con, por ejemplo

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

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

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.