Las convenciones de codificación son un conjunto de pautas 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 cubrir la organización de archivos, la sangría , comentarios , declaraciones , declaraciones , espacio en blanco , las convenciones de nomenclatura , prácticas de programación , la programación de los principios , la programación de reglas generales , las mejores prácticas arquitectónicas, etc Estas son las directrices para la calidad estructural de software . Programadores de softwareSe recomienda encarecidamente seguir 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 encargados del mantenimiento y a los revisores 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 habituales de codificación de un individuo. Los compiladores no hacen cumplir las convenciones de codificación .
Mantenimiento del software
Reducir el costo del mantenimiento del software es la razón más citada para seguir las convenciones de codificación. En su introducción a las convenciones de código para el lenguaje de programación Java, Sun Microsystems proporciona el siguiente fundamento: [2]
Las convenciones de código son importantes para los programadores por varias razones:
- Entre el 40% y el 80% del costo de por vida de una pieza de software se destina al 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 completa.
- Si envía su código fuente como un producto, debe asegurarse de que esté tan bien empaquetado y limpio como cualquier otro producto que cree.
Calidad
La revisión por pares del software con frecuencia 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 que está 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 que un fragmento de código en particular se escribió de cierta manera mucho después de que el código se escribió 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.
Estándares de codificación
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 un código de buena calidad.
Reducción de 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 el trabajo innecesario, lo que evita costos innecesarios, tanto al inicio como al final. Esto es simplemente porque 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 etapa de diseño (cómo se diseña 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, la complejidad se minimizará. Muy a menudo, se trata de mantener la codificación lo más "física" posible, 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 al no utilizar herramientas complicadas para trabajos simples.
Cuanto más complejo es el código, más probable es que tenga errores, más difíciles de encontrar y más probable 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 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 los nombres de las variables, cambiar el nombre de los métodos, mover métodos o clases enteras y dividir métodos grandes (o funciones ) en más pequeños.
Las metodologías de desarrollo de software ágiles 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 simples cuyo trabajo es procesar el 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 rastrear el progreso actual del proyecto o establecer una línea de base para 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 . 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 deriva de una mayor madurez y sofisticación de los mismos (y el enfoque moderno a los practicantes de la seguridad y la seguridad ), sino también de la naturaleza de las propias lenguas.
Factores del idioma
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 particiona en archivos separados y, con frecuencia, 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 la 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, por ejemplo, Perl, porque los espacios en blanco (sangría) son realmente importantes para el intérprete. Python no usa la sintaxis de llaves que usa Perl para delimitar funciones. Los cambios en la sangría 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:
establece i = 0 mientras que { $ i < 10 } { pone "$ i al cuadrado = [expr $ i * $ i]" incr 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 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, mientras falta su segundo argumento, su acción (porque el Tcl también usa el carácter de nueva línea para delimitar el final de un comando).
Convenciones comunes
Existe una gran cantidad de convenciones de codificación; consulte Estilo de codificación para ver numerosos ejemplos y discusión. Las convenciones de codificación comunes pueden cubrir las siguientes áreas:
- Convenciones de comentarios
- Convenciones de estilo de sangría
- Convenciones de longitud de línea
- Convenciones de nomenclatura
- Prácticas de programación
- Principios de programación
- Convenciones de estilo de programación
Los estándares de codificación incluyen el estándar de codificación CERT C , MISRA C , High Integrity C ++ , consulte la lista a continuación.
Ver también
- Comparación de lenguajes de programación (sintaxis)
- Notación húngara
- Estilo de sangría
- Lista de herramientas para el análisis de código estático
- Lista de filosofías de desarrollo de software
- MISRA
- Estilo de programación
- Métricas de software
- Calidad del software
- El poder de las 10 reglas
Referencias
- ^ "EditorConfig ayuda a los desarrolladores a definir y mantener estilos de codificación consistentes entre diferentes editores e IDE" . EditorConfig .
- ^ "Convenciones de código para el lenguaje de programación Java: por qué tener convenciones de código" . Sun Microsystems, Inc. 20 de abril de 1999.
- ^ Robert L. Glass: Hechos y falacias de la ingeniería de software; Addison Wesley, 2003.
- ^ Tom Gillis. "La complejidad es enemiga de la seguridad" .
- ^ Jeffries, Ron (8 de noviembre de 2001). "¿Qué es la programación extrema?: Mejora del diseño" . Revista XP. Archivado desde el original el 15 de diciembre de 2006.
- ^ Hoff, Todd (9 de enero de 2007). "Estándar de codificación C ++: nombres de archivos de clase" .
- ^ Estándares de codificación FIFE
- ^ van Rossum, Guido (19 de septiembre de 2006). Fred L. Drake, Jr. (ed.). "Tutorial de Python: primeros pasos hacia la programación" . Fundación de software Python. Archivado desde el original el 28 de septiembre de 2008 . Consultado el 17 de agosto de 2014 .
- ^ Raymond, Eric (1 de mayo de 2000). "¿Por qué Python?" . Diario de Linux.
- ^ Tcl Developer Xchange. "Resumen de la sintaxis del lenguaje Tcl" . ActiveState.
- ^ Staplin, George Peter (16 de julio de 2006). "¿Por qué no puedo comenzar una nueva línea antes de un grupo de llaves" . 'Wiki de Tcler'.
Lista de estándares de codificación
Convenciones de codificación para idiomas
- ActionScript: prácticas recomendadas y convenciones de codificación de Flex SDK
- Ada: Guía de estilo y calidad de Ada 95: directrices para programadores profesionales
- Ada: Guía para el uso del lenguaje de programación Ada en sistemas de alta integridad (ISO / IEC TR 15942: 2000)
- Ada: Rama de software de vuelo de la NASA - Estándar de codificación Ada
- Ada: Estándar de codificación Ada de la ESA - BSSC (98) 3 Edición 1 de octubre de 1998
- Ada: ingeniería y estandarización de software de la Agencia Espacial Europea
- C: Estándar de codificación CERT C Estándar de codificación CERT C (SEI)
- C: Estándar de codificación C integrado (Grupo Barr)
- C: Estándar de desarrollo de firmware (Jack Ganssle)
- C: MISRA C
- C: Estándar TIOBE C [1]
- C ++: Directrices básicas de C ++ ( Bjarne Stroustrup , Herb Sutter )
- C ++: Estándar de codificación Quantum Leaps C / C ++
- C ++: Programación C ++ / Lenguajes de programación / C ++ / Código / Convenciones de estilo
- C ++: Pautas de estilo de programación C ++ de GeoSoft
- C ++: Guía de estilo de C ++ de Google
- C ++: C ++ de alta integridad
- C ++: MISRA C ++
- C ++: Estándar de codificación C ++ de Philips Healthcare [2]
- C / C ++: Directrices de codificación C / C ++ de devolo
- C #: Convenciones de codificación de C # (Guía de programación de C #)
- C #: Pautas de diseño para desarrollar bibliotecas de clases
- C #: Brad Abrams
- C #: Philips Healthcare o estándar de codificación C # de Philips Healthcare [3]
- D: El estilo D
- Dart: la guía de estilo de Dart
- Erlang: reglas y convenciones de programación de Erlang
- Flex: convenciones de código para Flex SDK
- Java: Estándares de codificación de Ambysoft para Java
- Java: convenciones de código para el lenguaje de programación Java (no se mantiene activamente. Última versión: 1999-APR-20.)
- Java: Pautas de estilo de programación Java de GeoSoft
- Java: Estándares de codificación Java en Curlie
- Java: TIOBE Java Standard [4]
- Java: convenciones de codificación de SoftwareMonkey para Java y otros lenguajes de sintaxis de llaves
- JavaScript: convenciones de código para el lenguaje de programación JavaScript
- Lisp: Reglas de estilo Lisp de Riastradh
- MATLAB: Convenciones de codificación de Neurobat para MATLAB
- Object Pascal: Guía de estilo de Object Pascal
- Perl: Guía de estilo de Perl
- PHP :: PEAR: PHP :: Estándares de codificación PEAR
- PHP :: FIG: Grupo de interoperabilidad de framework PHP
- PL / I: Guía de estilo PL / I
- Python: guía de estilo para código Python
- Ruby: la guía de uso no oficial de Ruby
- Ruby: guía de estilo de Ruby de GitHub
- Shell: Guía de estilo de Shell de Google
Convenciones de codificación para proyectos
- Guía de estilo del lenguaje C para desarrolladores de Apache
- Estándares de codificación PHP de Drupal
- Estándares de codificación GNU
- "Estilo de codificación GNAT: una guía para desarrolladores GNAT" . Documentación en línea de GCC . Fundación de Software Libre . Consultado el 19 de enero de 2009 .( PDF )
- Estilo de codificación del kernel de Linux (o Documentation / CodingStyle en el árbol de fuentes del kernel de Linux)
- Guía de estilo de codificación de Mozilla
- Mono: estilo de programación para mono
- Guía de estilo del archivo fuente del kernel de OpenBSD (KNF)
- Directrices C ++ de Road Intranet
- Guías de estilo para proyectos de código abierto originados por Google
- La guía de estilo del código fuente de NetBSD (anteriormente conocida como BSD Kernel Normal Form)
- Estándares de codificación Zend Framework
- Estilo de lenguaje ZeroMQ C para escalabilidad (CLASS)
- ^ "Estándar de codificación TIOBE - C" . tics.tiobe.com . Consultado el 11 de marzo de 2021 .
- ^ "Estándar de codificación C ++" . tics.tiobe.com . Consultado el 11 de marzo de 2021 .
- ^ "Estándar de codificación C #" . tics.tiobe.com . Consultado el 11 de marzo de 2021 .
- ^ "TIOBE - Estándar de codificación Java" . tics.tiobe.com . Consultado el 11 de marzo de 2021 .