Zero como uma constante?

14

Eu encontrei este idioma de programação recentemente:

const float Zero = 0.0;

que é então usado em comparações:

if (x > Zero) {..}

Alguém pode explicar se isso é realmente mais eficiente, legível ou sustentável do que:

if (x > 0.0) {..}

NOTA: Eu posso pensar em outros motivos para definir esta constante, estou apenas pensando sobre o seu uso no contexto this .

    
por NWS 03.07.2012 / 12:42
fonte

6 respostas

29

Os possíveis motivos são o armazenamento em cache, a nomenclatura ou o tipo de força

Cache (não aplicável)

Você deseja evitar o custo de criação de um objeto durante o ato de comparação. Em Java, um exemplo seria

BigDecimal zero = new BigDecimal ("0.0");

isso envolve um processo de criação bastante pesado e é melhor servido usando o método estático fornecido:

BigDecimal zero = BigDecimal.ZERO;

Isso permite comparações sem incorrer em um custo repetido de criação, pois o BigDecimal é pré-armazenado em cache pela JVM durante a inicialização.

No caso do que você descreveu, um primitivo está executando o mesmo trabalho. Isso é amplamente redundante em termos de armazenamento em cache e desempenho.

Nomeação (improvável)

O desenvolvedor original está tentando fornecer uma convenção de nomenclatura uniforme para valores comuns em todo o sistema. Isso tem algum mérito, especialmente com valores incomuns, mas algo básico como zero só vale a pena no caso do caso de cache anterior.

Forçando o tipo (mais provável)

O desenvolvedor original está tentando forçar um determinado tipo primitivo para garantir que as comparações sejam convertidas em seu tipo correto e possivelmente em uma escala específica (número de casas decimais). Tudo bem, mas o nome simples "zero" provavelmente é um detalhe insuficiente para este caso de uso, com ZERO_1DP sendo uma expressão mais apropriada da intenção.

    
por 03.07.2012 / 13:02
fonte
6

É por causa do "ferramental Nagging"

Um possível motivo que não vejo listado aqui é porque muitas ferramentas de qualidade sinalizam o uso de números mágicos . Muitas vezes, é uma prática ruim ter números mágicos > lançados em um algoritmo sem torná-los claramente visíveis para alterações posteriores, especialmente se forem duplicados em vários locais no código.

Assim, embora essas ferramentas tenham razão em sinalizar esses problemas, elas geralmente geram falsos positivos para situações em que esses valores são inofensivos e provavelmente são estáticos ou apenas valores de inicialização.

E quando isso acontece, às vezes você enfrenta a escolha de:

  • marcando-os como falsos positivos, se a ferramenta permitir (geralmente com um comentário formatado especialmente, o que é irritante para pessoas que NÃO usam a ferramenta)
  • ou extraindo esses valores para constantes, seja importante ou não.

Sobre o desempenho

Depende da linguagem, eu acho, mas isso é bastante comum em Java e não tem impacto no desempenho, pois os valores são embutidos em tempo de compilação se eles forem constantes reais static final . Não teria um impacto em C ou C ++ se eles fossem declarados como constantes ou até mesmo como macros pré-processadores.

    
por 03.07.2012 / 13:11
fonte
5

Isso pode fazer sentido, pois define explicitamente que Zero é do tipo float .

Pelo menos em C e C ++, o valor 0.0 é do tipo double , enquanto o equivalente float é 0.0f . Portanto, supondo que o x que você compara também seja sempre float dizendo

x > 0.0

ao mesmo tempo, promova x to double para corresponder ao tipo de 0.0 que pode causar problemas (especialmente com testes de igualdade). A comparação sem conversão seria, obviamente,

x > 0.0f

que faz o mesmo que

float Zero = 0.0; // double 0.0 converted to float  
x > Zero

No entanto, acho que seria muito mais útil permitir avisos de conversões no compilador, em vez de fazer com que os usuários escrevessem códigos inábeis.

    
por 03.07.2012 / 13:10
fonte
1

Em primeiro lugar, aqui zero é definido como float , não int . Claro, isso não afeta nada na comparação, mas em outros casos quando esta constante é usada, pode fazer diferença.

Não vejo outra razão pela qual Zero seja declarado uma constante aqui. É apenas um estilo de codificação, e é melhor seguir o estilo se for usado em qualquer outro lugar nesse determinado programa.

    
por 03.07.2012 / 12:48
fonte
1

É quase certamente tão eficiente durante a execução (a menos que seu compilador seja muito primitivo) e muito pouco eficiente durante a compilação.

Quanto a saber se isso é mais legível do que x > 0 ... lembre-se de que há pessoas que sinceramente, genuinamente, acham que o COBOL foi uma ótima ideia e um prazer trabalhar com ele - e há pessoas que pensam exatamente da mesma sobre C. (Há rumores de que existem até mesmo alguns programadores com a mesma opinião sobre o C ++!) Em outras palavras, você não irá obter um acordo geral sobre este ponto, e provavelmente não vale a pena lutar acabou.

    
por 03.07.2012 / 12:49
fonte
0

[is] this is really any more efficient or readable or maintainable than:

if (x > 0.0) {..}

Se você estava escrevendo código genérico (ou seja, não específico do tipo), então muito possivelmente. Uma função zero() pode ser aplicada a qualquer tipo algébrico, ou qualquer tipo que seja um grupo w.r.t. Adição. Poderia ser um inteiro, poderia ser um valor de ponto flutuante, poderia até ser uma função se sua variável fosse, digamos, uma função dentro de algum espaço linear (por exemplo, x é uma função linear da forma z - > a_x * z + b_x) e, em seguida, zero() fornece a função com a e b ambos sendo zero() do tipo subjacente.

Então você esperaria que tal código, digamos, C ++ possivelmente (embora um zero() não seja muito comum AFAIK), ou em Julia, e talvez outros idiomas.

    
por 09.01.2018 / 15:35
fonte