Las convenciones de codificación son un conjunto de pautas para un lenguaje de programación específico que recomiendan el estilo de programación , las prácticas y los métodos para cada aspecto de un programa escrito en ese lenguaje. Estas convenciones generalmente cubren la organización de archivos, la sangría , los comentarios , las declaraciones , las instrucciones , 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. 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 se aplican 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 una 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 .
La reducción del coste de 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 codificación 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 al mantenimiento. [3]
- Casi ningún software recibe mantenimiento durante toda su vida por parte del autor original.
- Las convenciones de código mejoran la legibilidad del software, lo que permite a los ingenieros comprender el código nuevo más rápida y completamente.
- 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 de software suele implicar 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 siguiendo pautas coherentes 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 manera coherente facilita el mantenimiento. No hay garantía de que una persona recuerde la razón precisa por la que un fragmento de código en particular se escribió de cierta manera mucho después de que se escribió originalmente. Las convenciones de codificación pueden ayudar. El uso coherente de espacios en blanco mejora la legibilidad y reduce el tiempo que lleva 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 o no, 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 trabajo innecesario, lo que a su vez evita costes innecesarios, tanto iniciales como posteriores. Esto se debe simplemente a que si hay menos código, es menos trabajo no solo crear la aplicación, sino también mantenerla.
La complejidad se gestiona tanto en la fase de diseño (cómo se estructura el proyecto) como en la fase de desarrollo (mediante la utilización de un código más sencillo). 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 que sea muy directa y no demasiado 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 hay de que tenga errores, más difícil será encontrarlos 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 suele refactorizarse para que cumpla con 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 más comunes son cambiar los nombres de las variables, renombrar los métodos, mover métodos o clases enteras y dividir los métodos grandes (o funciones ) en otros más pequeños.
Las metodologías de desarrollo de software ágiles planifican una refactorización regular (o incluso continua), lo que la convierte en una parte integral del proceso de desarrollo de software en equipo . [5]
Las convenciones de codificación permiten a los programadores tener scripts o programas simples cuyo trabajo es procesar código fuente para algún propósito que no sea compilarlo en un ejecutable. Es una 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 línea base para estimaciones futuras del proyecto .
A su vez, los estándares de codificación consistentes pueden 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 . 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 cuya función es procesar software existente. El uso del análisis de código estático ha crecido de manera constante 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 al enfoque moderno en la seguridad ), pero también a la naturaleza de los propios lenguajes.
Todos los profesionales del software deben lidiar con el problema de organizar y administrar 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, con frecuencia, entre muchos directorios . Era natural para los programadores recopilar funciones estrechamente relacionadas (comportamientos) en el mismo archivo y recopilar 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 "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 sangría mucho más consistente que, por ejemplo, Perl, porque los espacios en blanco (sangría) son realmente importantes para el intérprete. Python no utiliza la sintaxis de llaves que Perl utiliza 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 solo 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 obtener numerosos ejemplos y análisis. 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++ .