Hispanopedia Wiki
Articulo de referencia

Líneas de código fuente

Las líneas de código fuente ( SLOC , por sus siglas en inglés), también conocidas como líneas de código ( LOC , por sus siglas en inglés ), son una métrica de software que se ut...

Hispanopedia WikiContenido en espanolLectura gratuita

Las líneas de código fuente ( SLOC , por sus siglas en inglés), también conocidas como líneas de código ( LOC , por sus siglas en inglés ), son una métrica de software que se utiliza para medir el tamaño de un programa informático contando el número de líneas en el texto de su código fuente . Las SLOC se utilizan normalmente para predecir el esfuerzo necesario para desarrollar un programa, así como para estimar la productividad de la programación o la mantenibilidad una vez que el software esté producido.

Métodos de medición

Las comparaciones más útiles se basan únicamente en el orden de magnitud de las líneas de código de un proyecto. Comparar un proyecto de 10 000 líneas con uno de 100 000 es mucho más útil que comparar uno de 20 000 con uno de 21 000. 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 .

Existen dos tipos principales de medidas de 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 el recuento de líneas en el texto del código fuente del programa, excluyendo las líneas de comentarios. [ 1 ]

La medición lógica de líneas de código (SLOC) intenta cuantificar el número de "instrucciones" ejecutables, pero sus definiciones específicas están ligadas a lenguajes de programación concretos (una medida sencilla para lenguajes como C es el número de puntos y coma al final de las instrucciones). Es mucho más fácil crear herramientas que midan las SLOC físicas, y sus definiciones son más fáciles de explicar. Sin embargo, las mediciones de SLOC físicas son más sensibles a las convenciones de formato y estilo que no son lógicamente relevantes que las SLOC lógicas. Además, las mediciones de SLOC suelen presentarse sin su definición, y las SLOC lógicas a menudo difieren significativamente de las físicas.

Considere este fragmento de código C como ejemplo de la ambigüedad que se presenta al determinar las líneas de código fuente (SLOC):

for ( int i = 0 ; i < 100 ; i ++ ) printf ( "hola" ); /* mostrar cien saludos */

En este ejemplo tenemos:

  • 1 línea física de código (LOC),
  • 2 líneas lógicas de código (LLOC) ( instrucción for e instrucción printf ),
  • 1 línea de comentario.

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

/* mostrar cien saludos */ for ( int i = 0 ; i < 100 ; i ++ ) { printf ( "hola" ); }

En este ejemplo tenemos:

  • 4 líneas físicas de código (LOC): ¿es necesario estimar el trabajo que implica colocar llaves?
  • 2 líneas lógicas de código (LLOC): ¿qué pasa con todo el trabajo que implica escribir líneas que no son sentencias?
  • 1 línea de comentario: las herramientas deben tener en cuenta todo el código y los comentarios, independientemente de la ubicación de los comentarios.

Incluso los valores SLOC "lógicos" y "físicos" pueden tener numerosas definiciones diferentes. Robert E. Park (durante su etapa en el Software Engineering Institute ) y otros desarrollaron un marco para definir los valores SLOC, con el fin de facilitar la explicación y definición precisas de 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 corresponde) incluir es fundamental al informar sobre una medida.

Orígenes

Cuando 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 generalmente representaba una línea de código. Era un objeto discreto que se podía contar fácilmente. Era la salida visible del programador, por lo que tenía sentido para los gerentes contar las líneas de código como medida de la productividad de un programador, incluso refiriéndose a ellas como " imágenes de tarjetas ". Hoy en día, los lenguajes de programación más utilizados permiten mucha más flexibilidad en el formato. 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, sobre todo por su uso a veces indebido. Los experimentos han confirmado repetidamente que el esfuerzo está altamente correlacionado con SLOC ; es decir, los programas con valores SLOC más altos requieren más tiempo de desarrollo. Por lo 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 presentar más funcionalidad que otro programa similar. Considerar SLOC como una medida de productividad tiene sus inconvenientes, ya que un desarrollador puede escribir solo unas pocas líneas y ser mucho más productivo en términos de funcionalidad que un desarrollador que termina creando más líneas (y, por lo general, dedicando más esfuerzo). Los buenos desarrolladores pueden fusionar varios módulos de código en uno solo, mejorando el sistema pero aparentando tener una productividad negativa porque eliminan código. Además, los desarrolladores inexpertos suelen recurrir a la duplicación de código , lo cual está muy desaconsejado, ya que es más propenso a errores y costoso de mantener, pero resulta en un SLOC más alto.

El conteo de líneas de código fuente (SLOC) presenta problemas de precisión al comparar programas escritos en diferentes lenguajes, a menos que se apliquen factores de ajuste para normalizar los lenguajes. Los distintos lenguajes de programación equilibran la brevedad y la claridad de diferentes maneras; por ejemplo, la mayoría de los lenguajes ensamblador 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 frecuente al comparar métricas de líneas de código fuente (SLOC) es la diferencia entre el código autogenerado y el escrito manualmente. Las herramientas de software modernas suelen generar automáticamente enormes cantidades de código con solo unos clics. 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 al espacio de trabajo. El trabajo que implica crear este código no se puede comparar razonablemente con el necesario para escribir un controlador de dispositivo , por ejemplo. Del mismo modo, una clase de interfaz gráfica de usuario personalizada escrita manualmente podría ser mucho más compleja que un simple controlador de dispositivo; de ahí la limitación de esta métrica.

Existen varios modelos de estimación de costos, plazos y esfuerzo que utilizan SLOC como parámetro de entrada, incluyendo la serie de modelos ampliamente utilizada 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, su eficacia depende de las estimaciones (en particular, las estimaciones de SLOC) que se les proporcionan. Muchos [ 2 ] han defendido 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 universalmente aceptada.

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 de Red Hat Linux [ 6 ] (lanzada en abril de 2001) contenía más de 30 millones de líneas de código fuente físicas. También extrapoló que, de haberse desarrollado mediante métodos propietarios convencionales, habría requerido aproximadamente 8000 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 conocido 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 una manera propietaria convencional habría requerido 14.005 años-persona y un costo de US$1.900 millones para su desarrollo. 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 2005La última versión incluirá más de 213 millones de líneas de código fuente.

Utilidad

Ventajas

  1. Posibilidad de automatizar el conteo: dado que una línea de código es una entidad física, el conteo manual puede eliminarse fácilmente automatizando el proceso. Se pueden desarrollar pequeñas utilidades para contar las líneas de código en un programa. Sin embargo, una utilidad de conteo de código lógico desarrollada para un lenguaje específico no puede utilizarse en otros lenguajes debido a las diferencias sintácticas y estructurales. No obstante, se han creado contadores físicos de líneas de código que funcionan en decenas de lenguajes.
  2. Una métrica intuitiva: las líneas de código sirven como una métrica intuitiva para medir el tamaño del software, ya que son visibles y permiten visualizar su efecto. Se dice que los puntos de función son una métrica más objetiva, que no puede concebirse como una entidad física; existen únicamente en el espacio lógico. De esta manera, las líneas de código resultan útiles para expresar el tamaño del software entre programadores con poca experiencia.
  3. Medida omnipresente: Las medidas LOC existen desde los inicios del software. [ 15 ] Por lo tanto, se podría argumentar que hay más datos LOC disponibles que de cualquier otra medida de tamaño.

Desventajas

  1. Falta de rendición de cuentas: la medición basada en líneas de código presenta algunos problemas fundamentales. Algunos opinan que no es útil medir la productividad de un proyecto utilizando únicamente los resultados de la fase de codificación, que generalmente representa solo entre el 30 % y el 35 % del esfuerzo total.
  2. Falta de cohesión con la funcionalidad: si bien los experimentos han confirmado repetidamente que el esfuerzo está altamente correlacionado con las líneas de código (LOC), la funcionalidad no lo está tanto. Es decir, los desarrolladores expertos pueden desarrollar la misma funcionalidad con mucho menos código, por lo que un programa con menos LOC puede presentar más funcionalidad que otro programa similar. En particular, las LOC son una medida deficiente de la productividad individual, ya que un desarrollador que escribe solo unas pocas líneas puede ser más productivo que uno que escribe más. Incluso más: una buena refactorización, como "extraer método", para eliminar código redundante y mantenerlo limpio, reducirá considerablemente las líneas de código.
  3. Impacto adverso en la estimación: debido a lo expuesto en el punto #1, las estimaciones basadas en líneas de código pueden resultar erróneas, con toda probabilidad.
  4. Experiencia del desarrollador: la implementación de una lógica específica varía según el nivel de experiencia del desarrollador. Por lo tanto, el número de líneas de código difiere de una persona a otra. Un desarrollador experimentado puede implementar cierta funcionalidad con menos líneas de código que otro desarrollador con menos experiencia, aunque utilicen el mismo lenguaje.
  5. Diferencias de lenguajes: consideremos dos aplicaciones que ofrecen la misma funcionalidad (pantallas, informes, bases de datos). Una 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 algunos aspectos de la aplicación serían diferentes. Las líneas de código necesarias para desarrollar la aplicación no serían las mismas. En consecuencia, el 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, el número de puntos de función se mantendrá constante.
  6. La llegada de las herramientas GUI : con la llegada de los lenguajes de programación y herramientas basadas en interfaces gráficas de usuario (GUI), 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 la función de arrastrar y soltar, entre otras operaciones con el ratón, para colocar componentes en un espacio de trabajo. El código generado automáticamente por una herramienta GUI no suele tenerse en cuenta al usar métodos de medición de líneas de código (LOC). Esto genera variaciones entre lenguajes; la misma tarea que se puede realizar en una sola línea de código (o incluso sin código) en un lenguaje puede requerir varias líneas en otro.
  7. Problemas con múltiples lenguajes: en el panorama actual del software, este se desarrolla a menudo en más de un lenguaje. Con frecuencia, se emplean varios lenguajes según la complejidad y los requisitos. El seguimiento y la elaboración de informes sobre la productividad y las tasas de defectos representan un grave problema, ya que, una vez integrado el sistema, no es posible atribuir los defectos a un lenguaje específico. En este caso, los puntos de función se perfilan como la mejor medida de tamaño.
  8. Falta de estándares de conteo: no existe una definición estándar de lo que constituye una línea de código. ¿Cuentan los comentarios? ¿Se incluyen las declaraciones de datos? ¿Qué sucede si una instrucción abarca varias líneas? Estas son las preguntas que suelen surgir. Si bien organizaciones como SEI e IEEE han publicado algunas directrices para intentar estandarizar el conteo, resulta difícil ponerlas en práctica, especialmente ante la aparición de nuevos lenguajes 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 gerencia en las líneas de código, mayor será el incentivo para que el programador amplíe su código con una complejidad innecesaria. Esto es indeseable, ya que una mayor complejidad puede conllevar un aumento en los costos de mantenimiento y en el esfuerzo necesario para corregir errores.

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

En IBM hay una especie de religión en el software que dice que hay que contar K-LOCs, y un K-LOC son mil líneas de código. ¿Qué tan grande es el proyecto? Oh, es como un proyecto de 10K-LOCs. Este es de 20K-LOCs. Y este es de 50K-LOCs. E IBM quería convertirlo en una especie de religión sobre cómo nos pagaban. Cuánto dinero ganamos con OS/2 , cuánto hicieron ellos. ¿Cuántos K-LOCs hiciste? Y seguíamos tratando de convencerlos: oye, si tenemos, si un desarrollador tiene una buena idea y puede hacer algo en 4K-LOCs en lugar de 20K-LOCs, ¿deberíamos ganar menos dinero? Porque ha hecho algo más pequeño y rápido, menos K-LOCs. K-LOCs, K-LOCs, esa es la metodología. ¡Uf! En fin, siempre me da escalofrío pensar en todo eso.

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

Cuando el equipo de Lisa se esforzaba por finalizar su software en 1982, los gerentes de proyecto comenzaron a exigir a los programadores que presentaran formularios semanales informando sobre la cantidad de líneas de código que habían escrito. Bill Atkinson pensó que era una tontería. Para la semana en 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, escribió "-2000" en el formulario. Después de unas semanas más, los gerentes dejaron de pedirle que completara el formulario, y él accedió con gusto. [ 16 ] [ 17 ]

Véase también

Notas

  1. ↑ Posiblemente incluya todo el paquete iLife, no solo el sistema operativo y las aplicaciones que normalmente vienen incluidas.

Referencias

  1. ↑ Vu Nguyen; Sophia Deeds-Rubin; Thomas Tan; Barry Boehm (2007), Un estándar de conteo de 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. 1 2 3 4 5 6 "¿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 el libro The Build Master de Vincent Maraia como fuente de la información.
  4. ↑ "¿Cuántas líneas de código tiene Windows XP?" . Microsoft. 11 de enero de 2011. Archivado del original el 26 de febrero de 2022.
  5. ↑ "Historia de Windows - Microsoft Windows" . 21/09/2012. Archivado del original el 21/09/2012 . Consultado el 26/03/2021 .
  6. 1 2 David A. Wheeler (30 de junio de 2001). "Más que un gigadólar: 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. 1 2 3 4 5 Robles, Gregorio. "Debian Counting" . Archivado del original el 14 de marzo de 2013. Recuperado 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 la base de código 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 del original el 23 de febrero de 2014. Recuperado el 7 de febrero de 2014 .
  10. ↑ Jobs, Steve (agosto de 2006). "En directo desde la WWDC 2006: Discurso principal de Steve Jobs" . Consultado el 16 de febrero de 2007. 86 millones de líneas de código fuente que se portaron para ejecutarse en una arquitectura completamente nueva sin ningún problema.
  11. ↑ Thorsten Leemhuis (3 de diciembre de 2009). "Novedades de Linux 2.6.32" . Archivado del 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: a qué ritmo avanza, quién lo lleva a cabo, qué hacen 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, estadísticas: el H Open: noticias y artículos" . Archivado del 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 . 18 de julio de 2010. 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 .

Lecturas adicionales

  • Li, Luo; Herbsleb, Jim; Shaw, Mary (mayo de 2005). Pronóstico de tasas de defectos en campo utilizando un enfoque combinado basado en el tiempo y en métricas: un estudio de caso de OpenBSD (CMU-ISRI-05-125) . Universidad Carnegie-Mellon.
  • McGraw, Gary (marzo-abril de 2003). "Desde cero: el taller de seguridad de software de DIMACS" . IEEE Security & Privacy . 1 (2): 59– 66. doi : 10.1109/MSECP.2003.1193213 .
  • Park, Robert E.; et  al. (31 de agosto de 1992). "Medición del tamaño del software: un marco para contar las declaraciones fuente" . Informe técnico CMU/SEI-92-TR-20 .
  • Definiciones de líneas prácticas de código fuente Las métricas estándar de recursos (RSM) definen las "líneas de código efectivas" como una métrica de código realista independiente del estilo de programación.
  • Métricas eLOC efectivas de líneas de código para software de código abierto popular como Linux Kernel 2.6.17, Firefox, Apache HTTPD, MySQL y PHP usando RSM.
  • Wheeler, David A. "SLOCCount" . Consultado el 12 de agosto de 2003 .
  • Wheeler, David A. (junio de 2001). "Conteo de líneas de código fuente (SLOC)" . Recuperado el 12 de agosto de 2003 .
  • Tanenbaum, Andrew S. Sistemas operativos modernos (2.ª ed.). Prentice Hall. ISBN 0-13-092641-8.
  • Howard Dahdah (24 de enero de 2007). "Tanenbaum describe su visión para un sistema operativo a prueba de abuelas" . Archivado del original el 27 de enero de 2007. Consultado el 29 de enero de 2007 .
  • CM Lott. "Herramientas de recopilación de métricas para código fuente C y C++" . Archivado del original el 19 de junio de 2020.
  • Folklore.org: Historias de Macintosh: -2000 líneas de código
Obtenido de " https://en.wikipedia.org/w/index.php?title=Source_lines_of_code&oldid=1355860712 "
Lecturas relacionadas
6 articulos
Programa de computadoraPrograma de computadoraUn programa informático es una secuencia o conjunto de instrucciones en un lenguaje de programación que un ordenador debe ejecutar . Es un componen...Código fuenteEjemplo de código fuente simple en lenguaje C , un lenguaje de programación procedimental . El programa resultante imprime "hola, mundo" en la pant...Productividad de programaciónProductividad de programaciónLa productividad de programación (también llamada productividad de software o productividad de desarrollo ) describe el grado de capacidad de los p...iconoMantenibilidadLa mantenibilidad es la característica de diseño inherente de un sistema o producto que determina la probabilidad de que pueda mantenerse o restaur...Orden de magnitudOrden de magnitudEl orden de magnitud es un concepto utilizado para analizar la escala de números en relación con otros.Hora-hombreHora-hombreUna hora-hombre u hora-humana es la cantidad de trabajo realizado por el trabajador promedio en una hora . [1] [2] Se utiliza para estimar la canti...