stringtranslate.com

Líneas de código fuente

Las líneas de código fuente ( SLOC ), también conocidas como líneas de código ( LOC ), son una métrica de software que se utiliza para medir el tamaño de un programa de computadora contando el número de líneas en el texto del código fuente del programa . SLOC se utiliza normalmente para predecir la cantidad de esfuerzo que se requerirá para desarrollar un programa, así como para estimar la productividad o la capacidad de mantenimiento de la programación una vez que se produce el software.

Métodos de medición

Muchas comparaciones útiles implican sólo el orden de magnitud de las líneas de código de un proyecto. Usar líneas de código para comparar un proyecto de 10.000 líneas con uno de 100.000 líneas es mucho más útil que comparar un proyecto de 20.000 líneas con uno de 21.000 líneas. Si bien es discutible cómo medir exactamente las líneas de código, las discrepancias de un orden de magnitud pueden ser indicadores claros de la complejidad del software o de las horas de trabajo .

Hay dos tipos principales de medidas SLOC: SLOC físico (LOC) y SLOC lógico (LLOC). Las definiciones específicas de estas dos medidas varían, pero la definición más común de SLOC físico es un recuento de líneas en el texto del código fuente del programa, excluyendo las líneas de comentarios. [1]

El SLOC lógico intenta medir el número de "declaraciones" ejecutables, pero sus definiciones específicas están vinculadas a lenguajes de computadora específicos (una medida SLOC lógica simple para lenguajes de programación tipo C es el número de puntos y comas que terminan en las declaraciones). Es mucho más fácil crear herramientas que midan el SLOC físico y las definiciones de SLOC físicos son más fáciles de explicar. Sin embargo, las medidas SLOC físicas son más sensibles a las convenciones de estilo y formato lógicamente irrelevantes que el SLOC lógico. Sin embargo, las medidas SLOC a menudo se establecen sin dar su definición, y el SLOC lógico a menudo puede ser significativamente diferente del SLOC físico.

Considere este fragmento de código C como un ejemplo de la ambigüedad encontrada al determinar SLOC:

para ( i = 0 ; i < 100 ; i ++ ) printf ( "hola" ); /* ¿Cuántas líneas de código es esto? */

En este ejemplo tenemos:

Dependiendo del programador y los estándares de codificación, la "línea" de código anterior podría escribirse en muchas líneas separadas:

/* Ahora ¿cuántas líneas de código son estas? */ for ( i = 0 ; i < 100 ; i ++ ) { printf ( "hola" ); }

En este ejemplo tenemos:

Incluso los valores SLOC "lógicos" y "físicos" pueden tener una gran cantidad de definiciones diferentes. Robert E. Park (mientras estaba en el Instituto de Ingeniería de Software ) y otros desarrollaron un marco para definir los valores SLOC, para permitir a las personas explicar y definir cuidadosamente la medida SLOC utilizada en un proyecto. Por ejemplo, la mayoría de los sistemas de software reutilizan el código, y determinar qué código reutilizado (si corresponde) incluir es importante al informar una medida.

Orígenes

En el momento en que se introdujo SLOC como métrica, los lenguajes más utilizados, como FORTRAN y el lenguaje ensamblador , eran lenguajes orientados a líneas. Estos lenguajes se desarrollaron en una época en la que las tarjetas perforadas eran la principal forma de entrada de datos para la programación. Una tarjeta perforada normalmente representaba una línea de código. Era un objeto discreto que se contaba fácilmente. Era el resultado visible del programador, por lo que tenía sentido para los gerentes contar líneas de código como una medida de la productividad de un programador, incluso refiriéndose a " imágenes de tarjetas ". Hoy en día, los lenguajes informáticos más utilizados permiten mucho más margen de maniobra para formatear. Las líneas de texto ya no están limitadas a 80 o 96 columnas, y una línea de texto ya no corresponde necesariamente a una línea de código.

Uso de medidas SLOC

Las medidas SLOC son algo controvertidas, particularmente por la forma en que a veces se utilizan incorrectamente. Los experimentos han confirmado repetidamente que el esfuerzo está altamente correlacionado con SLOC [ cita necesaria ] , es decir, los programas con valores SLOC más grandes tardan más en desarrollarse. Por tanto, SLOC puede ser eficaz para estimar el esfuerzo. Sin embargo, la funcionalidad está menos correlacionada con SLOC: los desarrolladores expertos pueden desarrollar la misma funcionalidad con mucho menos código, por lo que un programa con menos SLOC puede exhibir más funcionalidad que otro programa similar. Contar SLOC como medida de productividad tiene sus desventajas, ya que un desarrollador puede desarrollar sólo unas pocas líneas y aún así ser mucho más productivo en términos de funcionalidad que un desarrollador que termina creando más líneas (y generalmente dedicando más esfuerzo). Los buenos desarrolladores pueden fusionar varios módulos de código en un solo módulo, mejorando el sistema pero pareciendo tener una productividad negativa porque eliminan código. Además, los desarrolladores sin experiencia suelen recurrir a la duplicación de código , lo cual no se recomienda porque es más propenso a errores y costoso de mantener, pero da como resultado un SLOC más alto.

El recuento de SLOC presenta más problemas de precisión al comparar programas escritos en diferentes idiomas, a menos que se apliquen factores de ajuste para normalizar los idiomas. Varios lenguajes informáticos equilibran la brevedad y la claridad de diferentes maneras; Como ejemplo extremo, la mayoría de los lenguajes ensambladores requerirían cientos de líneas de código para realizar la misma tarea que unos pocos caracteres en APL . El siguiente ejemplo muestra una comparación de un programa "hola mundo" escrito en BASIC , C y COBOL (un lenguaje conocido por ser particularmente detallado).

Otro problema cada vez más común al comparar métricas SLOC es la diferencia entre código generado automáticamente y escrito a mano. Las herramientas de software modernas suelen tener la capacidad de generar automáticamente enormes cantidades de código con unos pocos clics del mouse. Por ejemplo, los creadores de interfaces gráficas de usuario generan automáticamente todo el código fuente para los elementos de control gráfico simplemente arrastrando un icono a un espacio de trabajo. El trabajo involucrado en la creación de este código no puede compararse razonablemente con el trabajo necesario para escribir un controlador de dispositivo, por ejemplo. Del mismo modo, una clase de GUI personalizada codificada a mano fácilmente podría ser más exigente que un simple controlador de dispositivo; de ahí la deficiencia de esta métrica.

Existen varios modelos de estimación de costos, cronograma y esfuerzo que utilizan SLOC como parámetro de entrada, incluida la serie de modelos ampliamente utilizada Modelo de costos constructivos ( COCOMO ) de Barry Boehm et al., PRICE Systems True S y SEER-SEM de Galorath . Si bien estos modelos han demostrado un buen poder predictivo, son tan buenos como las estimaciones (particularmente las estimaciones SLOC) que se les proporcionan. Muchos [2] han abogado por el uso de puntos de función en lugar de SLOC como medida de funcionalidad, pero dado que los puntos de función están altamente correlacionados con SLOC (y no se pueden medir automáticamente), esta no es una opinión universal.

Ejemplo

Según Vincent Maraia, [3] los valores SLOC para varios sistemas operativos en la línea de productos Windows NT de Microsoft son los siguientes:

David A. Wheeler estudió la distribución Red Hat del sistema operativo Linux e informó que la versión 7.1 [6] de Red Hat Linux (lanzada en abril de 2001) contenía más de 30 millones de SLOC físicos. También extrapoló que, si se hubiera desarrollado por medios propietarios convencionales, habría requerido alrededor de 8.000 años-persona de esfuerzo de desarrollo y habría costado más de mil millones de dólares (en dólares estadounidenses del año 2000).

Posteriormente se realizó un estudio similar de Debian GNU/Linux versión 2.2 (también conocida como "Potato"); este sistema operativo se lanzó originalmente en agosto de 2000. Este estudio encontró que Debian GNU/Linux 2.2 incluía más de 55 millones de SLOC y, si se hubiera desarrollado de forma propietaria convencional, habría requerido 14.005 años-persona y su desarrollo habría costado 1.900 millones de dólares. Ejecuciones posteriores de las herramientas utilizadas informan que la siguiente versión de Debian tenía 104 millones de SLOC y, a partir del año 2005 , la versión más reciente incluirá más de 213 millones de SLOC.

Utilidad

Ventajas

  1. Posibilidad de automatizar el conteo: dado que la línea de código es una entidad física, el esfuerzo de conteo manual se puede eliminar fácilmente automatizando el proceso de conteo. Se pueden desarrollar pequeñas utilidades para contar el LOC en un programa. Sin embargo, una utilidad de recuento de códigos lógicos desarrollada para un idioma específico no se puede utilizar para otros idiomas debido a las diferencias sintácticas y estructurales entre los idiomas. Sin embargo, se han producido contadores LOC físicos que cuentan docenas de idiomas.
  2. Una métrica intuitiva: la línea de código sirve como una métrica intuitiva para medir el tamaño del software porque se puede ver y su efecto se puede visualizar. Se dice que los puntos de función son más bien una métrica objetiva que no puede imaginarse como una entidad física, sino que sólo existe en el espacio lógico. De esta forma, LOC resulta útil para expresar el tamaño del software entre programadores con bajos niveles de experiencia.
  3. Medida ubicua: las medidas LOC han existido desde los primeros días del software. [15] Como tal, se puede argumentar que hay más datos LOC disponibles que cualquier otra medida de tamaño.

Desventajas

  1. Falta de responsabilidad: la medida de líneas de código adolece de algunos problemas fundamentales. ¿ Algunos que? ] Pienso que no es útil medir la productividad de un proyecto utilizando sólo los resultados de la fase de codificación, que normalmente representa sólo del 30% al 35% del esfuerzo total. [ cita necesaria ]
  2. Falta de cohesión con la funcionalidad: mediante experimentos [ ¿ por quién? ] han confirmado repetidamente que, si bien el esfuerzo está altamente correlacionado con LOC, la funcionalidad está menos correlacionada con LOC. Es decir, los desarrolladores expertos pueden desarrollar la misma funcionalidad con mucho menos código, por lo que un programa con menos LOC puede exhibir más funcionalidad que otro programa similar. En particular, LOC es una medida deficiente de la productividad de los individuos, porque un desarrollador que desarrolla sólo unas pocas líneas puede ser más productivo que un desarrollador que crea más líneas de código; incluso más: una buena refactorización como un "método de extracción" para deshacerse de código redundante y mantenerlo limpio reducirá principalmente las líneas de código.
  3. Impacto adverso en la estimación: debido al hecho presentado en el punto 1, las estimaciones basadas en líneas de código pueden salir mal, con toda posibilidad.
  4. Experiencia del desarrollador: la implementación de una lógica específica difiere según el nivel de experiencia del desarrollador. Por lo tanto, el número de líneas de código difiere de persona a persona. Un desarrollador experimentado puede implementar determinadas funciones en menos líneas de código que otro desarrollador con relativamente menos experiencia, aunque utilice el mismo lenguaje.
  5. Diferencia de idiomas: considere dos aplicaciones que brinden la misma funcionalidad (pantallas, informes, bases de datos). Una de las aplicaciones está escrita en C++ y la otra aplicación escrita en un lenguaje como COBOL. El número de puntos de función sería exactamente el mismo, pero los aspectos de la aplicación serían diferentes. Las líneas de código necesarias para desarrollar la aplicación seguramente no serían las mismas. Como consecuencia, la cantidad de esfuerzo requerido para desarrollar la aplicación sería diferente (horas por punto de función). A diferencia de las líneas de código, la cantidad de puntos de función permanecerá constante.
  6. Advenimiento de herramientas GUI : con la llegada de lenguajes de programación basados ​​en GUI y herramientas como Visual Basic , los programadores pueden escribir relativamente poco código y lograr altos niveles de funcionalidad. Por ejemplo, en lugar de escribir un programa para crear una ventana y dibujar un botón, un usuario con una herramienta GUI puede usar arrastrar y soltar y otras operaciones del mouse para colocar componentes en un espacio de trabajo. El código generado automáticamente por una herramienta GUI generalmente no se tiene en cuenta cuando se utilizan métodos de medición LOC. Esto da como resultado una variación entre idiomas; la misma tarea que se puede realizar en una sola línea de código (o sin ningún código) en un idioma puede requerir varias líneas de código en otro.
  7. Problemas con varios idiomas: en el escenario actual del software, el software suele desarrollarse en más de un idioma. Muy a menudo se emplean varios idiomas dependiendo de la complejidad y los requisitos. El seguimiento y la presentación de informes sobre la productividad y las tasas de defectos plantean un problema grave en este caso, ya que los defectos no pueden atribuirse a un lenguaje en particular después de la integración del sistema. El punto funcional destaca como la mejor medida de tamaño en este caso.
  8. Falta de estándares de conteo: no existe una definición estándar de qué es una línea de código. ¿Cuentan los comentarios? ¿Se incluyen declaraciones de datos? ¿Qué sucede si una declaración se extiende a lo largo de varias líneas? – Estas son las preguntas que surgen a menudo. Aunque organizaciones como SEI e IEEE han publicado algunas pautas en un intento de estandarizar el conteo, es difícil ponerlas en práctica, especialmente ante la introducción de lenguajes cada vez más nuevos cada año.
  9. Psicología: un programador cuya productividad se mide en líneas de código tendrá un incentivo para escribir código innecesariamente detallado. Cuanto más se centra la gestión en las líneas de código, más incentivo tiene el programador para ampliar su código con una complejidad innecesaria. Esto no es deseable, ya que una mayor complejidad puede generar un mayor costo de mantenimiento y un mayor esfuerzo requerido para corregir errores.

En el documental de PBS Triumph of the Nerds , el ejecutivo de Microsoft Steve Ballmer criticó el uso de contar líneas de código:

En IBM existe una religión en el software que dice que hay que contar los K-LOC, y un K-LOC son mil líneas de código. ¿Qué tan grande es el proyecto? Oh, es una especie de proyecto 10K-LOC. Este es un 20K-LOCer. Y estos son 50K-LOC. E IBM quería convertirlo en la religión sobre cómo nos pagaban. Cuánto dinero ganamos con OS/2 , cuánto ganaron ellos. ¿Cuántos K-LOC hiciste? Y seguimos tratando de convencerlos (oye, si lo hemos hecho), un desarrollador tiene una buena idea y puede hacer algo en 4K-LOC en lugar de 20K-LOC, ¿deberíamos ganar menos dinero? Porque ha creado algo más pequeño y más rápido, menos K-LOC. K-LOC, K-LOC, esa es la metodología. ¡Puaj! De todos modos, eso siempre hace que mi espalda se arrugue al pensar en todo esto.

Según el Museo de Historia de la Computación, el desarrollador de Apple, Bill Atkinson, en 1982 encontró problemas con esta práctica:

Cuando el equipo de Lisa estaba presionando para finalizar su software en 1982, los gerentes de proyecto comenzaron a exigir a los programadores que enviaran formularios semanales informando sobre la cantidad de líneas de código que habían escrito. Bill Atkinson pensó que eso era una tontería. Durante la semana en la que había reescrito las rutinas de cálculo de regiones de QuickDraw para que fueran seis veces más rápidas y 2000 líneas más cortas, puso "-2000" en el formulario. Después de unas semanas más, los gerentes dejaron de pedirle que llenara el formulario y él cumplió con gusto. [16] [17]

Ver también

Notas

  1. ^ Posiblemente incluya toda la suite iLife, no solo el sistema operativo y las aplicaciones generalmente incluidas.

Referencias

  1. ^ Vu Nguyen; Sophia Deeds-Rubin; Thomas Tan; Barry Boehm (2007), Un estándar de conteo SLOC (PDF) , Centro de Ingeniería de Software y Sistemas, Universidad del Sur de California
  2. ^ IFPUG "Cuantificación de los beneficios del uso de puntos de función"
  3. ^ abcdef "¿Cuántas líneas de código hay en Windows?". Conociendo.NET. 6 de diciembre de 2005 . Consultado el 30 de agosto de 2010 .
    Éste, a su vez, cita The Build Master de Vincent Maraia como fuente de información.
  4. ^ "¿Cuántas líneas de código hay en Windows XP?". Microsoft. 11 de enero de 2011. Archivado desde el original el 26 de febrero de 2022.
  5. ^ "Una historia de Windows: Microsoft Windows". 2012-09-21. Archivado desde el original el 21 de septiembre de 2012 . Consultado el 26 de marzo de 2021 .
  6. ^ ab David A. Wheeler (30 de junio de 2001). "Más que un gigabuck: estimación del tamaño de GNU/Linux".
  7. ^ González-Barahona, Jesús M.; Miguel A. Ortuño Pérez; Pedro de las Heras Quirós; José Centeno González; Vicente Matellán Olivera. "Contando patatas: el tamaño de Debian 2.2". debian.org . Archivado desde el original el 3 de mayo de 2008 . Consultado el 12 de agosto de 2003 .
  8. ^ abcde Robles, Gregorio. "Conteo de Debian". Archivado desde el original el 14 de marzo de 2013 . Consultado el 16 de febrero de 2007 .
  9. ^ Debian 7.0 se lanzó en mayo de 2013. El número es una estimación publicada el 13 de febrero de 2012, utilizando el código base que se convertiría en Debian 7.0, utilizando el mismo método de software que para los datos publicados por David A. Wheeler. James Bromberger. "Debian Wheezy: 19 mil millones de dólares. Su precio... ¡GRATIS!". Archivado desde el original el 23 de febrero de 2014 . Consultado el 7 de febrero de 2014 .
  10. ^ Empleos, Steve (agosto de 2006). "En vivo desde la WWDC 2006: discurso de apertura de Steve Jobs" . Consultado el 16 de febrero de 2007 . 86 millones de líneas de código fuente que se adaptaron para ejecutarse en una arquitectura completamente nueva sin contratiempos.
  11. ^ Thorsten Leemhuis (3 de diciembre de 2009). "Novedades de Linux 2.6.32". Archivado desde el original el 19 de diciembre de 2013 . Consultado el 24 de diciembre de 2009 .
  12. ^ Greg Kroah-Hartman; Jonatán Corbet; Amanda McPherson (abril de 2012). "Desarrollo del kernel de Linux: qué tan rápido va, quién lo hace, qué están haciendo y quién lo patrocina". La Fundación Linux . Consultado el 10 de abril de 2012 .
  13. ^ Thorsten Leemhuis (1 de octubre de 2012). "Resumen, perspectivas, estadísticas: The H Open: noticias y características". Archivado desde el original el 19 de diciembre de 2013.
  14. ^ "Linux-Kernel durchbricht die 20-Millionen-Zeilen-Marke".
  15. ^ IFPUG "una breve historia de las métricas de líneas de código (loc)"
  16. ^ "Código fuente de MacPaint y QuickDraw". CHM . 2010-07-18 . Consultado el 15 de abril de 2021 .
  17. ^ "Folklore.org: -2000 líneas de código". www.folklore.org . Consultado el 15 de abril de 2021 .

Otras lecturas

enlaces externos