Capacitación en Java de Beida Jade Bird: ¿Cómo estandarizar sus propios métodos de edición de código?

Hoy analizamos los requisitos para la escritura de código estandarizado.

Espero que al leer este artículo pueda mejorar mi comprensión de las especificaciones del código.

1. Asegúrese de que no haya errores después de la compresión del código. Para proyectos JSP grandes, todos los archivos JSP incluidos en el proyecto generalmente se comprimen cuando se lanza el producto. Por ejemplo, puede utilizar GoogleClosureCompilerService para comprimir código. Las versiones más nuevas de jQuery utilizan esta herramienta para minimizar el código, lo que a menudo elimina los comentarios escritos durante el desarrollo y elimina todos los espacios y nuevas líneas. Incluso puedes reemplazar un nombre de variable largo por uno corto y sin sentido. El propósito de esto es acelerar la descarga de archivos y reducir el tráfico de datos adicional causado por las visitas al sitio web. Además, también desempeña un papel en la protección del código. Al menos el código comprimido no es tan fácil de leer incluso después de la restauración.

Para que el código pase la compresión correctamente, generalmente se requiere que las declaraciones terminen normalmente con punto y coma, las llaves deben terminar estrictamente, etc. , dependiendo de los requisitos de la herramienta de compresión.

Entonces, si no sigues los estándares al principio y luego regresas para encontrar los errores después de comprimirlos, será una pérdida de tiempo.

2. Asegúrese de que el código pueda pasar la función de formato automático del IDE específico. Generalmente, las herramientas de desarrollo relativamente completas (como Aptana Studio) tienen la función de "formateo automático" del código, lo que ayuda a lograr una disposición unificada del código, como saltos de línea, sangrías y espacios. Puede establecer sus estándares de formato favoritos, como abrir llaves { o comenzar una nueva línea.

El propósito de implementar este requisito es facilitar que los miembros del equipo de desarrollo tomen una copia del código y usen el IDE para formatearlo automáticamente en un estilo que les guste o con el que estén familiarizados.

Tu colega necesita ver tu código, tal vez porque escribiste un método general, y también necesita usarlo en el desarrollo de otros módulos. Leer su código puede proporcionar información sobre las llamadas a métodos y los detalles de implementación que la simple documentación de API no puede proporcionar.

3. El requisito de utilizar comentarios de documentos estándar es básico, lo que resulta beneficioso para ver los parámetros específicos del método en la llamada al método. También puede utilizar herramientas de documentación de respaldo para generar documentación de desarrollo en html u otros formatos para que la lean otros miembros del equipo. Puedes intentar usar jsdoc-toolkit.

Si su API generada automáticamente proviene de una plataforma abierta, como la aplicación facebook.com, entonces su documentación está lista para todos los desarrolladores de todo el mundo.

Además, escribir comentarios completos facilita que los miembros del equipo lean su código. A través de la descripción de su parámetro, los miembros del equipo pueden conocer fácilmente los detalles del método que escribió y participar en la implementación.

Por supuesto, también facilitará el mantenimiento futuro del código, de modo que incluso si es un gran proyecto, después de mucho tiempo, no olvidarás lo que escribiste en ese momento cuando regreses y cambies las cosas. .

4. Utilice nombres de variables estandarizados y significativos. El uso de nombres de variables estandarizados y significativos mejora la legibilidad del código. Como miembro del desarrollo de proyectos a gran escala, el código que escribe no solo es fácil de entender para otros.

Capacitación en informática/Piense en el desarrollo de grandes proyectos. De hecho, es posible que todos hayan escrito mucho código y hayan estandarizado los nombres. Más adelante, mirando hacia atrás, será claro y fácil de entender. como actualizaciones del sistema o nuevas funciones en el futuro, es mucho más fácil modificar el código.

Si ahora descubres que ni siquiera puedes entender el código que escribiste originalmente, estás totalmente equivocado.