Dovremmo cercare codice bugiardo?

In parole semplici:

Sì , dovresti cercare codice bugiardo e farlo dire la verità. Ma non confrontandolo con la documentazione. Questo sarebbe un metodo per rilevare la documentazione che sta mentendo.

Ci sono molti modi in cui il codice può mentire, di cui menzionerò solo alcuni:

• Blocchi di codice che non vengono mai eseguiti perché le condizioni non sono mai soddisfatte. Il codice ti sta mentendo su quanto fa.
• Il codice che aggiunge complessità non necessaria riguarda la complessità del problema.
• Il codice senza convenzioni di denominazione si trova perché ti induce in errore a pensare che faccia qualcosa di diverso rispetto a ciò che fa realmente.

Più corto è, meno bugie. È evidente.

Meno è complicato il codice, più è trasparente. Quindi si trova di meno.

Trucchi sintattici arcani si trovano molto. Preferisci algoritmi chiari, passo dopo passo. Stanno meno.

Un buon strumento di analisi del codice statico può aiutarti a trovare il codice che giace.

Anche una buona batteria di test automatizzati obbliga il codice a dire la verità.

Il codice non può mentire.

Ciò che è in codice è ciò che sta facendo il tuo programma, indipendentemente dalla documentazione, dal controllo qualità o dal cliente. Soprattutto se il tuo codice è stato rilasciato ed è stato sul campo per un po ', quel comportamento atteso non dovrebbe essere ignorato.

Il codice può essere sicuramente errato . Può certamente essere fuorviante nella sua denominazione o organizzazione. Può certamente essere illeggibile.

Ma se vuoi la fonte della verità per ciò che il tuo codice è facendo , non ciò che deve fare, non ciò che è stato progettato per fare, non ciò che pensavi che stesse facendo ... se hai bisogno di sapere cosa sta facendo, vai al codice.

Fai varie domande.

Should we be on the lookout for lying code?

Certo!

Should we be comparing [code] against any existing documentation?

Questo non potrebbe mai far male, anche se come menzionato in altre risposte, molto spesso questo ti porterà a trovare problemi nella documentazione , non nel codice .

Or is [code] usually the best source for what it needs to be doing?

È sempre la migliore fonte per ciò che fa è . La migliore fonte di ciò che il codice dovrebbe fare può essere (una combinazione di) cose diverse però, le principali sono:

• Il codice stesso;
• Il codice chiamante;
• Commenti in quel codice;
• Documentazione;
• Test unitari;
• Test di integrazione e regressione;
• Il programmatore;
• L'utente finale;

Quale è la fonte "migliore" (o la sua combinazione) dipende dalla tua situazione.

If it is agile code, is it less likely to lie, or can that code not lie at all?

Non sono sicuro di cosa intenda per "codice agile", AFAIK "agile" di solito si riferisce al processo di codifica. Supponendo che tu intenda "codice creato in un processo di programmazione agile", allora penso che sia sicuro dire che può mentire ancora. Quanto è probabile mentire, rispetto al codice creato ad es. i progetti in stile cascata sono una questione soggettiva (personalmente non penso ci sia una grande connessione).

Nota
Tutto quanto sopra è sotto il presupposto che il codice può mentire e che questo sia un esempio di base (benché forzato):

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

Questo è solo un esempio in cui direi "code bugie", @ user61852 ha alcuni altri (codice non raggiungibile, complessità del codice che non corrisponde alla complessità del problema, cattiva denominazione), e penso che ce ne siano molti altri. Wikipedia ha un sommario di bugie abbastanza decente, molti di loro possono essere trovati codice.

Nota che se sei in una discussione con qualcuno, sii sicuro che l'altra persona non significa "il codice non può mentire" che "il codice fa quello che fa". In sostanza, l'altra persona qui sta definendo usando una definizione di "menzogna" così stretta che può dichiarare l'affermazione "il codice non può mentire" come un assioma / verità di base. In questo caso è probabilmente meglio essere d'accordo con il suo axioma.

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

Puoi discutere se la parola "lie" sia tecnicamente appropriata, ma questo codice implica chiaramente che x a volte potrebbe essere maggiore di 5 e talvolta no. Se guardi il programma completo e scopri che questa funzione viene sempre chiamata solo in un posto e che x è sempre impostata su una costante 6, allora questa è una bugia.

Inoltre, il compilatore potrebbe averlo notato e ha sostituito questo blocco di codice semplicemente con

doSomething()

Se doADifferentThing non viene chiamato da nessun'altra parte nel tuo programma, potrebbe essere rimosso completamente dal programma.

Se la tua lingua supporta un assert di qualche tipo, che è disattivato nelle build di produzione, ciascuna dichiarazione assert è potenzialmente una bugia. Un typecast è un'altra affermazione che potrebbe essere una bugia.