O que é uma linha de código?

votos
12

Eu percebo que não há definitivamente resposta certa a esta pergunta, mas quando as pessoas falam sobre linhas de código, o que eles significam? Em C ++, por exemplo, você conta as linhas em branco? comentários? linhas com apenas uma chave de abrir ou fechar?

Eu sei que algumas pessoas usam LoC como medida de produtividade, e eu estou querendo saber se existe uma convenção padrão aqui. Além disso, eu acho que há uma maneira de obter vários compiladores para contar linhas de código - existe uma convenção padrão lá?

Publicado 09/12/2008 em 17:33
fonte usuário
Em outras línguas...                            


20 respostas

votos
22

Não, não há nenhuma convenção padrão, e todas as ferramentas que conta deles será um pouco diferente.

Isso pode fazer você se perguntar: "Por que então eu nunca usar LOC como medida de produtividade?" ea resposta é, porque ele realmente não importa como você conta uma linha de código, desde que você contá-los de forma consistente, você pode ter uma idéia do tamanho geral de um projeto em relação aos outros.

Respondeu 09/12/2008 em 17:38
fonte usuário

votos
11

Ter um olhar para a Wikipedia artigo , especialmente o " Medindo SLOC secção":

Existem dois tipos principais de medidas SLOC: SLOC física e SLOC lógico. definições específicas destas duas medidas variam, mas a definição mais comum de SLOC física é uma contagem de linhas no texto do código-fonte do programa, incluindo linhas de comentário. As linhas em branco, a menos que também estão incluídas as linhas de código em uma secção constituída por linhas em branco mais do que 25%. Neste caso as linhas em branco em excesso de 25% não são contados para linhas de código.

medidas SLOC lógicos tentam medir o número de "declarações", mas suas definições específicas estão ligadas a linguagens de computador específicos (uma medida SLOC lógica simples para linguagens de programação C-like é o número de ponto e vírgula de terminação de instrução). É muito mais fácil para criar ferramentas que medem SLOC física e definições SLOC físicos são mais fáceis de explicar. No entanto, as medidas de SLOC físicos são sensíveis a logicamente irrelevantes formatação e estilo convenções, enquanto SLOC lógica é menos sensível a formatação e estilo convenções. Infelizmente, as medidas SLOC são muitas vezes afirmou, sem dar a sua definição, e SLOC lógica muitas vezes pode ser significativamente diferente de SLOC física.

Considerar este fragmento de código C como um exemplo da ambiguidade encontrado quando se determinar SLOC:

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

Neste exemplo temos:

  • 1 linhas físicas de LOC Código
  • 2 Linhas lógicos de código LLOC (para declaração e declaração printf)
  • Linha 1 Comment

[...]

Respondeu 09/12/2008 em 17:40
fonte usuário

votos
8

eu diria

  • comentários contar
  • linhas em branco contam, porque eles são importantes para facilitar a leitura, mas não mais do que uma forma contígua
  • linhas com chaves também contam, mas aplicar a mesma regra para linhas em branco - ou seja, 5 chaves aninhadas com nenhum código entre eles conta como uma linha.

Eu também sugerem humildemente que qualquer medida de produtividade que realmente depende de um valor LoC é bobagem :)

Respondeu 09/12/2008 em 17:37
fonte usuário

votos
4

Qualquer dia que eu possa terminar com menos linhas de código, mas tanto ou mais funcionalidades de trabalho ... é um bom dia. Ser capaz de retirar centenas de linhas de código e acabar com algo que é tão funcional e mais sustentável, é uma coisa maravilhosa.

Dito isto, a menos que você tem diretrizes de codificação muito estritas em sua equipe, linhas físicas de código é uma estatística inútil. linhas lógicas de código ainda é inútil, mas como menos não é perigosamente enganoso.

Respondeu 09/12/2008 em 21:54
fonte usuário

votos
3

Se você usar LOC como medida de produtividade, de repente você vai encontrar os seus programadores escrevendo muito mais verbosely para "burlar o sistema". É uma medida estúpida, e apenas pessoas estúpidas usá-lo para algo mais do que se gabar.

Respondeu 09/12/2008 em 17:50
fonte usuário

votos
3

Seja qual for "wc -l" retorna é o meu número.

Respondeu 09/12/2008 em 17:36
fonte usuário

votos
2

1 linha = 4 segundos de leitura. Se é preciso mais do que isso para descobrir o que eu estou dizendo nessa linha, a linha é muito longo.

Respondeu 09/12/2008 em 20:19
fonte usuário

votos
2

"Linhas de código" deve incluir qualquer coisa que você tem que manter. Isso inclui comentários, mas exclui espaços em branco.

Se você estiver usando isso como uma métrica de produtividade, certifique-se que você está fazendo comparações razoáveis. Uma linha de C ++ não é o mesmo que uma linha de rubi.

Respondeu 09/12/2008 em 17:42
fonte usuário

votos
1

A noção de LOC é uma tentativa de quantificar o volume de código. Como apontado em outras respostas, não importa o que você especificamente chamar uma linha de código, desde que você é consistente. Intuitivamente, parece que um programa de 10 linha menor do que um programa de 100 linha que é menor do que um programa de 1000 linhas e assim por diante. Você esperaria que leva menos tempo para criar, deubg, e manter um programa de 100 linha do que um programa de 1000 line. Informalmente, pelo menos, você pode usar LOC para dar uma sensação áspera para a quantidade de trabalho necessário para criar, depurar e manter um programa de um determinado tamanho.

Claro, há lugares onde isso não se sustenta. Por exemplo, um algoritmo complexo processado em 1000 linhas pode ser muito mais difícil de desenvolver do que, digamos, um programa de banco de dados simples que consome 2500 linhas.

Então, LOC é uma medida de grão grosso do volume de código que permite que os gerentes de obter uma understading razoável do tamanho de um problema.

Respondeu 09/12/2008 em 21:12
fonte usuário

votos
1

Você deve estar pensando em "linhas de código passou ", não "linhas de código produzidas ".

As coisas devem ser tão simples quanto possível, de modo a criar uma referência positiva com base na quantidade de linhas é encorajador código ruim.

Além disso, algumas coisas que são muito difíceis acabam sendo resolvidos com muito pouco código, e algumas coisas que são muito fáceis (código clichê como getters e setters, por exemplo) pode adicionar um monte de linhas em muito pouco tempo.

Quanto à questão original, se eu estava indo para contar linhas, eu incluir cada linha diferente linhas em branco consecutivas. Eu incluir comentários, bem como, uma vez que são (espero) documentação útil.

Respondeu 09/12/2008 em 18:25
fonte usuário

votos
1

Não há uma resposta certa.

Para estimativas informais, eu uso wc -l.

Se eu precisava para medir algo rigorosamente, mediria instruções executáveis. Praticamente, qualquer coisa com um terminador de instrução (geralmente ponto e vírgula), ou terminando com um bloco. Para instruções compostas, eu contar cada subinstrução.

Assim:

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

Se eu estivesse fazendo isso no Esquema ou Lisp, eu contar expressões.

Como já foi dito, o que mais importa é que sua contagem é consistente. Também importa o que você está usando isso para. Se você quiser apenas para deixar um novo potencial de aluguer sabe o quão grande o seu projeto é, use wc -l. Se você está querendo fazer um planejamento e estimativa, então você pode querer obter mais formal. Você não deve, em caso algum, ser usando LOC à compensação programador base sobre.

Respondeu 09/12/2008 em 18:17
fonte usuário

votos
1

LOC é uma métrica notoriamente ambíguo. Para uma comparação detalhada, é válido apenas quando se compara o código que foi escrito na mesma língua, com o mesmo estilo, pela mesma equipe.

No entanto, ele fornece uma certa noção da complexidade quando analisada em uma idéia de ordem de magnitude. Um programa de 10000-line é muito mais complexo do que um programa 100-line.

A vantagem do LOC é que wc -l devolve-lo, e não há nenhuma fancyness real envolvido na compreensão ou calculá-lo, ao contrário de muitas outras métricas de software.

Respondeu 09/12/2008 em 17:52
fonte usuário

votos
0

Usando LOC para medir um desempenho programadores é como julgar a qualidade de uma pintura pelo seu tamanho. "Valor" única do LOC, tanto quanto eu estou preocupado é para impressionar os seus clientes e assustar a concorrência.

Dito isto, eu acho que o número de instruções compiladas seria o menos ambíguo. Ainda assim, maus programadores têm a vantagem de que eles tendem a escrever código desnecessariamente verbose. Lembro-me de uma vez substituindo mais de 800 linhas de muito ruim código com 28 linhas. Isso faz de mim um preguiçoso?

Qualquer gerente de projeto que usa LOC como uma métrica de desempenho primário é um idiota que merece programadores ruins.

Respondeu 02/09/2016 em 00:40
fonte usuário

votos
0

No mundo do .NET parece haver um acordo global que uma linha de código (LOC) é um ponto de seqüência de depuração . Um ponto de sequência é uma unidade de depuração, é a porção de código de destaque em vermelho-escuro quando se coloca um ponto de ruptura. Com ponto de seqüência podemos falar de LoC lógica , e essa métrica pode ser comparado em várias linguagens .NET. A métrica de código LoC lógica é apoiada pela maioria das ferramentas .NET incluindo métrica de código VisualStudio, NDepend ou NCover.

Um método 8 LoC (começando e acabando pontos de sequência colchetes não são tidos em conta):

texto alternativo

Ao contrário do LoC física (ou seja, apenas contando o número de linha em um arquivo de origem) a LoC lógica tem a imensa vantagem de não depender do estilo de codificação. Estilo de codificação, todos nós concordamos com isso, pode fazer a contagem LoC física variando de uma ordem de magnitude de um desenvolvedor para outro. Eu escrevi um post mais detalhado do blog sobre o tema: Como você contar o número de linhas de código (LOC)?

Respondeu 12/12/2010 em 19:12
fonte usuário

votos
0

Eu sei que algumas pessoas usam LoC como medida de produtividade

Você poderia me dizer quem são para que eu não possa trabalhar com (ou ainda pior, para ) eles?

Se eu pode implementar em 1400 linhas usando Haskell que eu também poderia implementar em 2800 linhas usando C, eu sou mais produtivo em C ou Haskell? Que vai demorar mais tempo? Que vai ter mais bugs (dica: é linear na contagem LOC)?

O valor de um programador é quanto suas alterações no código (incluindo a partir de ou para a cadeia vazia) aumenta o número em sua linha inferior. Não conheço nenhuma boa maneira de medir ou aproximar disso. Mas eu sei que qualquer métrica razoavelmente mensurável pode ser caçado e não reflete o que você realmente quer. Portanto, não usá-lo.

Dito isto, como você contar LOCs? Simples, uso wc -l. Por que é que a ferramenta certa? Bem, você provavelmente não se preocupam com qualquer número particular, mas sobre as tendências totais gerais (indo para cima ou para baixo, e por quanto), sobre as tendências individuais (indo para cima ou para baixo, mudando de direção quão rápido, ...) e sobre praticamente qualquer coisa, exceto apenas o número 82763.

As diferenças entre o que a medida ferramentas provavelmente não são interessantes. A menos que você tem evidências de que o número cuspir por sua ferramenta (e única essa ferramenta) se correlaciona com algo interessante, usá-lo como um valor aproximado áspera; outra coisa senão monotonicity deve ser tomado não só com grão, mas um balde de sal.

Conte quantas vezes '\n'ocorre. Outros personagens interessantes para contar poderia ser ';', '{'e '/'.

Respondeu 19/03/2009 em 23:15
fonte usuário

votos
0

Eu uso wc -lpara uma estimativa rápida da complexidade de um espaço de trabalho. No entanto, como a produtividade LOC métrica é o pior . Eu geralmente considerá-lo um dia muito produtivo se meu se a contagem LOC vai PARA BAIXO.

Respondeu 22/12/2008 em 00:44
fonte usuário

votos
0

Concordo w / a resposta aceito por Craig H, no entanto eu gostaria de acrescentar que na escola eu fui ensinado que espaço em branco, comentários e declarações não devem ser contados como "linhas de código" em termos de medir as linhas de código produzido por um programador para fins de produtividade - ou seja, regra Ol ‘15 linhas por dia’.

Respondeu 09/12/2008 em 20:59
fonte usuário

votos
0

Concordo com as mensagens que dizem que é relatado muitas maneiras e não é uma métrica importante. Veja esta sempre ouvir-of-developers-se-pago-per-line-of-code .

Respondeu 09/12/2008 em 20:09
fonte usuário

votos
0

Penso nele como uma única instrução processável. Por exemplo

(Uma linha)

Dim obj as Object

(5) linhas

If _amount > 0 Then
  _amount += 5
Else
  _amount -= 5
End If
Respondeu 09/12/2008 em 17:39
fonte usuário

votos
0
  1. LOCphy: fisicamente linhas
  2. LOCbl: Blanklines Kommentarblocks werden als Kommentarzeile gezählt
  3. LOCpro: linhas de programação (declarações, definições, directivas e código)
  4. LOCcom: linhas de comentários

Muitas ferramentas disponíveis estão dando informações de porcentagem de linhas cheias e assim por diante.

Você apenas tem que olhar para ele, mas não só contam sobre ele.

LOC está crescendo maciçamente no início de um projeto e diminui muitas vezes depois de comentários;)

Respondeu 09/12/2008 em 17:38
fonte usuário

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