stringtranslate.com

Líneas fuente de código

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 informático contando la cantidad 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 involucran únicamente el orden de magnitud de las líneas de código en un proyecto. Usar líneas de código para comparar un proyecto de 10 000 líneas con un proyecto 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-hombre .

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

El SLOC lógico intenta medir la cantidad de "declaraciones" ejecutables, pero sus definiciones específicas están ligadas a lenguajes informáticos específicos (una medida simple del SLOC lógico para lenguajes de programación tipo C es la cantidad de puntos y comas que terminan las declaraciones). Es mucho más fácil crear herramientas que midan el SLOC físico, y las definiciones del SLOC físico son más fáciles de explicar. Sin embargo, las medidas del SLOC físico son más sensibles a las convenciones de formato y estilo lógicamente irrelevantes que el SLOC lógico. Sin embargo, las medidas del SLOC a menudo se indican 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:

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

En este ejemplo tenemos:

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

/* ¿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 trabajaba en el Instituto de Ingeniería de Software ) y otros desarrollaron un marco para definir los valores SLOC, con el fin de permitir que las personas expliquen y definan cuidadosamente la medida SLOC utilizada en un proyecto. Por ejemplo, la mayoría de los sistemas de software reutilizan código, y determinar qué código reutilizado (si es que hay alguno) incluir es importante al informar una medida.

Orígenes

En la época 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 la época en que las tarjetas perforadas eran la principal forma de entrada de datos para la programación. Una tarjeta perforada representaba normalmente 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 directivos contar líneas de código como una medida de la productividad de un programador, incluso haciendo referencia a " imágenes de tarjetas ". Hoy en día, los lenguajes informáticos más utilizados permiten mucho más margen de maniobra para el formato. Las líneas de texto ya no se limitan 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 en la forma en que a veces se las usa mal. Los experimentos han confirmado repetidamente que el esfuerzo está altamente correlacionado con SLOC [ cita requerida ] , es decir, los programas con valores SLOC más altos toman más tiempo para desarrollarse. Por lo tanto, SLOC puede ser eficaz para estimar el esfuerzo. Sin embargo, la funcionalidad está menos correlacionada con SLOC: los desarrolladores expertos pueden ser capaces de 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 salvedades, ya que un desarrollador puede desarrollar solo unas pocas líneas y, sin embargo, 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 múltiples 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 inexpertos a menudo recurren a la duplicación de código , lo cual es altamente desaconsejado ya que es más propenso a errores y costoso de mantener, pero da como resultado un SLOC más alto.

El conteo SLOC presenta problemas de precisión adicionales al comparar programas escritos en diferentes lenguajes, a menos que se apliquen factores de ajuste para normalizar los lenguajes. Varios lenguajes de programación equilibran la brevedad y la claridad de diferentes maneras; como un 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 verboso).

Otro problema cada vez más común al comparar las métricas SLOC es la diferencia entre el código generado automáticamente y el código 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 ratón. Por ejemplo, los creadores de interfaces gráficas de usuario generan automáticamente todo el código fuente de los elementos de control gráfico simplemente arrastrando un icono a un espacio de trabajo. El trabajo que implica crear este código no se puede comparar razonablemente con el trabajo necesario para escribir un controlador de dispositivo, por ejemplo. Del mismo modo, una clase de GUI personalizada codificada a mano podría ser fácilmente 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, cronogramas y esfuerzos que utilizan SLOC como parámetro de entrada, incluyendo la serie de modelos ampliamente utilizados Constructive Cost Model ( 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, solo son tan buenos como las estimaciones (en particular, las estimaciones SLOC) que se les suministran. Muchos [2] han defendido el uso de puntos de función en lugar de SLOC como una 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 de 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 de Red Hat Linux [6] (publicada 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 la versión 2.2 de Debian GNU/Linux (también conocida como "Potato"); este sistema operativo se lanzó originalmente en agosto de 2000. Este estudio descubrió que Debian GNU/Linux 2.2 incluía más de 55 millones de SLOC y que, si se hubiera desarrollado de forma privativa convencional, habría requerido 14.005 años-persona y habría costado 1.900 millones de dólares estadounidenses. 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 nueva incluirá más de 213 millones de SLOC.

Utilidad

Ventajas

  1. Alcance de la automatización del 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 conteo de código lógico desarrollada para un lenguaje específico no se puede utilizar para otros lenguajes debido a las diferencias sintácticas y estructurales entre los lenguajes. Sin embargo, se han producido contadores LOC físicos que cuentan docenas de lenguajes.
  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 una métrica más objetiva que no se puede imaginar como una entidad física, solo existe en el espacio lógico. De esta manera, 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 rendición de cuentas: la medición de líneas de código adolece de algunos problemas fundamentales. Algunos [¿ quiénes? ] piensan que no es útil medir la productividad de un proyecto utilizando únicamente los resultados de la fase de codificación, que normalmente representa solo entre el 30% y el 35% del esfuerzo total. [ cita requerida ]
  2. Falta de cohesión con la funcionalidad: aunque los experimentos [¿ de quién? ] han confirmado repetidamente que, si bien el esfuerzo está altamente correlacionado con el LOC, la funcionalidad está menos correlacionada con el LOC. Es decir, los desarrolladores expertos pueden ser capaces de 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, el LOC es una mala medida de la productividad de los individuos, porque un desarrollador que desarrolla solo unas pocas líneas puede ser aún más productivo que un desarrollador que crea más líneas de código; incluso más: una buena refactorización como "extraer método" para deshacerse del código redundante y mantenerlo limpio reducirá en gran medida 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 resultar negativamente erróneas, con toda probabilidad.
  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, la cantidad de líneas de código varía de una persona a otra. Un desarrollador experimentado puede implementar cierta funcionalidad en menos líneas de código que otro desarrollador con relativamente menos experiencia, aunque utilicen el mismo lenguaje.
  5. Diferencias en lenguajes: considere dos aplicaciones que proporcionan la misma funcionalidad (pantallas, informes, bases de datos). Una de las aplicaciones está escrita en C++ y la otra 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 ciertamente no serían las mismas. Como consecuencia, la cantidad de esfuerzo necesario para desarrollar la aplicación sería diferente (horas por punto de función). A diferencia de las líneas de código, el número de puntos de función permanecerá constante.
  6. Advenimiento de las herramientas GUI : con el advenimiento de los lenguajes de programación basados ​​en GUI y las 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 que se genera automáticamente mediante una herramienta GUI generalmente no se toma en consideración cuando se utilizan métodos LOC de medición. Esto da como resultado variaciones entre lenguajes; la misma tarea que se puede realizar en una sola línea de código (o sin código en absoluto) en un lenguaje puede requerir varias líneas de código en otro.
  7. Problemas con varios lenguajes: en el escenario actual del software, el software suele desarrollarse en más de un lenguaje. Muy a menudo, se utilizan varios lenguajes según la complejidad y los requisitos. El seguimiento y la generación de informes sobre la productividad y las tasas de defectos plantean un problema grave en este caso, ya que los defectos no se pueden atribuir a un lenguaje en particular después de la integración del sistema. El punto de función se 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 lo que es una línea de código. ¿Cuentan los comentarios? ¿Se incluyen las 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 extenso. Cuanto más se centre la dirección en las líneas de código, más incentivo tendrá el programador para ampliar su código con una complejidad innecesaria. Esto es indeseable, ya que una mayor complejidad puede generar un mayor coste de mantenimiento y un mayor esfuerzo necesario para corregir errores.

En el documental de PBS El triunfo de los nerds , el ejecutivo de Microsoft Steve Ballmer criticó el uso del conteo de líneas de código:

En IBM hay 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 un proyecto de 10K-LOC. Este es un proyecto de 20K-LOC. Y este es de 50K-LOC. E IBM quería convertirlo en una religión sobre cómo nos pagaban. Cuánto dinero ganamos con OS/2 , cuánto hicieron ellos. ¿Cuántos K-LOC hicieron? Y seguimos tratando de convencerlos: oye, si tenemos... 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 hecho algo más pequeño y más rápido, menos K-LOC. K-LOC, K-LOC, esa es la metodología. ¡Uf! De todos modos, eso siempre me pone los pelos de punta al pensar en todo el asunto.

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 trabajando 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. Para 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 pocas semanas más, los gerentes dejaron de pedirle que completara el formulario y él cumplió con gusto. [16] [17]

Véase también

Notas

  1. ^ Posiblemente incluya toda la suite iLife, no sólo el sistema operativo y las aplicaciones normalmente 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 Sistemas y Software, 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?". Knowing.NET. 6 de diciembre de 2005. Consultado el 30 de agosto de 2010 .
    Esto a su vez cita a The Build Master de Vincent Maraia como la fuente de la 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". 21 de septiembre de 2012. Archivado desde el original el 21 de septiembre de 2012. Consultado el 26 de marzo de 2021 .
  6. ^ por David A. Wheeler (30 de junio de 2001). "Más de un gigabuck: Estimando el 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. «Debian Counting». Archivado desde el original el 14 de marzo de 2013. Consultado el 16 de febrero de 2007 .
  9. ^ Debian 7.0 fue lanzado en mayo de 2013. La cifra 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: US$19 mil millones. Su precio... ¡GRATIS!". Archivado desde el original el 23 de febrero de 2014. Consultado el 7 de febrero de 2014 .
  10. ^ Jobs, Steve (agosto de 2006). "En directo desde la WWDC 2006: discurso inaugural de Steve Jobs" . Consultado el 16 de febrero de 2007. 86 millones de líneas de código fuente que se adaptaron para funcionar en una arquitectura completamente nueva sin problemas.
  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; Jonathan Corbet; Amanda McPherson (abril de 2012). "Desarrollo del núcleo de Linux: qué tan rápido avanza, quién lo está haciendo, qué están haciendo y quién lo patrocina". The Linux Foundation . Consultado el 10 de abril de 2012 .
  13. ^ Thorsten Leemhuis (1 de octubre de 2012). "Resumen, perspectivas y estadísticas: The H Open: noticias y artículos". Archivado desde el original el 19 de diciembre de 2013.
  14. ^ "Linux-Kernel durchbricht die 20-Millionen-Zeilen-Marke". 30 de junio de 2015.
  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 2021-04-15 .
  17. ^ "Folklore.org: -2000 líneas de código". www.folklore.org . Consultado el 15 de abril de 2021 .

Lectura adicional

Enlaces externos