Crie uma nova variável para encurtar o código

Question

Crie uma nova variável para encurtar o código

#1 resposta do (4 votos)
#2 resposta do (4 votos)

5

Muitas vezes me perguntei sobre as implicações de encurtar código atribuindo variáveis temporárias com nomes mais curtos a acessos de dados com nomes longos. É melhor ilustrado por um exemplo (em Ruby, mas não que isso importe):

Este código longo é feio, IMO:

# Trim the description to MAX_LENGTH characters followed by "..."
# if the description is MAX_LENGTH characters or longer
def shorthand_description
    return (some_object.nested_hash.description.length >= MAX_LENGTH)
           ? "#{some_object.nested_hash.description[0..MAX_LENGTH]}..."
           : some_object.nested_hash.description
end

Isso parece ser muito mais legível:

def shorthand_description
    desc = some_object.nested_hash.description
    return (desc.length >= MAX_LENGTH)
           ? "#{desc[0..MAX_LENGTH]}..."
           : desc
end

Pessoalmente, eu quase sempre curto as variáveis se a cadeia de acesso longo tiver mais de 20 caracteres e for repetida. Está criando uma variável apenas para tornar o código mais legível aceitável? Depende de diretrizes de estilo para o idioma ou é um conceito agnóstico de linguagem?

code-quality coding-style clean-code

por Chris Cirefice 23.06.2016 / 05:15

fonte

2 respostas

4

When you see a good move, look for a better one.
—Emanuel Lasker, 27-year world chess champion

É um ótimo aprimoramento de legibilidade, mas sempre procure o melhor movimento. Nesse caso, você provavelmente está encobrindo problemas com suas responsabilidades sendo perdidas. O princípio de procurar evitar essas cadeias de identificadores tem seu próprio nome: a Lei de Demeter .

Talvez isso se encaixe melhor como description.shorthand() ou como truncate_to_length(string, length) . Sim, há exceções para todas as regras, como essa página do C2 que eu fiz a ligação explica, mas se esta é uma ocorrência regular, você provavelmente está introduzindo um monte de acoplamentos desnecessários em sua arquitetura.

por 23.06.2016 / 08:44

fonte

Tags code-quality coding-style clean-code

Deve-se usar um banco de dados separado para dados do aplicativo e dados do usuário? Como alterar agressivamente o ponteiro inteligente interno para unique_ptr?

score 4 · Accepted Answer

(Minha resposta ignora os efeitos da otimização - suponho que exista uma máquina processando seu código que possa fazer uma otimização decente para que a variável extra que está sendo criada para facilitar a leitura não faça diferença no desempenho.)

Na minha experiência, escreva seu código para ser entendido. Um nome curto e significativo é definitivamente mais aceitável do que repetir uma sequência muito longa de caracteres, seja qual for a linguagem. Quando você voltar ao código novamente em uma semana / mês / ano, você apreciará essa pequena clareza adicionada para ajudar você a entender melhor.

Dito isso, se você estiver aprimorando o código existente, siga as convenções que já estão sendo usadas. Se o seu código parecer muito "diferente" sem um bom motivo, será difícil para a pessoa que o analisar entender o motivo. E se as convenções forem realmente terríveis e perturbadoras, refatore o código (certifique-se de que existem testes) ou, pelo menos, adicione um comentário realmente bom explicando o que está acontecendo. Esta não é a década de 1960, quando o armazenamento era muito caro para permitir o esclarecimento de comentários no código-fonte.

A melhor regra: Escreva seu código como se o próximo desenvolvedor designado para trabalhar nele fosse realmente mau e irritado e conhecesse seu endereço de casa.