Qual é a razão para estas regras PMD?

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

  •  06-07-2019
  •  | 
  •  

Pergunta

DataflowAnomalyAnalysis: Encontrado 'DD'-anomalia para a variável 'variável' (Linhas 'n1' - 'n2').

DataflowAnomalyAnalysis: Encontrado 'DU'-anomalia para a variável 'variável' (Linhas 'n1' - 'n2').

DD e DU som familiar ... Eu quero dizer em coisas como testes e análises relativas ao mais fraco pré e pós-condições, mas eu não me lembro dos detalhes.

NullAssignment: atribuir um objeto a nulo é um cheiro de código. Considerar refatoração.

não iria definir um objeto para null auxiliar na coleta de lixo, se o objeto é um objeto local (não utilizados fora do método)? Ou isso é um mito?

MethodArgumentCouldBeFinal: Parâmetro 'Param' não é atribuída e poderia ser declarou final

LocalVariableCouldBeFinal: local 'Variável' variável poderia ser declarado final

Existem quaisquer vantagens em usar parâmetros final e variáveis?

LooseCoupling: Evite usar tipos de implementação como 'LinkedList'; usar a interface em vez

Se eu sei que eu especificamente precisa de um LinkedList, por que eu não usar um para fazer minhas intenções explicitamente claro para futuros desenvolvedores? É uma coisa para voltar a classe que é mais alto até o caminho da classe que faz sentido, mas por que eu não declaro meus variáveis ??a ser de sentido estrito?

AvoidSynchronizedAtMethodLevel: Use nível de bloco em vez de nível método sincronização

Quais as vantagens que a sincronização em nível de bloco têm mais de sincronização em nível de método?

AvoidUsingShortType: Não use o tipo curto

As minhas primeiras línguas foram C e C ++, mas no mundo Java, por que eu não deveria usar o tipo que melhor descreve meus dados?

Foi útil?

Solução

  • DD e DU anomalias (se bem me lembro-me usar FindBugs e as mensagens são um pouco diferentes) referem-se a atribuir um valor a uma variável local que não é lido, geralmente porque é reatribuída outro valor antes mesmo de sendo lido. Um caso típico seria inicializar algumas variáveis ??com null quando é declarada. Não declarar a variável até que seja necessário.

  • A atribuição null a uma variável local, a fim de "ajudar" o coletor de lixo é um mito. PMD está deixando você sabe que esta é a desordem apenas contra-produtivo.

  • A especificação final sobre uma variável local deve ser muito útil para um otimizador, mas eu não tenho quaisquer exemplos concretos de EIC atuais aproveitando essa dica. Descobri que é útil no raciocínio sobre a correção do meu próprio código.

  • A especificação de interfaces em termos de ... bem, Interfaces é uma grande prática de design. Você pode facilmente mudar as implementações da coleção sem impactar o chamador em tudo. Isso é o que as interfaces são tudo.

  • Eu não posso pensar de muitos casos em que um chamador requerem a LinkedList, uma vez que não expõe qualquer API que não é declarado por alguns interface. Se o cliente se baseia em que API, está disponível através da interface correta.

  • sincronização Bloquear nível permite a seção crítica a ser menores, o que permite que tanto trabalho a ser feito ao mesmo tempo possível. Talvez mais importante, permite a utilização de um objecto de bloqueio que é controlada em particular por objecto a envolvente. Dessa forma, você pode garantir que nenhum bloqueio pode ocorrer. Usando o exemplo se como um bloqueio, ninguém pode sincronizar on-lo incorretamente, causando impasse.

  • Operandos do tipo short são promovidos a int em qualquer operação. Esta regra é que você saiba que esta promoção está ocorrendo, e assim como você pode usar um int. No entanto, usando o tipo de short pode economizar memória, por isso, se é um membro de instância, eu provavelmente ignorar essa regra.

Outras dicas

DataflowAnomalyAnalysis: Encontrado 'DD'-anomalia para a variável 'variável' (Linhas 'n1' - 'n2').

DataflowAnomalyAnalysis: Encontrado 'DU'-anomalia para a variável 'variável' (Linhas 'n1' - 'n2').

Não faço ideia.

NullAssignment: atribuir um objeto a nulo é um cheiro de código. Considerar refatoração.

não iria definir um objeto para null auxiliar na coleta de lixo, se o objeto é um objeto local (não utilizados fora do método)? Ou isso é um mito?

Objetos em métodos locais estão marcados para ser lixo coletado uma vez o método retorna. Colocando-os como nulo não vai fazer qualquer diferença.

Uma vez que tornaria menos desenvolvedores experimentar o que é que a atribuição nulo tudo sobre ele pode ser considerado um cheiro de código.

MethodArgumentCouldBeFinal: Parâmetro 'Param' não é atribuída e poderia ser declarou final

LocalVariableCouldBeFinal: local 'Variável' variável poderia ser declarado final

Existem quaisquer vantagens em usar parâmetros final e variáveis?

É tornar mais claro que o valor não vai mudar durante o ciclo de vida do objeto.

Além disso, se por acaso alguém tentar atribuir um valor, o compilador irá impedir este erro de codificação no tipo de compilação.

considere o seguinte: 

 public void businessRule( SomeImportantArgument important )  {
      if( important.xyz() ){
          doXyz();
      }
      // some fuzzy logic here
      important = new NotSoImportant();
      // add for/if's/while etc 

     if( important.abc() ){ // <-- bug
         burnTheHouse();
     }
  }

Suponha que você está atribuído a resolver alguns bug misterioso que de vez em quando queima a casa.

Você sabe o que eras o parâmetro utilizado, o que não entendo é Por o método burnTHeHouse é invocado, se não forem cumpridas as condições (de acordo com suas descobertas)

Ele faz demorar um pouco para findout que em algum ponto no meio, somone alterar a referência, e que você está usando outros objeto.

Usando final ajuda a prevenir este tipo de coisas.

LooseCoupling: Evite usar tipos de implementação como 'LinkedList'; usar a interface em vez

Se eu sei que eu especificamente precisa de um LinkedList, por que eu não usar um para fazer minhas intenções explicitamente claro para futuros desenvolvedores? É uma coisa para voltar a classe que é mais alto até o caminho da classe que faz sentido, mas por que eu não declaro meus variáveis ??a ser de sentido estrito?

Não há nenhuma diferença, neste caso. Gostaria de pensar que desde que você não está usando a funcionalidade LinkedList específica a sugestão é justo.

Hoje, LinkedList poderia fazer sentido, mas usando uma interface que você ajudar a sua própria (ou outros) para mudá-lo facilmente quando ele não vai.

Para projetos pequenos, pessoais, isso pode não fazer sentido em tudo, mas desde que você está usando um analisador já, eu acho que você se preocupa com a qualidade do código já.

Além disso, ajuda desenvolvedor menos experiente para criar bons hábitos. [Eu não estou dizendo que você é um, mas o analisador não sabe que você;)]

AvoidSynchronizedAtMethodLevel: Use nível de bloco em vez de nível método sincronização

Quais as vantagens que a sincronização em nível de bloco têm mais de sincronização em nível de método?

Quanto menor for a secção sincronizado melhor. É isso.

Além disso, se você sincronizar no nível do método que você vai bloquear todo o objeto. Quando você sincroniza a nível de bloco, basta sincronizar essa seção específica, em algumas situações, isso é o que você precisa.

AvoidUsingShortType: Não use o tipo curto

As minhas primeiras línguas foram C e C ++, mas no mundo Java, por que eu não deveria usar o tipo que melhor descreve meus dados?

Eu nunca ouvi falar disso, e eu concordo com você :) Eu nunca usar short embora.

Meu palpite é que, por não usá-lo, você ajudado a sua auto upgrade para atualizar a int sem problemas.

Código cheiros são mais orientados para a qualidade do código de otimizações de desempenho. Assim, o conselho é dado para programadores menos experientes e armadilhas a evitar, do que para melhorar a velocidade do programa.

Desta forma, você pode economizar muito tempo e frustrações ao tentar alterar o código para caber um projeto melhor.

Se o conselho não faz sentido, simplesmente ignorá-los, lembre-se, você é o desenvolvedor em carga, e a ferramenta é apenas que uma ferramenta. Se algo der errado, você não pode culpar a ferramenta, certo?

Apenas uma nota sobre a questão final.

Pondo "final" em um resultados variáveis ??em que só seja atribuível uma vez . Isso não significa necessariamente que é mais fácil de escrever, mas certamente significa que é mais fácil de Leia para um futuro mantenedor.

Por favor, considere os seguintes pontos:

  • qualquer variável com um final pode ser imediatamente classificado em "não alterar o valor enquanto assiste".
  • por implicação isso significa que se todas as variáveis ??que não vai mudar são marcados com final, em seguida, as variáveis ??não marcado com o Final realmente vai mudar.

Isso significa que você já pode ver quando a leitura através da parte definição que variáveis ??de olhar para fora, porque podem alterar valor durante o código, eo mantenedor pode gastar his / her esforços melhor como o código é mais legível.

não iria definir um objeto como nulo auxiliar na coleta de lixo, se o objeto é um objeto local (não utilizado fora do método)? Ou isso é uma mito?

A única coisa que faz é torná-lo possível para o objeto a ser GCD antes do final do método, que é raramente necessário.

Existem quaisquer vantagens em usar parâmetros finais e variáveis?

Isso torna o código um pouco mais clara desde que você não precisa se preocupar com o valor a ser alterado somwhere quando você analisar o código. Mais frequentemente então não você não precisa ou quer mudar o valor de uma variável, uma vez que é criado de qualquer maneira.

Se eu sei que eu especificamente precisa de um LinkedList, por que eu não usar um para fazer minhas intenções explicitamente claro para futuros desenvolvedores?

Você pode pensar em qualquer razão por que você especificamente precisa de um LinkedList?

É uma coisa para voltar a classe que é maior o caminho de classe que faz sentido, mas porque Eu não iria declarar meus variáveis ??para ser do sentido estrito?

Eu não me importo muito com variáveis ??locais ou campos, mas se você declarar um parâmetro de método do tipo LinkedList, eu vou te caçar e te machucar, porque torna impossível para mim usar coisas como Arrays.asList() e Collections.emptyList().

Quais as vantagens que a sincronização em nível de bloco têm mais de sincronização em nível de método?

O maior deles é que ele permite que você use um objeto monitor dedicado para que somente aqueles seções críticas são mutuamente exclusivos que precisam ser, ao invés de tudo usando o mesmo monitor.

no mundo Java, por que não eu usar o tipo que melhor descreve a minha dados?

Porque tipos menores que int são automtically promovido a int para todos os cálculos e você tem para fazer cair a qualquer coisa atribuir a eles. Isto leva a código confuso e bastante confustion (especialmente quando autoboxing está envolvido).

AvoidUsingShortType: Não use o tipo curto

  • item da lista

    curta é de 16 bits, 2 de elogio em java

  • a operaion mathmatical curto com qualquer coisa na parte externa da família Integer de outro curta vai exigir uma conversão extensão de sinal tempo de execução para o tamanho maior. operando contra um ponto flutuante requer extensão de sinal e uma conversão não-trivial para IEEE-754.
  • não pode encontrar a prova, mas com um registo de 32 bits ou 64 bits, você não é mais a poupança de 'instruções do processador' a nível bytecode. Você está estacionamento um carro compacto em um ponto de estacionamento de um semi-reboque, tanto quanto o registrador do processador está em causa.
  • Se você está otimizando seu projeto no nível de código byte, wow. apenas Uau. ; P
  • Concordo no lado do projeto de ignorar este aviso PMD, apenas pesar descrevendo com precisão o seu objeto com um 'curto' contra as conversões de desempenho incorridos.
  • Na minha opinião, os hits de desempenho incorridos são minúsculos na maioria das máquinas. ignorar o erro.

Que vantagens a nível de bloco sincronização têm sobre método de nível sincronização? Sincronizar um método é como fazer um bloco synchronize(getClass()), e bloqueia toda a classe.

Talvez você não quer que

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top