Las convenciones de codificación son un conjunto de pautas para un lenguaje de programación específico que recomiendan estilos , prácticas y métodos de programación para cada aspecto de un programa escrito en ese lenguaje. Estas convenciones generalmente cubren organización de archivos, sangría , comentarios , declaraciones , declaraciones , espacios en blanco , convenciones de nomenclatura , prácticas de programación , principios de programación , reglas generales de programación , mejores prácticas arquitectónicas, etc. Estas son pautas para la calidad estructural del software . Se recomienda encarecidamente a los programadores de software que sigan estas pautas 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 pares de un proyecto de software. Las convenciones pueden formalizarse 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. Los compiladores no imponen las convenciones de codificación .
Reducir el costo de mantenimiento del software es la razón más citada para seguir las convenciones de codificación. En la sección introductoria sobre 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 coste de vida útil de un software se destina a mantenimiento. [3]
- Casi ningún software es mantenido durante toda su vida por el autor original.
- Las convenciones de código 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 envía su código fuente como producto, debe asegurarse de que esté tan bien empaquetado y limpio como cualquier otro producto que cree.
La revisión por pares del software frecuentemente implica la lectura del código fuente. Este tipo de revisión por pares es principalmente una actividad de 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 enviar el código para su revisión. El código escrito utilizando pautas consistentes es más fácil de entender y asimilar para otros revisores, lo que mejora la eficacia del proceso de detección de defectos.
Incluso para el autor original, el software codificado de forma coherente facilita el mantenimiento. No hay garantía de que una persona recuerde la razón precisa por la cual un fragmento de código en particular se escribió de cierta manera mucho después de que el código se escribiera originalmente. Las convenciones de codificación pueden ayudar. El uso constante de espacios en blanco mejora la legibilidad y reduce el tiempo necesario para comprender el software.
Cuando las convenciones de codificación se han diseñado específicamente para producir código de alta calidad y luego se han adoptado formalmente, se convierten en estándares de codificación. Los estilos específicos, independientemente de si se adoptan comúnmente, no producen automáticamente código de buena calidad.
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 trabajos innecesarios, lo que evita costos innecesarios, tanto iniciales como posteriores. Esto se debe simplemente a que si hay menos código, es menos trabajo no sólo para crear la aplicación, sino también para mantenerla.
La complejidad se gestiona tanto en la etapa de diseño (cómo se arquitectura el proyecto) como en la etapa de desarrollo (al tener un código más simple). Si la codificación se mantiene básica y simple, se minimizará la complejidad. Muy a menudo esto implica mantener la codificación lo más "física" posible: codificar de una manera muy directa y no muy abstracta. Esto produce un código óptimo que es fácil de leer y seguir. La complejidad también se puede evitar simplemente no utilizando herramientas complicadas para trabajos sencillos.
Cuanto más complejo sea el código, más probabilidades habrá de que tenga errores, más difíciles serán de encontrar y más probabilidades habrá de que haya errores ocultos.
La refactorización se refiere a una actividad de mantenimiento de software en la que se modifica el código fuente para mejorar la legibilidad o mejorar su estructura. El software a menudo se refactoriza para adaptarlo a los estándares de codificación establecidos por un equipo después de su lanzamiento inicial. Cualquier cambio que no altere el comportamiento del software puede considerarse refactorización. Las actividades de refactorización comunes 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 ágiles de desarrollo de software planifican una refactorización regular (o incluso continua), convirtiéndola en una parte integral del proceso de desarrollo de software del equipo . [5]
Las convenciones de codificación permiten a los programadores tener scripts o programas simples cuyo trabajo es procesar el código fuente para algún propósito distinto a compilarlo en un ejecutable. Es una práctica común contar el tamaño del software ( líneas de código fuente ) para rastrear el progreso actual del proyecto o establecer una línea de base para estimaciones futuras de proyectos .
Unas normas de codificación coherentes pueden, a su vez, hacer que las mediciones sean más coherentes. A menudo se utilizan etiquetas especiales dentro de los comentarios del código fuente para procesar la documentación; dos ejemplos notables son javadoc y doxygen . Las herramientas especifican el uso de un conjunto de etiquetas, pero su uso dentro de un proyecto está determinado por convención.
Las convenciones de codificación simplifican la escritura de software nuevo cuyo trabajo es procesar el software existente. El uso del análisis de código estático ha crecido constantemente desde la década de 1950. Parte del crecimiento de esta clase de herramientas de desarrollo se debe a una mayor madurez y sofisticación de los propios profesionales (y el enfoque moderno en la seguridad ) , pero también a la naturaleza de los propios lenguajes.
Todos los profesionales del software deben enfrentarse al problema de organizar y gestionar una gran cantidad de instrucciones, a veces complejas. Para 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 recopilaran funciones (comportamientos) estrechamente relacionadas en el mismo archivo y recopilaran 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 una práctica escribir el código para una sola clase (pública) en un solo archivo (el convención '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 idioma puede ser un requisito en otro. Las convenciones de idioma 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 a la fuente crean estándares implícitos. Por ejemplo, el código Python tiene una sangría mucho más consistente que, digamos, Perl, porque los espacios en blanco (sangría) son realmente importantes para el intérprete. Python no utiliza la sintaxis de llaves que utiliza Perl para delimitar funciones. Los cambios en la sangría sirven como delimitadores. [8] [9] Tcl , que utiliza 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 } { pone "$i al cuadrado = [expr $i*$i]" incr i } La razón es que en Tcl las llaves no se utilizan sólo para delimitar funciones como en C o Java. De manera más general, las llaves se utilizan 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).
Existe una gran cantidad de convenciones de codificación; consulte Estilo de codificación para ver numerosos ejemplos y debates. Las convenciones de codificación comunes pueden cubrir las siguientes áreas:
Los estándares de codificación incluyen el estándar de codificación CERT C , MISRA C y High Integrity C++ .