Deve contagem LOC incluem testes e comentários?

StackOverflow https://stackoverflow.com/questions/274575

  •  07-07-2019
  •  | 
  •  

Pergunta

Enquanto LOC (# linhas de código) é uma medida problemática da complexidade do código, ele é o mais popular, e quando usado com muito cuidado, pode fornecer uma estimativa aproximada de pelo menos complexidades relativas de bases de código (ou seja, se um programa é 10KLOC e outra é 100KLOC, escrito na mesma língua, por equipes de aproximadamente a mesma competência, o segundo programa é quase certamente muito mais complexo).

Ao contar linhas de código, você prefere contar comentários em? E sobre os testes?

Já vi várias abordagens para isso. Ferramentas como o cloc e sloccount permitem incluir ou excluir comentários. Outras pessoas consideram comentários parte do código e sua complexidade.

Existe o mesmo dilema para testes de unidade, que às vezes pode chegar ao tamanho do próprio código testado, e até mesmo ultrapassá-lo.

Eu vi aborda todo o espectro, desde contando apenas as linhas "operacionais" não-comentário não estão em branco, para "linhas XXX de testado código, comentou", que é mais como correr "wc -l em todo o código arquivos do projeto".

Qual é a sua preferência pessoal, e por quê?

Foi útil?

Solução

Um homem sábio uma vez me disse 'você recebe o que você mede' quando se trata de gerir programadores.

Se você avaliá-los em sua saída LOC surpreendentemente você tende a ficar um monte de linhas de código.

Se você avaliá-los sobre o número de erros que fechar, surpreendentemente você terá um monte de bugs corrigidos.

Se você avaliá-los em recursos adicionais, você tem um monte de recursos.

Se você avaliá-los em complexidade ciclomática você começa funções ridiculamente simples.

Uma vez que um dos principais problemas com bases de código nos dias de hoje é a rapidez com que crescem e quão duro eles estão a mudança uma vez que já crescido, que tendem a se coíbe de usar LOC como uma métrica em tudo, porque ele dirige o comportamento fundamental errado.

Dito isto, se você tem que usá-lo, contar sans comentários e testes e exigem um estilo de codificação consistente.

Mas se você realmente quer uma medida de 'tamanho do código' apenas TAR.GZ a base de código. Ele tende a servir como uma melhor estimativa aproximada do 'conteúdo' do que as linhas de contagem que é suscetível a diferentes estilos de programação.

Outras dicas

Testes e comentários tem que ser mantida também. Se você estiver indo para usar LOC como uma métrica (e eu só vou assumir que eu não posso falar com você fora dela), você deve dar todos os três (linhas de código real, comentários, testes).

A coisa mais importante (e, esperamos óbvia) é que você seja consistente. Não relatar um projeto com apenas as linhas de código real e outro com todos os três combinados. Encontrar ou criar uma ferramenta que irá automatizar esse processo para você e gerar um relatório. 

Lines of Code:       75,000
Lines of Comments:   10,000
Lines of Tests:      15,000
                  ---------
Total:              100,000

Desta forma, você pode ter certeza que vai

  1. Get feito.
  2. Get feito da mesma maneira cada vez.

Eu pessoalmente não sinto que o LOC métrica em sua própria é tão útil como alguns dos outros métricas de código.

NDepend lhe dará a LOC métrica, mas também lhe dará muitos outros, tal complexidade cyclometric. Ao invés de enumerá-los todos, aqui está a ligação à lista.

Há também um livre CodeMetric add-in para refletor

Eu não vou responder diretamente a sua pergunta por uma razão simples: eu ódio as linhas de código métrica. Não importa o que você está tentando medir é muito difícil fazer pior do que LOC; Praticamente qualquer outra métrica que você gostaria de pensar vai ser melhor.

Em particular, você parece querer medir o complexidade do seu código. No geral cyclometric complexidade (também chamado de complexidade de McCabe) é muito melhor métrica para isso.

rotinas com uma alta complexidade cyclometric são as rotinas que você deseja focar sua atenção. É essas rotinas que são difíceis de teste, podre ao núcleo com erros e difíceis de manter.

Existem muitas ferramentas que medem esse tipo de complexidade. Uma rápida pesquisa no Google em seu idioma preferido vai encontrar dezenas de ferramentas que fazem este tipo de complexidade.

linhas de código significa exatamente isso: Sem comentários ou linhas vazias são contadas. E para que seja comparável a outros código fonte (não importa se a métrica em itsle fis útil ou não), você precisa de pelo menos estilos semelhantes de codificação: 

for (int i = 0; i < list.count; i++)
{
    // do some stuff
}

for (int i = 0; i < list.count; i++){
    // do some stuff
}

A segunda versão faz exatamente o mesmo, mas tem uma LOC menos. Quando você tem um monte de loops aninhados, isto pode resumir um pouco. É por isso que métricas como pontos de função foram inventados.

Depende do que você está usando o LOC para.

Como medida de complexidade - não tanto. Talvez o 100KLOC são na sua maioria código gerado a partir de uma tabela simples, eo 10KLOC kas 5KLOC regexps.

No entanto, vejo cada linha de código associado a um custo de funcionamento. Você paga para cada linha, enquanto as vidas de programa: ele precisa ser lido quando mantido, ele pode conter um erro que precisa ser corrigido, aumenta tempo de compilação, obter-de-source-controle e os tempos de backup, antes de mudança ou removê-lo pode ser necessário para descobrir se alguém confia nele etc. O custo médio pode ser nanopennies por linha e dia, mas de coisas que acrescenta-se.

KLOC pode ser um indicador primeiro tiro de quanto a infra-estrutura um projeto necessidades. Nesse caso, gostaria de incluir comentários e testes - mesmo que o custo de execução de uma linha de comentário é muito menor do que um dos regexp está no segundo projeto

.

[editar] [alguém com uma opinião semelhante sobre o tamanho do código] 1

Nós usamos somente algumas linhas de métrica código para uma coisa - uma função deve conter algumas linhas suficientes de código a ser lido sem rolagem da tela. Funções maiores do que normalmente são difíceis de ler, mesmo se eles têm uma muito baixa complexidade cyclometric. Para seu uso que fazemos contagem de espaços em branco e comentários.

Ele também pode ser bom para ver quantas linhas de código que você removido durante uma refactor - aqui você só quer contar linhas de código, espaços em branco que não facilitar a leitura e comentários que não são úteis (que não pode ser automatizado).

Finalmente um aviso - de uso de métricas de forma inteligente. Um bom uso de métricas é para ajudar a responder a pergunta 'qual parte do código se beneficiariam mais de refatoração' ou "como é urgente uma revisão de código para o último check-in? - uma função de 1,000 linha com uma complexidade ciclomática de 50 é um sinal de néon piscando dizendo 'refactor me now'. Um mau uso de métricas é 'quão produtivo é programador X' ou 'quão complicado é o meu software' .

Trecho do artigo: Como você contar o número de linhas de código (LOC) em relação à ferramenta NDepend que conta a lógica número de linhas de código para programas .NET.

Como você contar o número de linhas de código (LOC)?

Você conta método de declaração de assinatura? Você conta linhas apenas com suporte? Você conta várias linhas quando uma única chamada de método está escrito em várias linhas devido a um elevado número de parâmetros? Você conta ‘namespaces’ e ‘usando namespace’ declaração? Você conta interface e métodos abstratos declaração? Você conta campos de atribuição quando são declaradas? Você conta linha em branco?

Dependendo do estilo de codificação de cada um desenvolvedor e, dependendo do idioma escolha (C #, VB.NET ...) não pode haver diferença significativa através da medição do LOC.

Aparentemente medir a LOC de analisar arquivos de código parece um assunto complexo. Graças a um astuto existe uma maneira simples de medir exatamente o que é chamado o LOC lógico. O LOC lógica tem 2 vantagens significativas sobre o LOC física (o LOC que é inferida a partir de análise de arquivos de origem):

  • Codificação estilo não interfere com LOC lógico. Por exemplo, o LOC não vai mudar porque uma chamada de método é gerar em várias linhas devido a um elevado número de argumentos.
  • LOC Logical é independente do idioma. Os valores obtidos a partir de montagens escritos em diferentes idiomas são comparáveis ??e podem ser somadas.

No mundo da NET, o LOC lógica pode ser calculado a partir dos arquivos PDB, os arquivos que são usados ??pelo depurador para vincular o código IL com o código fonte. A ferramenta NDepend calcula o LOC lógico para um método desta forma: é igual ao número de ponto de seqüência encontrada por um método no arquivo PDB. Um ponto de sequência é usado para marcar um local no código IL que corresponde a um local específico na fonte original. Mais informações sobre pontos de seqüência aqui. Note que pontos de seqüência, que correspondem a C # chaves { ‘e‘}’não são tidos em conta.

Obviamente, o LOC para um tipo é a soma de seus métodos de LOC, a LOC para um namespace é a soma de seus tipos LOC, a LOC para uma assembléia é a soma do LOC de seus namespaces eo COL para uma aplicação é a soma dos seus conjuntos LOC. Aqui estão algumas observações:

  • Interfaces, métodos abstratos e enumerações ter um LOC é igual a 0. código Só concreto que é efetivamente executado é considerado no cálculo LOC.
  • Namespaces, tipos, campos e métodos declarações não são considerados como linha de código, porque eles não têm correspondentes pontos de seqüência.
  • Quando a C # ou VB.NET compilador enfrenta uma instância incorporada campos de inicialização, que gera uma sequência para cada ponto do construtor exemplo (a mesma observação aplica-se para os campos estáticos em linha de inicialização e construtor estático).
  • LOC calculado a partir de um método anônimo não interfere com o LOC de seus métodos declarando exteriores.
  • A relação global entre NbILInstructions e LOC (em C # e VB.NET) é normalmente cerca de 7.
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top