Convenciones de programación

De Wikipedia, la enciclopedia libre

Convenciones de programación son un conjunto de directrices para un lenguaje de programación concreto que recomienda estilo, prácticas, y métodos de programación para cada aspecto de un programa escrito en cada lenguaje. Estas convenciones normalmente comprenden gestión de archivos, sangría, comentarios, declaraciones, sentencias, espaciado, convenciones de nombres, buenas prácticas de programación, principios de programación, buenas prácticas de arquitectura, etc. Estas son directrices para la calidad estructural del software. Se recomienda encarecidamente a los programadores de software seguir estas directrices para ayudar a mejorar la legibilidad de su código de fuente y un fácil mantenimiento del software. Las convenciones de programación son solo aplicables a maintenedores humanos y revisores por pares de un proyecto de software. Las convenciones pueden ser formalizadas en un conjunto documentado de reglas que un equipo entero o toda la compañía pueden seguir, o puede ser tan informal como las prácticas habituales de programación de un individuo.[1]​ Las convenciones de programación no son aplicadas por los compiladores.

Mantenimiento de software[editar]

Reducir el coste de mantenimiento de software es la razón citada más a menudo para seguir las convenciones de programación. En su introducción a convenciones de código para el lenguaje de programación Java , Sol Microsystems proporciona el siguiente razonamiento:[2]​

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

  • 40–80% del coste de tiempo de una trozo de código va a mantenimiento.[3]​
  • Difícilmente algún software es mantenido por su autor original durante su vida entera .
  • Las convenciones de código mejoran la legibilidad del software, permitiendo a los ingenieros entender código nuevo más deprisa y exhaustivamente.
  • Si empaquetas el código fuente como producto, necesitas estar seguro de que está bien empaquetado y limpio como cualquier otro producto que hayas creado.

Calidad[editar]

La revisión de software por pares frecuentemente implica leer el código fuente. Este tipo de revisión por pares es principalmente una actividad de detección de errores de software. Por definición, solo el autor original de una pieza de código ha leído el archivo fuente antes de que el código sea entregado para revisión. El código que está escrito utilizando las directrices compatibles es más fácil de entender y asimilar para otro revisor, mejorando la eficacia del proceso de detección de errores.

Incluso para el autor original, software programado coherentemente facilita su mantenibilidad. No hay ninguna garantía de que un desarrollador recordará el razonamiento preciso por el que un trozo particular de código fue escrito de una cierta manera mucho tiempo después de que el código fuera originalmente escrito. Las convenciones de programación pueden ayudar. El uso consistente de los espacios en blanco mejora la legibilidad y reduce el tiempo que se necesita para entender el software.

Estándares de programación[editar]

Dónde las convenciones de programación han sido específicamente diseñadas para producir alta calidad de código, y ha sido formalmente adoptado, se han convertido entonces en estándares de programación. Los estilos concretos, independientemente de si son generalmente adoptados, no producen automáticamente código de buena calidad.

Reducción de complejidad[editar]

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

La administración de la complejidad incluye el siguiente principio básico: minimizar la cantidad de código escrito durante el desarrollo de proyecto. Esto previene el trabajo innecesario, lo cual previene el coste innecesario, funcionando en ambos sentidos.

La complejidad se gestiona en la etapa de diseño (cómo se organiza la arquitectura del proyecto) y en la etapa de desarrollo (qué programación se utiliza). Si el códido se mantiene de forma básica y sencilla entonces la complejidad será minimizada. Muy a menudo esto consiste en mantener el código tan 'físico' como sea posible (programar de una manera muy directa y con una abstracción baja). Esto produce código óptimo que es fácil de leer y seguir.

Cuanto más complejo sea el código más probable será que sea defectuoso, más difíciles de encontrar serán los errores y más probablemente habrá errores ocultos.

Refactoring[editar]

Refactoring se refiere a una actividad de mantenimiento del software donde el código de fuente es modificado para mejorar su legibilidad o su estructura. El software es a menudo reorganizado para alinearlo con los estándares de codificación que un equipo ha declarado después de su liberación inicial. Cualquier cambio que no altera el comportamiento del software puede ser considerado refactoring. Unas actividades comunes de refactoring consisten en cambiar los nombres de las variables, renombrar métodos, mover métodos o clases enteras y dividir métodos grandes (o funciones) en unos más pequeños.

Las metodologías de desarrollo de software ágiles planean hacer refactoring de manera regular (o incluso continua) haciéndolo una parte integral del proceso de desarrollo de software en equipo.[5]​

Automatización de tareas[editar]

Las convenciones de programación permiten tener programas o scripts sencillos cuyo trabajo es procesar el código fuente para propósitos diferentes que compilar para crear un ejecutable. Es una práctica común contar el tamaño del software (líneas de código fuente) para seguir el progreso del proyecto actual o establecer una base para estimaciones futuras del proyecto.

Los estándares consistentes de programación pueden conseguir las medidas más consistentes. Las etiquetas especiales dentro comentarios de código fuente son a menudo utilizadas para procesar 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 programación simplifican escribir software nuevo cuyo trabajo es procesar software existente. El uso de análisis de código estático ha crecido coherentemente desde los años cincuenta. Algo del crecimiento de esta clase de herramientas de desarrollo proviene del aumento de la sofisticación y madurez de los propios desarrolladores (y la moda de poner el foco en prevención y seguridad), pero también de la naturaleza de los propios lenguajes.

Factores de lenguaje[editar]

Todos los desarrolladores de software tienen que enfrentarse con el problema de organizar y dirigir en ocasiones de un gran número de instrucciones 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. De manera natural para programadores se concentran funciones estrechamente relacionadas (comportamientos) en el mismo archivo y se agrupan archivos relacionados en directorios. Como el desarrollo de software evolucionó desde lo programación por procedimientos (como FORTRAN) hacia una programación más orientada a objetos (como C++), se convirtió en práctica habitual escribir el código para una sola clase (pública) en un único archivo (la convención una clase por archivo).[6]​[7]​ Java ha ido un paso más allá: el compilador 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 archivos fuente individuales. Cada compilador (o intérprete) utilizado para procesar código de fuente es único. Las reglas que un compilador aplica al código fuente crean estándares implícitos. Por ejemplo, el código Python está mucho más coherentemente indentado que, digamos el de Perl, porque los espacios en blanco (sangría) es de hecho algo significativo para el intérprete. Python no utiliza la sintaxis con llaves que Perl utiliza para delimitar funciones. Ya que en Python, los cambios en la sangría sirven como los delimitadores.[8]​[9]​ Tcl, el cual utiliza una sintaxis de llaves similar a Perl o C/C++ para delimitar funciones, no permite lo siguiente, lo cual parece bastante razonable para un programador de C:

 set i = 0
 while {$i < 10} 
 {
    puts "$i squared = [expr $i*$i]"
    incr i
 }

La razón es que en Tcl, las llaves no son utilizadas solo para delimitar funciones como en C o Java. Más generalmente, las llaves se suelen usar 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 de encima, a while le falta su segundo argumento, su acción (porque Tcl también utiliza el carácter de nueva línea para delimitar el fin de una orden).

Convenciones comunes[editar]

Hay un número grande de convenciones de programación; ve Coding Style para más información y numerosos ejemplos. Las convenciones de programación común pueden cubrir las áreas siguientes:

Estándares de codificación incluyen el CERT C Coding Standard, MISRA C o el High Integrity C++.

Véase también[editar]

Referencias[editar]

  1. ↑ «EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs.». EditorConfig. 
  2. ↑ «Code Conventions for the Java Programming Language : Why Have Code Conventions». Sun Microsystems, Inc. 20 de abril de 1999. 
  3. ↑ Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.
  4. ↑ Tom Gillis. "Complexity is the enemy of security" Archivado el 2 de febrero de 2019 en Wayback Machine..
  5. ↑ Jeffries, Ron (8 de noviembre de 2001). «What is Extreme Programming? : Design Improvement». XP Magazine. Archivado desde el original el 15 de diciembre de 2006. 
  6. ↑ Hoff, Todd (9 de enero de 2007). «C++ Coding Standard : Naming Class Files». 
  7. ↑ FIFE coding standards
  8. ↑ van Rossum, Guido (19 de septiembre de 2006). Fred L. Drake, Jr, ed. «Python Tutorial : First Steps Towards Programming». Python Software Foundation. Archivado desde el original el 28 de septiembre de 2008. Consultado el 17 de agosto de 2014. 
  9. ↑ Raymond, Eric (1 de mayo de 2000). «Why Python?». Linux Journal. 
  10. ↑ Tcl Developer Xchange. «Summary of Tcl language syntax». ActiveState. 
  11. ↑ Staplin, George Peter (16 de julio de 2006). «Why can I not start a new line before a brace group». 'the Tcler's Wiki'. 

Enlaces externos[editar]

Convenciones de programación para lenguajes[editar]

Obtenido de «https://es.wikipedia.org/w/index.php?title=Convenciones_de_programación&oldid=160417564»