2011-04-07 16 views
37

¿Cuáles son algunas convenciones de nomenclatura de archivos de diseño que las personas han creado?Convenciones de nomenclatura de archivos de diseño?

No he encontrado nada en línea, pero pensé en utilizar la siguiente convención.

¿Qué piensan todos?

- activity_* 
- dialog_* 
- list_item_* 

Eso es todo lo que he trabajado hasta ahora.

Además, ¿qué pasa con el nombre de la actividad en contra de su diseño? Por ejemplo:

-> res 
    -> layout 
     -> activity_about_us.xml 
-> src 
    -> activity 
     -> AboutUs.java 

Respuesta

26

Curiosamente, tratando de google esta pregunta sólo trae esta página de resultados tan significativos ... Durante el último medio año utilizo una convención de nombres similar a la suya, pero con prefijos más cortos. Por ejemplo: para la actividad que muestra "Acerca de nosotros" pantalla:

Nombre de clase: ActAboutUs. La clase de prefijo es un poco exagerada, pero distingue claramente las clases de actividad de las demás. Inicialmente utilicé un directorio separado para todas las actividades (similar a su enfoque) pero después de un tiempo me di cuenta de que para aplicaciones más grandes puede ser mejor agrupar en directorios por función que por superclase (es decir, Actividad). Es más fácil para mí trabajar en un solo directorio, por ejemplo, /src/settings/ cuando trabajo en Configuración. De esta manera todos los archivos de Java que necesito están en un solo directorio, así que no tiene que pasear por:

/src/settings/ActSettingsGlobal.java 
/src/settings/ActSettingsNet.java 
/src/settings/Settings.java 
/src/settings/SettingsDBAdapter.java 
/src/settings/etc... 

Este enfoque también ayuda a dividir el trabajo entre los desarrolladores, es decir, cada uno está trabajando en su propia dir en función separada para que no pisen los pies del otro :-).

Algunas personas prefieren sufijos pero los encontré menos útiles. Los prefijos ayudan a agrupar las cosas alfabéticamente como en el ejemplo anterior: el prefijo Act* se ordena primero, por lo que todas las actividades se encuentran convenientemente en la parte superior.

siquiera estoy considerando el uso de Act_ como un prefijo que es más fácil de leer a pesar de que está en conflicto con las convenciones de nombrado de Java ...

Disposición nombre: act_about_us.xml.En res/layout/ no tenemos el "lujo" de subdirectorios que es bastante lamentable por lo que la única manera de agrupar las cosas se usa como prefijo apropiado act_, dlg_, etc ...

Identificadores de cadena: <string name="act_about_us_dlg_help1_title" ... string.xml es el lugar donde tenemos más problemas con el duplicado name s. Es muy fácil crear duplicados si no se utiliza la convención de nomenclatura como activity_element_item. Añade una gran cantidad de tipeo adicional, pero te ahorra mucha confusión más adelante. Para cadenas globales (de aplicación amplia) usamos el prefijo "global_", por ejemplo global_btn_ok, global_msg_no_inet_conn. Por lo general, hacemos que una persona sea responsable de todas las cadenas global_, por lo que si alguien necesita una nueva cadena o cambio, necesita sincronizarse con él para evitar crear un lío.

(ahora me estoy dando cuenta de que activity__element__item (dos guiones) es más clara y fácil de leer que activity_element_item)

en resumen, todavía no puede deshacerse de la sensación de que hay algo mal con mi enfoque, porque yo no puedo creer que Google Devs haya creado un marco tan inconveniente cuando se trata de trabajar con archivos, ID, nombres, etc. ...

+6

Estaba buscando en Google buscando algún tipo de guía para seguirme a mí mismo que, como habrán descubierto, me llevó a publicar esta pregunta. – Salsero69

+0

¿Encontraste una mejor solución? – Shreyans

9

Creo que siguiendo la convención de nombres debe ser sigue

para la actividad

si nuestro nombre de la actividad es

DisplayListActivity 

entonces nuestra layoutname debería ser

display_list_activity.xml 

de elementos de la lista podemos incluir la categoría en la lista de elementos nombre de la presentación

country_list_item.xml 

y para dialogboxes su acción se puede incluir

delete_country_dialog.xml 
5

Al buscar un grupo de diseños, que es como tiendo a trabajar en ellos, Encuentro efectivo preceder siempre al nombre de la clase y el seguimiento con cualquier subdisposición. Por ejemplo:

Clase Nombre:AboutActivity.java
nombre de la presentación:about_activity.xml
Nombre Sub-diseño:about_activity_menu.xml
Sub Nombre Sub-diseño:about_activity_menu_item.xml

Su actividad se siempre estar en la parte superior de cada agrupación y la búsqueda de no actividades se vuelve menos de CA hore ¿Alguien sabe por qué las subcarpetas no son una cosa todavía? Espero eficiencia y simplicidad en el back-end, pero me imagino que no dolería demasiado.

+0

así no es como AndroidStudio lo hace por defecto ... – Nacho

1

La primera parte de un nombre de archivo de disposición siempre debe ser del tipo de la clase correspondiente. Por ejemplo, si tenemos una clase MainActivity (tipo es Activity en este caso), el archivo de diseño correspondiente debería llamarse activity_main.xml

Eso significa que digamos que tenemos un cuadro de diálogo llamado WarningDialog, el archivo de diseño correspondiente debería llamarse dialog_warning.xml , mismo ocurre con los fragmentos etc.

Esto podría parecer familiar porque eso es también cómo los archivos se nombran activity/layout al crear un nuevo proyecto en Android Studio (MainActivity ->activity_main.xml).

0

Ésta es una buena lectura https://jeroenmols.com/blog/2016/03/07/resourcenaming/

Básicamente, se siguen WHAT WHERE DESCRIPTION SIZE

Por ejemplo, archivo de diseño

  • activity_main: ver el contenido de la MainActivity
  • fragment_articledetail : vista para el Articl eDetailFragment

cadenas

  • articledetail_title: título de ArticleDetailFragment
  • feedback_explanation: Explicación de la regeneración en FeedbackFragment

dibujable - all_infoicon_large: gran versión del icono de información genérica - all_infoicon_24dp: 24dp versión del ícono de información genérica

Cuestiones relacionadas