Articulo de referencia

Convenciones de codificación

Código fuente en Bash Las convenciones de codificación son un conjunto de directrices para un lenguaje de programación específico que recomiendan el estilo , las prácticas y los...

Código fuente en Bash

Las convenciones de codificación son un conjunto de directrices para un lenguaje de programación específico que recomiendan el estilo , las prácticas y los métodos de programación para cada aspecto de un programa escrito en ese lenguaje. Estas convenciones suelen abarcar la organización de archivos, la indentación , los comentarios , las declaraciones , las sentencias , los espacios en blanco , las convenciones de nomenclatura , las prácticas de programación , los principios de programación, las reglas generales de programación, las mejores prácticas arquitectónicas, etc. Son directrices para la calidad estructural del software . Se recomienda encarecidamente a los programadores de software que sigan estas directrices para ayudar a mejorar la legibilidad de su código fuente y facilitar el mantenimiento del software . Las convenciones de codificación solo son aplicables a los mantenedores humanos y revisores por pares de un proyecto de software. Las convenciones pueden estar formalizadas en un conjunto documentado de reglas que sigue todo un equipo o empresa, [ 1 ] o pueden ser tan informales como las prácticas de codificación habituales de un individuo. Las convenciones de codificación no son impuestas por los compiladores .

Mantenimiento de software

Reducir el costo del mantenimiento del software es la razón más citada para seguir las convenciones de codificación. En la sección introductoria sobre las convenciones de código para el lenguaje de programación Java, Sun Microsystems ofrece el siguiente razonamiento: [ 2 ]

Las convenciones de código son importantes para los programadores por varias razones:

  • Entre el 40% y el 80% del costo total de un software a lo largo de su vida útil se destina a mantenimiento. [ 3 ]
  • Prácticamente ningún software recibe mantenimiento durante toda su vida útil por parte de su autor original.
  • Las convenciones de codificación mejoran la legibilidad del software, lo que permite a los ingenieros comprender el código nuevo de forma más rápida y exhaustiva.
  • Si distribuyes tu código fuente como un producto, debes asegurarte de que esté tan bien empaquetado y limpio como cualquier otro producto que crees.

Calidad

La revisión por pares de software suele implicar la lectura del código fuente. Este tipo de revisión se centra principalmente en la detección de defectos . Por definición, solo el autor original de un fragmento de código ha leído el archivo fuente antes de que el código se envíe para su revisión. El código escrito siguiendo directrices consistentes es más fácil de comprender y asimilar para otros revisores, lo que mejora la eficacia del proceso de detección de defectos.

Incluso para el autor original, un software codificado de forma consistente facilita su mantenimiento. No hay garantía de que una persona recuerde la razón precisa por la que un fragmento de código se escribió de cierta manera mucho después de su creación. Las convenciones de codificación pueden ser de gran ayuda. El uso consistente de espacios en blanco mejora la legibilidad y reduce el tiempo necesario para comprender el software.

Estándares de codificación

Cuando las convenciones de codificación se diseñan específicamente para producir código de alta calidad y se adoptan formalmente, se convierten en estándares de codificación. Los estilos específicos, independientemente de su uso común, no garantizan automáticamente la obtención de código de buena calidad.

Reducción de la complejidad

La complejidad es un factor que va en contra de la seguridad. [ 4 ]

La gestión de la complejidad incluye el siguiente principio básico: minimizar la cantidad de código escrito durante el desarrollo del proyecto. Esto evita trabajo innecesario y, por consiguiente, costes innecesarios, tanto iniciales como posteriores. Esto se debe a que, si hay menos código, se requiere menos trabajo no solo para crear la aplicación, sino también para mantenerla.

La complejidad se gestiona tanto en la fase de diseño (cómo se estructura el proyecto) como en la de desarrollo (mediante un código más sencillo). Si el código se mantiene básico y simple, la complejidad se minimiza. A menudo, esto implica que el código sea lo más directo posible, evitando la abstracción excesiva. Esto produce un código óptimo, fácil de leer y comprender. La complejidad también puede evitarse simplemente no utilizando herramientas complicadas para tareas sencillas.

Cuanto más complejo sea el código, mayor será la probabilidad de que contenga errores, más difícil será encontrar los errores y mayor será la probabilidad de que haya errores ocultos.

Refactorización

La refactorización se refiere a una actividad de mantenimiento de software en la que se modifica el código fuente para mejorar su legibilidad o estructura. El software se suele refactorizar para que cumpla con los estándares de codificación establecidos por el equipo tras su lanzamiento inicial. Cualquier cambio que no altere el comportamiento del software puede considerarse refactorización. Algunas actividades comunes de refactorización son cambiar nombres de variables, renombrar métodos, mover métodos o clases completas y dividir métodos (o funciones ) grandes en otros más pequeños.

Las metodologías de desarrollo de software ágil planifican la refactorización regular (o incluso continua), convirtiéndola en una parte integral del proceso de desarrollo de software del equipo . [ 5 ]

Automatización de tareas

Las convenciones de codificación permiten a los programadores tener scripts o programas sencillos cuya función es procesar el código fuente para un propósito distinto al de compilarlo en un ejecutable. Es práctica común contar el tamaño del software ( líneas de código fuente ) para realizar un seguimiento del progreso del proyecto actual o establecer una base para las estimaciones de proyectos futuros .

Los estándares de codificación consistentes pueden, a su vez, hacer que las mediciones sean más consistentes. Las etiquetas especiales dentro de los comentarios del código fuente se utilizan a menudo para procesar la documentación; dos ejemplos notables son javadoc y doxygen . Estas herramientas especifican el uso de un conjunto de etiquetas, pero su uso dentro de un proyecto viene determinado por convención.

Las convenciones de codificación simplifican la escritura de nuevo software cuya función es procesar el software existente. El uso del análisis estático de código ha crecido de forma constante desde la década de 1950. Parte de este crecimiento se debe a la mayor madurez y sofisticación de los propios profesionales (y al enfoque actual en la seguridad ), pero también a la naturaleza de los lenguajes de programación en sí .

Factores lingüísticos

Todos los profesionales del software deben lidiar con el problema de organizar y administrar una gran cantidad de instrucciones, a veces complejas. Para casi todos los proyectos de software, excepto los más pequeños, el código fuente (instrucciones) se divide en archivos separados y, frecuentemente, entre muchos directorios . Era natural que los programadores agruparan funciones (comportamientos) estrechamente relacionadas en el mismo archivo y agruparan archivos relacionados en directorios. A medida que el desarrollo de software pasó de la programación puramente procedimental (como la que se encuentra en FORTRAN ) hacia construcciones más orientadas a objetos (como las que se encuentran en C++ ), se convirtió en práctica escribir el código para una sola clase (pública) en un solo archivo (la convención de "una clase por archivo"). [ 6 ] [ 7 ] Java ha ido un paso más allá: el compilador de Java devuelve un error si encuentra más de una clase pública por archivo.

Una convención en un lenguaje puede ser un requisito en otro. Las convenciones de lenguaje también afectan a los archivos fuente individuales. Cada compilador (o intérprete) utilizado para procesar el código fuente es único. Las reglas que un compilador aplica al código fuente crean estándares implícitos. Por ejemplo, el código Python tiene una indentación mucho más consistente que, digamos, Perl, porque el espacio en blanco (indentación) es realmente significativo para el intérprete. Python no utiliza la sintaxis de llaves que Perl usa para delimitar funciones. Los cambios en la indentación sirven como delimitadores. [ 8 ] [ 9 ] Tcl , que usa una sintaxis de llaves similar a Perl o C/C++ para delimitar funciones, no permite lo siguiente, lo que parece bastante razonable para un programador de C:

establecer i = 0 mientras { $i < 10 } { poner "$i al cuadrado = [expr $i*$i]" incrementar i }

La razón es que en Tcl, las llaves no se usan solo para delimitar funciones como en C o Java. De manera más general, las llaves se usan para agrupar palabras en un solo argumento. [ 10 ] [ 11 ] En Tcl, la palabra while toma dos argumentos, una condición y una acción . En el ejemplo anterior, a while le falta su segundo argumento, su acción (porque Tcl también usa el carácter de nueva línea para delimitar el final de un comando).

convenciones comunes

Existen numerosas convenciones de codificación; consulte Estilo de codificación para ver numerosos ejemplos y explicaciones. Las convenciones de codificación comunes pueden abarcar las siguientes áreas:

Los estándares de codificación incluyen el estándar de codificación CERT C , MISRA C y High Integrity C++ .

Véase también

Referencias

  1. "EditorConfig ayuda a los desarrolladores a definir y mantener estilos de codificación consistentes entre diferentes editores e IDE" . EditorConfig .
  2. "Convenciones de código para el lenguaje de programación Java : ¿Por qué existen las convenciones de código?" . Sun Microsystems, Inc. 20 de abril de 1999. 
  3. Robert L. Glass: Hechos y falacias de la ingeniería de software; Addison Wesley, 2003.
  4. Tom Gillis. "La complejidad es enemiga de la seguridad" .
  5. Jeffries, Ron (8 de noviembre de 2001). "¿Qué es la Programación Extrema?: Mejora del Diseño" . Revista XP. Archivado del original el 15 de diciembre de 2006. 
  6. Hoff, Todd (2007-01-09). "Estándar de codificación de C++ : Nomenclatura de archivos de clase" . 
  7. Estándares de codificación FIFE
  8. van Rossum, Guido (19 de septiembre de 2006). Fred L. Drake, Jr. (ed.). "Tutorial de Python : Primeros pasos hacia la programación" . Python Software Foundation. Archivado del original el 28 de septiembre de 2008. Consultado el 17 de agosto de 2014 . 
  9. Raymond, Eric (1 de mayo de 2000). "¿Por qué Python?" . Linux Journal.
  10. Tcl Developer Xchange. "Resumen de la sintaxis del lenguaje Tcl" . ActiveState.
  11. Staplin, George Peter (16 de julio de 2006). "¿Por qué no puedo empezar una nueva línea antes de un grupo de llaves?" . 'The Tcler's Wiki'.