¿Qué es una línea de código?

votos
12

Me doy cuenta de que no hay una respuesta correcta para esta pregunta, pero cuando la gente habla de líneas de código, ¿qué significan? En C ++, por ejemplo, ¿cuentas líneas en blanco? comentarios? líneas con solo un corsé abierto o cercano?

Sé que algunas personas usan LoC como una medida de productividad, y me pregunto si hay una convención estándar aquí. Además, creo que hay una manera de obtener varios compiladores para contar las líneas de código. ¿Existe una convención estándar allí?

Publicado el 09/12/2008 a las 17:33
fuente por usuario
En otros idiomas...                            


20 respuestas

votos
22

No, no hay una convención estándar, y cada herramienta que los cuenta será ligeramente diferente.

Esto puede hacer que pregunte: "¿Por qué utilizaría LOC como medida de productividad?" y la respuesta es, porque realmente no importa cómo cuente una línea de código, siempre que los cuente consistentemente puede hacerse una idea del tamaño general de un proyecto en relación con los demás.

Respondida el 09/12/2008 a las 17:38
fuente por usuario

votos
11

Echa un vistazo al artículo de Wikipedia , especialmente a la sección " Measuring SLOC ":

Hay dos tipos principales de medidas SLOC: SLOC físico y SLOC lógico. 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, incluidas las líneas de comentario. Las líneas en blanco también se incluyen a menos que las líneas de código en una sección consten de más del 25% de líneas en blanco. En este caso, las líneas en blanco de más del 25% no se cuentan para las líneas de código.

Las medidas lógicas de SLOC intentan medir el número de "declaraciones", pero sus definiciones específicas están ligadas a lenguajes informáticos específicos (una simple medida lógica de SLOC para lenguajes de programación similares a C es el número de puntos y coma que terminan las declaraciones). Es mucho más fácil crear herramientas que midan el SLOC físico, y las definiciones físicas del SLOC son más fáciles de explicar. Sin embargo, las medidas físicas de SLOC son sensibles a las convenciones de estilo y formato lógicamente irrelevantes, mientras que las SLOC lógicas son menos sensibles a las convenciones de formato y estilo. Desafortunadamente, las medidas de 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:

for (i=0; i<100; ++i) printf("hello");   /* How many lines of code is this? */

En este ejemplo tenemos:

  • 1 líneas físicas de código LOC
  • 2 líneas lógicas de código lLOC (para instrucción y declaración printf)
  • 1 comentario línea

[...]

Respondida el 09/12/2008 a las 17:40
fuente por usuario

votos
8

Yo diría que

  • los comentarios cuentan
  • Las líneas en blanco cuentan, porque son importantes para la legibilidad, pero no más de una contigua
  • las líneas con llaves cuentan también, pero aplican la misma regla que las líneas en blanco, es decir, 5 llaves anidadas sin código entre ellas cuentan como una línea.

También sugeriría humildemente que cualquier medida de productividad que realmente dependa de un valor de LoC es litera :)

Respondida el 09/12/2008 a las 17:37
fuente por usuario

votos
4

Cualquier día que pueda terminar con menos líneas de código, pero tanta o más funcionalidad de trabajo ... es un buen día. Ser capaz de eliminar cientos de líneas de código y terminar con algo que es tan funcional, y más fácil de mantener, es algo maravilloso.

Dicho esto, a menos que tenga unas pautas de codificación muy estrictas en su equipo, las líneas físicas de código son una estadística inútil. Las líneas lógicas de código siguen siendo inútiles, pero al menos no son peligrosamente engañosas.

Respondida el 09/12/2008 a las 21:54
fuente por usuario

votos
3

Si usa LOC como medida de productividad, de repente encontrará que sus programadores escriben mucho más exhaustivamente para "jugar con el sistema". Es una medida estúpida, y solo las personas estúpidas la usan para algo más que los derechos de fanfarronear.

Respondida el 09/12/2008 a las 17:50
fuente por usuario

votos
3

Lo que sea que "wc -l" devuelva es mi número.

Respondida el 09/12/2008 a las 17:36
fuente por usuario

votos
2

1 línea = 4 segundos de lectura. Si se necesita más que eso para descubrir lo que estoy diciendo en esa línea, la línea es demasiado larga.

Respondida el 09/12/2008 a las 20:19
fuente por usuario

votos
2

Las "líneas de código" deben incluir todo lo que tenga que mantener. Eso incluye comentarios, pero excluye el espacio en blanco.

Si está utilizando esto como una métrica de productividad, asegúrese de hacer comparaciones razonables. Una línea de C ++ no es lo mismo que una línea de Ruby.

Respondida el 09/12/2008 a las 17:42
fuente por usuario

votos
1

La noción de LOC es un intento de cuantificar un volumen de código. Como se señaló en otras respuestas, no importa lo que específicamente llame una línea de código, siempre y cuando sea coherente. Intuitivamente, parece que un programa de 10 líneas es más pequeño que un programa de 100 líneas, que es más pequeño que un programa de 1000 líneas, y así sucesivamente. Es de esperar que se necesite menos tiempo para crear, eliminar y mantener un programa de 100 líneas que un programa de 1000 líneas. Informalmente al menos, puede usar LOC para dar una idea aproximada de la cantidad de trabajo requerido para crear, depurar y mantener un programa de un cierto tamaño.

Por supuesto, hay lugares donde esto no se sostiene. Por ejemplo, un algoritmo complejo representado en 1000 líneas puede ser mucho más difícil de desarrollar que, por ejemplo, un programa de base de datos simple que consume 2500 líneas.

Por lo tanto, LOC es una medida aproximada de volumen de código que permite a los gerentes obtener una comprensión razonable del tamaño de un problema.

Respondida el 09/12/2008 a las 21:12
fuente por usuario

votos
1

Debería pensar en "líneas de código gastadas ", no en "líneas de código producidas ".

Las cosas deben ser lo más simples posible, por lo que crear un punto de referencia positivo basado en la cantidad de líneas es alentar el código incorrecto.

Además, algunas cosas que son muy difíciles terminan siendo resueltas con muy poco código, y algunas cosas que son muy fáciles (código repetitivo como getters y setters por ejemplo) pueden agregar muchas líneas en muy poco tiempo.

En cuanto a la pregunta original, si iba a contar líneas, incluiría todas las líneas que no sean consecutivas en blanco. Incluiría comentarios también, ya que son (afortunadamente) documentación útil.

Respondida el 09/12/2008 a las 18:25
fuente por usuario

votos
1

No hay una respuesta correcta.

Para estimaciones informales, uso wc -l.

Si tuviera que medir algo rigurosamente, mediría las declaraciones ejecutables. Casi todo, cualquier cosa con un terminador de declaración (generalmente punto y coma) o terminando con un bloque. Para las declaraciones compuestas, contaría cada subrogación.

Asi que:

int i = 7;                  # one statement terminator; one (1) statement
if (r == 9)                # count the if as one (1) statement
  output("Yes");      # one statement terminator; one (1) statement; total (2) for the if
while (n <= 14) {    # count the while as one (1) statement
  output("n = ", n);  # one statement terminator; one (1) statement
  do_something();   # one statement terminator; one (1) statement
  n++                       # count this one, one statement (1), even though it doesn't need a statement terminator in some languages
}                              # brace doesn't count; total (4) for the while

Si lo estuviera haciendo en Scheme o Lisp, contaría expresiones.

Como otros han dicho, lo más importante es que su recuento es constante. También importa para qué estás usando esto. Si solo quieres que un nuevo empleado potencial sepa cuán grande es tu proyecto, usa wc -l. Si quiere hacer planes y estimar, puede ser más formal. En ningún caso debe utilizar LOC para basar la compensación del programador en.

Respondida el 09/12/2008 a las 18:17
fuente por usuario

votos
1

LOC es una métrica notoriamente ambigua. Para una comparación detallada, solo es válido al comparar el código que ha sido escrito en el mismo idioma, con el mismo estilo, por el mismo equipo.

Sin embargo, proporciona una cierta noción de complejidad cuando se mira en una idea de orden de magnitud. Un programa de 10000 líneas es mucho más complejo que un programa de 100 líneas.

La ventaja de LOC es que wc -l lo devuelve, y no hay ninguna fantasía real involucrada en su comprensión o cálculo, a diferencia de muchas otras métricas de software.

Respondida el 09/12/2008 a las 17:52
fuente por usuario

votos
0

El uso de LOC para medir un rendimiento programadores es como juzgar la calidad de una pintura de su tamaño. Sólo de LOC "valor" en lo que a mí respecta es para impresionar a sus clientes y asustar a su competencia.

Dicho esto, me gustaría pensar que el número de instrucciones compiladas sería la menos ambigua. Aún así, los malos programadores tienen la ventaja de que tienden a escribir código innecesariamente prolijo. Recuerdo que una vez que la sustitución de más de 800 líneas de código muy mal con 28 líneas. ¿Eso me hace un vago?

Cualquier jefe de proyecto que utiliza LOC como una métrica de rendimiento primario es un idiota que merece malos programadores.

Respondida el 01/09/2016 a las 21:40
fuente por usuario

votos
0

En el mundo .NET parece que hay un acuerdo global que una línea de código (LOC) es un punto de secuencia de depuración . Un punto de secuencia es una unidad de depuración, es la porción de código resaltado en color rojo oscuro cuando se pone un punto de ruptura. Con el punto secuencia podemos hablar de la Línea de Control lógica , y esta métrica se pueden comparar entre diferentes lenguajes .NET. La métrica de código de Línea de Control lógico es apoyada por la mayoría de las herramientas de .NET incluyendo métrica código VisualStudio, NDepend o NCover.

Un método 8 LoC (comenzando y terminando puntos de secuencia paréntesis no se tienen en cuenta):

texto alternativo

Contrariamente a la Línea de Control físico (que significa simplemente contando el número de línea en un archivo de origen) la Línea de Control lógico tiene la inmensa ventaja de no depender de estilo de codificación. Codificación de estilo, todos estamos de acuerdo en eso, puede hacer que el conteo Línea de Control física varía de un orden de magnitud de un desarrollador a otro. Escribí un post más detallado blog sobre el tema: ¿Cómo se cuenta el número de líneas de código (LOC)?

Respondida el 12/12/2010 a las 19:12
fuente por usuario

votos
0

Sé que algunas personas usan LoC como una medida de productividad

¿Me podría decir quiénes son para que no trabajo con accidentalmente (o, peor aún, a ) ellos?

Si puedo implementar en 1400 líneas usando Haskell lo que también podría implementar en 2800 líneas usando C, ¿soy más productivo en C o en Haskell? ¿Qué va a tomar más tiempo? ¿Cuál va a tener más errores (sugerencia: es lineal en el conteo de LOC)?

El valor de un programador es cuánto cambia su código (incluso desde o hacia la cadena vacía) aumenta el número en su línea inferior. No conozco una buena forma de medir o aproximar eso. Pero sé que cualquier métrica que se pueda medir razonablemente se puede evaluar y no refleja lo que realmente se desea. Entonces no lo uses.

Dicho eso, ¿cómo se cuentan los LOC? Simple, uso wc -l. ¿Por qué es esa la herramienta correcta? Bueno, probablemente no le interese ningún número en particular, sino las tendencias totales generales (subiendo o bajando, y por cuánto), sobre las tendencias individuales (subiendo o bajando, cambiando de dirección con qué rapidez, ...) y sobre casi todo menos el número 82,763.

Las diferencias entre lo que las herramientas miden probablemente no sean interesantes. A menos que tenga evidencia de que el número escupido por su herramienta (y solo esa herramienta) se correlaciona con algo interesante, úselo como una figura aproximada; cualquier cosa que no sea la monotonicidad debe tomarse no solo con un grano sino con un cubo de sal.

Cuenta cuántas veces '\n'ocurre. Otros personajes interesantes para contar podrían ser ';', '{'y '/'.

Respondida el 19/03/2009 a las 23:15
fuente por usuario

votos
0

Utilizo wc -lpara una estimación rápida de la complejidad de un espacio de trabajo. Sin embargo, como una métrica de productividad, LOC es LO PEOR . En general, considero que es un día muy productivo si mi conteo de LOC baja.

Respondida el 22/12/2008 a las 00:44
fuente por usuario

votos
0

Estoy de acuerdo con la respuesta aceptada por Craig H, sin embargo me gustaría añadir que en la escuela me enseñaron que el espacio en blanco, los comentarios y las declaraciones no deberían contarse como "líneas de código" en términos de medir las líneas de código producido por un programador para fines de productividad, es decir, la regla Ol '"15 líneas por día".

Respondida el 09/12/2008 a las 20:59
fuente por usuario

votos
0

Estoy de acuerdo con las publicaciones que dicen que se informan de muchas maneras y no es una métrica importante. Mira este ever-hear-of-developers-getting-paid-por-line-of-code .

Respondida el 09/12/2008 a las 20:09
fuente por usuario

votos
0

Lo veo como una sola declaración procesable. Por ejemplo

(1 línea)

Dim obj as Object

(5 líneas)

If _amount > 0 Then
  _amount += 5
Else
  _amount -= 5
End If
Respondida el 09/12/2008 a las 17:39
fuente por usuario

votos
0
  1. LOCphy: líneas físicas
  2. LOCbl: Blanklines Kommentarblocks werden als Kommentarzeile gezählt
  3. LOCpro: líneas de programación (declaraciones, definiciones, directivas y código)
  4. LOCcom: líneas de comentarios

Muchas herramientas disponibles dan información del porcentaje de líneas rellenas, etc.

Solo tienes que mirarlo, pero no solo contar con eso.

LOC está creciendo masivamente al inicio de un proyecto y disminuye a menudo después de las revisiones;)

Respondida el 09/12/2008 a las 17:38
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more