Estándares de codificación, organización de sucursales de Git

Convención de nomenclatura de códigos

Convención de nomenclatura de paquetes

Adopte reglas de nomenclatura de nombres de dominio y utilice todas las letras minúsculas. El nombre del paquete de primer nivel es com, el nombre del paquete de segundo nivel es kl (es el nombre de la empresa, que puede abreviarse), el nombre del paquete de tercer nivel es pos (nombrado según la aplicación), el de cuarto nivel El nombre del paquete es actividad o adaptador, etc. (nombre del módulo o nombre del nivel), según En situaciones reales, también puede utilizar nombres de paquetes de cinco niveles y nombres de paquetes de seis niveles. Por ejemplo: com.kl.pos.actividad | com.kl.pos.adapter

Convención de nomenclatura de proyectos especiales

Puede agregar un prefijo de proyecto fijo según las especificaciones existentes, como el proyecto kl, la Actividad se puede cambiar a KlLoginActivity y el Diseño puede ser kl_activity_login. Para evitar que se haga referencia a este proyecto especial, hay muchos archivos con el mismo nombre al buscar archivos y los costos de modificación y mantenimiento son altos.

Método de denominación de archivos de clase

La denominación de actividades siempre utiliza el nombre del módulo + Actividad. Por ejemplo: Actividad de inicio de sesión, Actividad de usuario.
La denominación de fragmentos siempre utiliza el nombre del módulo + Fragmento. Por ejemplo: Fragmento de inicio, Fragmento de tiempo.
Personalizar el nombre de la función Ver + Ver/VerGrupo (nombre de componente específico). Por ejemplo: WhiteLayout, RatingView,
nombre de la función del componente del widget + widget. Por ejemplo: ScanWidget, WeatherWidget.
Nombre de la función del cuadro de diálogo + Diálogo. Por ejemplo: LoginDialog, ProgressDialog.
La denominación del adaptador siempre utiliza el nombre del módulo + Fragmento. Por ejemplo: HomeAdapter, WeatherAdapter.

Denominación de diseño

Actividad nombre del módulo_actividad. Por ejemplo, R.layout.activity_login
Fragmento nombre del módulo_fragmento. Por ejemplo, R.layout.fragment_login_layout_header
Incluye nombre del módulo de diseño_nombre de la función. Por ejemplo, @layout/layout_login_bottom
Elemento del adaptador_nombre del módulo_nombre de la función. Por ejemplo, R.layout.item_simple_text
Dialog dialog_module_function nombre. Por ejemplo R.layout.dialog_time_picker

Nomenclatura de archivos de recursos de valores

color nombre del módulo_color. Por ejemplo color_material_design
dimensiones dimens_module nombre. Por ejemplo, dimens_material_design
estilo style_module nombre. Por ejemplo, style_material_design
temas temas_nombre del módulo. Por ejemplo, temas_material_diseño
cadenas cadenas_nombre del módulo. Por ejemplo strings_meatrial_design otros módulos y así sucesivamente

Convención de nomenclatura de interfaz

Las reglas de nomenclatura son las mismas que las de las clases, utilizando el método de nomenclatura big camel case, que generalmente comienza con I mayúscula (abreviatura de interfaz) o termina con able o ible, como interfaz Runnable; interfaz Accesible. O consulte una interfaz de Android similar. Como el evento de clic OnClickListener, etc.

Denominación de variables

Las variables miembro utilizan el método de denominación en caso de camello nombre de usuario nombre de dispositivo.

Denominación constante

Las letras están en mayúsculas y las palabras están separadas por guiones bajos _. Con respecto al método de denominación de constantes, en el código JAVA se recomienda utilizar constantes para reemplazar números y cadenas fijas en cualquier momento. En otras palabras, excepto 0 y 1, otros números no deben aparecer en el programa. Si se pueden reemplazar 0 y 1, no se permite que aparezcan. Las constantes se pueden definir al principio del programa o en un ámbito más amplio. Los nombres deben estar en letras mayúsculas e indicar el significado completo de la constante. Si un nombre constante consta de varias palabras, las palabras deben estar separadas por un guión bajo "_", como por ejemplo: NUM_DAYS_IN_WEEK, MAX_VALUE.

Reglas de nomenclatura de sucursales

Función-número de versión-prefijo de rama
El prefijo de rama es obligatorio, las ramas maestra y de desarrollo no necesitan contener números de versión y la rama de lanzamiento principal no necesita contener información funcional.

Reglas de prefijo de rama

rama	describir	¿Es una sucursal protegida?
maestro	rama maestra	Sí
desarrollar	rama principal de desarrollo	Sí
liberar	rama de liberación	Sí
característica	rama característica	No
revisión	rama de modificación de errores	No
faena	Agregue ramas de compilación, automatización y configuración mediante scripts	No

Diagrama de flujo de relación de sucursales

Proceso de operación de sucursales

nueva función

Corte de la rama de desarrollo y asígnele el nombre característica-versión número-función
El envío del código del proyecto KL debe llevar el número de tarea o el número de error
Una vez desarrollada la función, se entrega a los evaluadores para que la prueben.
Pruebe la combinación en la rama de desarrollo y verifique eliminar la rama original.

Correcciones de errores funcionales

Corte de la rama de desarrollo y asígnele el nombre hotfix-version number-function
El envío del código del proyecto KL debe llevar el número de tarea o el número de error
La corrección de errores se completa y se entrega a los evaluadores para que la prueben.
Pruebe la combinación en la rama de desarrollo y verifique eliminar la rama original.

Preparación de la rama de lanzamiento de versión

Corte de la rama de desarrollo y asígnele el nombre versión-versión número-función
versión alfa: asígnele el nombre versión-versión número-alfa Por ejemplo: versión/2.2.0-alfa versión
beta: asígnele el nombre versión-versión número-beta Por ejemplo: lanzamiento /2.2 .0-beta
versión lanzada oficialmente: número de versión de lanzamiento denominado, por ejemplo: lanzamiento/2.2.0
Después de modificar los pasos básicos, como el número de versión y el corte del servidor, envíe el código y adjunte el número de tarea.
Antes de publicar la versión, combínela en la rama master y etiquétela
Siga el proceso de lanzamiento de la versión

Reglas de eliminación de sucursales

Las ramas fusionadas en desarrollo deben eliminarse lo antes posible.
La rama de versión principal no se puede eliminar
Si la rama actual se pospone hasta que la versión especificada esté en línea, el número de versión de la rama debe modificarse a tiempo y las versiones caducadas deben limpiarse de manera oportuna.