Líneas de código fuente

Líneas de código fuente (SLOC), también conocidas como líneas de código (LOC), son una métrica de software utilizada 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 involucran solo 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 un proyecto de 21 000 líneas. Si bien es discutible exactamente cómo medir 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.

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 conteo de líneas en el texto del código fuente del programa, excluyendo las líneas de comentarios.

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

• 1 línea física de código (LOC),
• 2 líneas lógicas de código (LLOC) (para declaración e declaración de imprenta),
• 1 línea de comentarios.

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

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

En este ejemplo tenemos:

• 4 líneas físicas de código (LOC): ¿está colocando el trabajo de aparatos para ser estimado?
• 2 líneas lógicas de código (LLOC): ¿qué pasa con todas las líneas de trabajo que no componen el estado?
• 1 línea de comentarios: las herramientas deben tener en cuenta todos los códigos y comentarios independientemente de la colocación de comentarios.

Incluso el "lógico" y "físico" Los valores SLOC pueden tener una gran cantidad de definiciones variables. 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 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 el código, y determinar qué código reutilizado (si lo hay) incluir es importante al informar sobre una medida.

Orígenes

En el momento en que la gente comenzó a usar 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 generalmente 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 las 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 un tanto controvertidas, particularmente por la forma en que a veces se usan de manera indebida. Los experimentos han confirmado repetidamente que el esfuerzo está altamente correlacionado con SLOC, es decir, los programas con valores de SLOC más altos toman más tiempo para desarrollarse. Por lo tanto, SLOC puede ser efectivo 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 inconvenientes, 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, en general, gastando 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 el código. Además, los desarrolladores sin experiencia a menudo recurren a la duplicación de código, lo que se desaconseja porque es más propenso a errores y costoso de mantener, pero da como resultado un SLOC más alto.

El conteo 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 "hola mundo" programa escrito en BASIC, C y COBOL (un lenguaje conocido por ser particularmente detallado).

PRINT "hola, mundo"

#include Identificado.hint principal() {} printf()"Hola, mundon");}

 identificación división. programa-id. Hola. . procedimiento división. pantalla "hola, mundo" Goback . final programa Hola. .

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 escrito a mano. Las herramientas de software modernas a menudo tienen la capacidad de generar automáticamente enormes cantidades de código con unos pocos clics del mouse. Por ejemplo, los constructores de interfaces gráficas de usuario generan automáticamente todo el código fuente para 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, cronogramas y esfuerzos que usan SLOC como parámetro de entrada, incluida la serie de modelos de modelos de costos constructivos (COCOMO) ampliamente utilizada por Barry Boehm et al., PRICE Systems True S y Galorath's vidente-SEM. Si bien estos modelos han mostrado un buen poder predictivo, son tan buenos como las estimaciones (particularmente las estimaciones SLOC) que se les alimentan. Muchos 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 universal.

Ejemplo

According to Vincent Maraia, the SLOC values for various operating systems in Microsoft 's Windows NT product line are as follows:

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 (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 patentados 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).

Más tarde 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 forma convencional, habría requerido 14 005 años-persona y habría costado 1900 millones de USD para desarrollarlo. Las 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. Alcance para la automatización de la contabilidad: ya que la línea de código es una entidad física, el esfuerzo de contabilidad manual se puede eliminar fácilmente mediante la automatización del proceso de conteo. Se pueden desarrollar pequeñas utilidades para contar el LOC en un programa. Sin embargo, no se puede utilizar una utilidad de contabilidad de código lógico para un idioma específico debido a las diferencias sintácticas y estructurales entre los idiomas. Sin embargo, se han producido contadores de LOC físico 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 el efecto de ella se puede visualizar. Se dice que los puntos de función son más de una métrica objetiva que no se puede imaginar como una entidad física, sólo existe en el espacio lógico. De esta manera, LOC viene útil para expresar el tamaño de software entre los programadores con bajos niveles de experiencia.
3. Medida Ubiquito: las medidas LOC han estado alrededor desde los primeros días del software. Como tal, se argumenta que hay más datos de LOC disponibles que cualquier otra medida de tamaño.

Desventajas

1. Falta de rendición de cuentas: la medida de las líneas de código sufre algunos problemas fundamentales. Algunos piensan que no es útil medir la productividad de un proyecto utilizando sólo los resultados de la fase de codificación, que generalmente representa sólo el 30% al 35% del esfuerzo general.
2. Falta de cohesión con la funcionalidad: aunque los experimentos han confirmado repetidamente que mientras el esfuerzo está muy correlacionado con LOC, la funcionalidad está menos bien correlacionada con LOC. Es decir, los desarrolladores calificados pueden desarrollar la misma funcionalidad con mucho menos código, por lo que un programa con menos LOC puede mostrar más funcionalidad que otro programa similar. En particular, LOC es una medida de productividad deficiente de los individuos, porque un desarrollador que desarrolla sólo unas pocas líneas puede ser aún más productivo que un desarrollador creando más líneas de código – aún más: un buen refactoring como "método de Extracción" para deshacerse del 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 ir mal, en toda posibilidad.
4. La 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 cierta funcionalidad en menos líneas de código que otro desarrollador de experiencia relativamente menor, aunque usan el mismo idioma.
5. Diferencia en idiomas: considerar dos aplicaciones que proporcionan 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 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 seguirá siendo constante.
6. Advent of GUI tools: with the advent of GUI-based programming languages and tools such as Visual Basic, programmers can write relatively little code and achieve high levels of 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 utilizar arrastrar y soltar y otras operaciones de ratón para colocar componentes en un espacio de trabajo. El código que se genera automáticamente por una herramienta GUI no suele tenerse en cuenta al utilizar métodos de medición LOC. Esto resulta en la variación entre idiomas; la misma tarea que se puede hacer en una sola línea de código (o ningún código en absoluto) en un idioma puede requerir varias líneas de código en otro.
7. Problemas con varios idiomas: en el escenario de software de hoy, el software se desarrolla a menudo en más de un idioma. Muy a menudo, varios idiomas se emplean dependiendo de la complejidad y los requisitos. El seguimiento y la presentación de informes sobre la productividad y las tasas de defectos plantea un grave problema en este caso, ya que los defectos no pueden atribuirse a un idioma particular después de la integración del sistema. El punto de función destaca ser la mejor medida de tamaño en este caso.
8. Falta de normas de contabilidad: no hay una definición estándar de lo que es una línea de código. ¿Los comentarios cuentan? ¿Se incluyen declaraciones de datos? ¿Qué pasa si una declaración se extiende sobre varias líneas? – Estas son las preguntas que a menudo surgen. Aunque organizaciones como SEI e IEEE han publicado algunas pautas en un intento de estandarizar el recuento, es difícil ponerlas en práctica especialmente ante nuevas y nuevas lenguas que se introducen cada año.
9. Psicología: un programador cuya productividad se mide en líneas de código tendrá un incentivo para escribir innecesariamente código verboso. Cuanto más gestión se centra en líneas de código, más incentivos tiene el programador para ampliar su código con complejidad sin necesidad. Esto es indeseable, ya que una mayor complejidad puede llevar a un mayor costo de mantenimiento y un mayor esfuerzo necesario para la fijación de errores.

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

En IBM hay una religión en el software que dice que tienes que contar K-LOCs, y un K-LOC es mil líneas de código. ¿Qué tan grande es un proyecto? Es un proyecto de 10K-LOC. Esto es un 20K-LOCer. Y esto es 50K-LOCs. Y IBM quería hacer la religión sobre cómo nos pagaron. Cuánto dinero ganamos con OS/2, cuánto hicieron. ¿Cuántos K-LOCs hiciste? Y seguimos tratando de convencerlos – hey, si tenemos – un desarrollador tiene una buena idea y él puede hacer algo en 4K-LOCs en lugar de 20K-LOCs, ¿debemos hacer menos dinero? Porque ha hecho algo más pequeño y más rápido, menos K-LOC. K-LOCs, K-LOCs, esa es la metodología. Ugh! De todos modos, eso siempre hace que mi espalda se arruga al pensar en todo.

Según el Computer History Museum, el desarrollador de Apple, Bill Atkinson, en 1982 encontró problemas con esta práctica:

Cuando el equipo de Lisa estaba tratando de finalizar su software en 1982, los directores de proyectos comenzaron a exigir a los programadores que presentaran formularios semanales informando sobre el número de líneas de código que habían escrito. Bill Atkinson pensó que era tonto. Para la semana en la que había reescrito las rutinas de cálculo de la región de QuickDraw para ser seis veces más rápido 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 rellenara el formulario y cumplió con alegría.