Deveríamos estar atentos a códigos mentirosos?

9

Isso se refere a uma discussão em uma resposta e aos comentários desta pergunta: O que há com a aversão à documentação no setor? . A resposta alegou que "o código não pode mentir" e, portanto, deve ser o local de destino em vez da documentação. Vários comentários apontaram que "o código pode mentir". Existe verdade em ambos os lados, pelo menos em parte devido à forma como a documentação é inadequada e inadequada.

Deveríamos estar atentos ao código mentiroso, comparando-o com qualquer documentação existente? Ou geralmente é a melhor fonte para o que precisa ser feito? Se for um código ágil, é menos provável que ele mente, ou esse código não pode mentir?

documentation

— thursdaysgeek
fonte

11

Você poderia esclarecer o que você quer dizer com "mentira"? Não devemos nos referir a comentários em outra pergunta para obter seu contexto.

— user16764

@ user16764 Sem olhar para o outro segmento, a primeira coisa a pop em mente é o dissimulado C Concurso

— Izkata

Se a documentação diz que o código deve funcionar bem, e o código bar, isso significa que bar é o que o código deveria estar fazendo? Ou estamos assumindo que a barra é a ação correta porque nunca lemos a documentação, porque o código está sempre correto?

— thursdaysgeek

Se o código foi aceito como barra, a documentação está incorreta e desatualizada. Mas se foo e bar estão intimamente relacionados, e os usuários não perceberam que isso não resolve os problemas da maneira esperada, então talvez a documentação sobre foo não esteja errada? Em outras palavras, o código é realmente tudo e tudo o que o código deveria estar fazendo?

— thursdaysgeek

9

Nas palavras dos leigos:

Sim , você deve procurar o código da mentira e fazê-lo dizer a verdade. Mas não comparando-o com a documentação. Esse seria um método para detectar a documentação que está.

Existem várias maneiras pelas quais o código pode estar, das quais mencionarei apenas algumas:

Blocos de código que nunca são executados porque condições que nunca são atendidas. O código está mentindo sobre o quanto ele faz.
O código que adiciona complexidade desnecessária reside na complexidade do problema.
O código sem convenções de nomenclatura está porque leva você a pensar que faz algo diferente do que está realmente fazendo.

Quanto mais curto, menos ele fica. É auto-evidente.

Quanto menos complicado o código, mais transparente ele é. Então está menos.

Os truques de sintaxe arcanos são muito comuns. Prefira algoritmos claros e passo a passo. Eles mentem menos.

Uma boa ferramenta de análise de código estático pode ajudá-lo a encontrar o código que está.

Além disso, uma boa bateria de teste automatizada força o código a dizer a verdade.

— Tulains Córdova
fonte

4

The shorter and terser the code is, the less it lies. It's self evident. Eu dificilmente diria isso. Na minha experiência, quanto mais curto e terso o código, mais oportunidades ele tem de varrer o assunto, geralmente ocultando-o em chamadas de função enganosas.

— Mason Wheeler

@MasonWheeler Você está certo. Eu editei a parte "concisa".

— Tulains Córdova

Não estou convencido de "Código sem convenções de nomenclatura". Certamente é ruim, mas como pode estar mentindo se não está lhe dizendo nada? "Eu não vou te dizer!" é teimosamente obstrutivo e desinformativo, mas não enganoso. Certamente a "mentira" é quando existe uma convenção de nomenclatura, mas é usada de uma maneira que não corresponde ao que o código realmente faz - por exemplo, se você estiver usando húngaro (eca!), Mas ocasionalmente tenha o prefixo pde uma variável que não é um ponteiro.

— Steve314

2

Na verdade, o que você está sugerindo pode ser melhor descrito como "sofisma" do que simplesmente como "mentiras". O sofisma tende a ser detalhado e complicado precisamente, de modo que é difícil ver as falhas lógicas e é superficialmente inteligente e confiante, para que as pessoas tenham medo de questioná-lo, caso pareçam estúpidas.

— Steve314

Outro exemplo: código que altera as propriedades subjacentes do idioma ou tempo de execução, por exemplo, redefinindo ou mascarando o comportamento primitivo.

— 23613 JustinCelebrC

6

Código não pode mentir.

O que está em código é o que seu programa está fazendo atualmente - independentemente da documentação, controle de qualidade ou do cliente. Especialmente se o seu código foi lançado e está em campo há algum tempo, esse comportamento esperado não deve ser ignorado.

O código pode certamente estar incorreto . Certamente pode ser enganoso em sua nomeação ou organização. Certamente pode ser ilegível.

Mas se você deseja a fonte da verdade para o que o seu código está fazendo , não o que ele deve fazer, não o que ele foi projetado para fazer, não o que você pensou que estava fazendo ... se você precisa saber o que está realmente fazendo, vá para o código.

— Telastyn
fonte

Existe uma escola de pensamento de que, se você é deliberadamente enganoso, mas pedanticamente correto, não está mentindo. Não é a única escola de pensamento. Por exemplo, eu tenho uma edição antiga de Detecting Lies and Deceit, de Aldert Vrij . Uma das primeiras coisas que isso faz é considerar várias definições de mentira e engano, optando por incluir afirmações pedanticamente corretas, mas deliberadamente enganosas, em parte porque esse é um entendimento comum de qualquer maneira.

— Steve314

Desculpe, mas dizer "mas foi pedanticamente correto" não significa que você não pode ser chamado de mentiroso - mesmo que as pessoas não respondam, elas ainda sabem disso.

— Steve314

@ steve314 - pssh. A pergunta original era sobre comentários. Construir um homem de palha para esses raros cenários em que o código é enganosamente nomeado para argumentar a favor dos comentários (e ignorar o cenário muito comum de comentários desatualizados) é absurdo.

— Telastyn

11

Eu concordo com isso - não estou discutindo o que você defende, apenas a definição aparente de "mentira" que você usa ao fazê-lo. O código pode mentir - não para o compilador, mas certamente para os leitores humanos. É até um objetivo intencional em alguns casos - coisas como o concurso ofuscado de C seriam um exemplo relativamente benigno. Sofisticação, como sugiro no meu comentário para user61852. Só porque um compilador vê através da mentira não significa que não é uma mentira.

— precisa saber é o seguinte

@Telastyn Acho que você nunca teve um filtro para redirecionar, fazendo com que um passo a passo realmente acontecesse no espaço em branco e, então, entre no código não chamado desse método, para nunca mais voltar, não é? Deus, eu odeio os desenvolvedores! @ # $ Java fazer com Java.

— usar o seguinte

0

Você faz várias perguntas.

Deveríamos estar atentos ao código mentiroso?

Claro!

Deveríamos comparar o código com qualquer documentação existente?

Isso nunca poderia prejudicar, embora, como mencionado em outras respostas, isso muitas vezes o levará a encontrar problemas na documentação , não no código .

Ou [código] geralmente é a melhor fonte para o que ele precisa fazer?

É sempre a melhor fonte para o que está fazendo. A melhor fonte para o que o código deve estar fazendo pode ser (uma combinação de) coisas diferentes, sendo as principais:

O próprio código;
O código de chamada;
Comentários nesse código;
Documentação;
Testes de unidade;
Testes de integração e regressão;
O programador;
O usuário final;

Qual é a "melhor" fonte (ou combinação das mesmas) depende da sua situação.

Se for um código ágil, é menos provável que ele mente, ou esse código não pode mentir?

Não sei ao certo o que você quer dizer com "código ágil", o AFAIK "ágil" geralmente se refere ao processo de codificação. Supondo que você queira dizer "código criado em um processo de programação ágil", acho que é seguro dizer que ainda pode mentir. A probabilidade de mentir, comparado ao código criado em, por exemplo, projetos no estilo cascata, é uma questão subjetiva (pessoalmente, não acho que exista uma grande conexão).

Nota de rodapé
Tudo o que precede está sob a suposição de que o código pode estar, e que este é um exemplo básico (embora pouco artificial):

public int DivideByTwo(int input) 
{
    return input / 3;
}

Este é apenas um exemplo em que eu diria "código mente", o @ user61852 possui alguns outros (código inacessível, complexidade do código que não corresponde à complexidade do problema, má nomeação) e acho que existem muitos outros. A Wikipedia tem um resumo um tanto decente de mentiras , muitas delas podem ser encontradas código.

Observe que, se você estiver discutindo com alguém, tenha certeza de que o da outra pessoa não significa "código não pode mentir" que "código faz o que faz". Em essência, a outra pessoa aqui está definindo usando uma definição para "mentira" que é tão estreita que pode declarar a declaração "código não pode mentir" como axioma / verdade básica. Nesse caso, provavelmente é melhor concordar com seu axioma.

— Jeroen
fonte

0

if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

Você pode discutir se a palavra "mentira" é tecnicamente apropriada, mas esse código implica claramente que x às vezes será maior que 5 e às vezes não. Se você olhar para o programa completo e descobrir que essa função é sempre chamada apenas em um lugar e que x é sempre definido como 6 constante, isso é mentira.

Além disso, o compilador pode ter notado isso e substituído esse bloco de código por simplesmente

doSomething()

Se o doADifferentThing não for chamado em nenhum outro lugar do seu programa, ele poderá ser removido completamente do programa.

Se seu idioma suportar assertalgum tipo, que é desativado nas compilações de produção, cada assertdeclaração é potencialmente uma mentira. Um typecast é outra afirmação que pode ser uma mentira.

— MatrixFrog
fonte