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. ...
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
¿Encontraste una mejor solución? – Shreyans