Dovremmo cercare il codice bugiardo?

9

Questo si riferisce a una discussione in una risposta e ai commenti di questa domanda: che cosa è l'avversione alla documentazione nel settore? . La risposta affermava che "il codice non può mentire" e quindi dovrebbe essere la posizione di riferimento anziché la documentazione. Diversi commenti hanno sottolineato che "il codice può mentire". Vi è verità da entrambe le parti, almeno in parte a causa della scarsa e inappropriata gestione della documentazione.

Dovremmo cercare il codice bugiardo, confrontandolo con qualsiasi documentazione esistente? O di solito è la migliore fonte per ciò che deve fare? Se è un codice agile, ha meno probabilità di mentire o quel codice non può mentire affatto?

documentation

— thursdaysgeek
fonte

1

Potresti chiarire cosa intendi per "menzogna"? Non dovremmo fare riferimento ai commenti in un'altra domanda per ottenere il tuo contesto.

— user16764

@ user16764 Senza guardare l'altro thread, la prima cosa da ricordare è il Underhanded C Contest

— Izkata,

Se la documentazione dice che il codice dovrebbe fare foo, e il codice fa bar, significa che bar è ciò che il codice dovrebbe fare? O stiamo assumendo che la barra sia l'azione corretta perché non abbiamo mai letto la documentazione, perché il codice è sempre corretto?

— giovedì giovedì

Se il codice è stato accettato come barra, la documentazione è errata e obsoleta. Ma se foo e bar sono strettamente correlati e gli utenti non hanno notato che non risolve completamente i loro problemi come si aspettavano, allora forse la documentazione su foo non è sbagliata? In altre parole, il codice è davvero il tutto e tutto ciò che il codice dovrebbe fare?

— giovedì giovedì

9

Nelle parole di laici:

Sì , dovresti cercare il codice bugiardo e farlo dire la verità. Ma non confrontandolo con la documentazione. Sarebbe un metodo per rilevare la documentazione che si trova.

Esistono diversi modi in cui il codice può mentire, di cui ne citerò solo alcuni:

Blocchi di codice che non vengono mai eseguiti a causa di condizioni che non vengono mai soddisfatte. Il codice ti sta mentendo su quanto fa.
Il codice che aggiunge complessità non necessarie risiede nella complessità del problema.
Il codice senza convenzioni di denominazione risiede nel fatto che ti induce a pensare di fare qualcosa di diverso da ciò che sta realmente facendo.

Più è corto, meno mente. È evidente.

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

I trucchi per la sintassi arcana risiedono molto. Preferisci algoritmi chiari e dettagliati. Mentono meno.

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

Anche una buona batteria di prova automatizzata impone al codice di dire la verità.

— Tulains Córdova
fonte

4

The shorter and terser the code is, the less it lies. It's self evident. Difficilmente lo direi. Nella mia esperienza, più breve è il codice, più opportunità ha di spazzare bugie sotto il tappeto, generalmente nascondendole in ingannevoli chiamate di funzione.

— Mason Wheeler,

@MasonWheeler Hai ragione. Ho modificato la parte "concisa".

— Tulains Córdova,

Non sono convinto da "Codice senza bugie sulle convenzioni di denominazione". È certamente brutto, ma come può mentire se non ti dice nulla? "Non ti sto dicendo!" è ostinatamente ostruttivo e disinformativo ma non ingannevole. Sicuramente la "bugia" è quando esiste una convenzione di denominazione, ma viene utilizzata in un modo che non corrisponde a ciò che il codice effettivamente fa - ad esempio se stai usando ungherese (yuck!) Ma a volte ha il prefisso pper una variabile che non è un puntatore.

— Steve314

2

In realtà, ciò che stai suggerendo potrebbe essere meglio descritto come "sofisma" piuttosto che semplicemente come "bugie". La sofferenza tende ad essere verbosa e complicata proprio per cui è difficile vedere i difetti logici, ed è superficialmente intelligente e sicura di sé, così che le persone hanno paura di metterlo in discussione nel caso in cui sembrino stupidi.

— Steve314

Un altro esempio: codice che modifica il linguaggio sottostante o le proprietà di runtime, ad esempio ridefinendo o mascherando il comportamento primitivo.

— Giustino

6

Il codice non può mentire.

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

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

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

— Telastyn
fonte

C'è una scuola di pensiero che se sei deliberatamente ingannevole ma pedantemente corretto, allora non stai mentendo. Non è l'unica scuola di pensiero. Ad esempio, ho una vecchia edizione di Detecting Lies and Deceit di Aldert Vrij . Una delle prime cose che fa è prendere in considerazione varie definizioni di menzogna e inganno, scegliendo di includere dichiarazioni pedanticamente corrette ma deliberatamente fuorvianti in parte perché è comunque un'intesa comune.

— Steve314,

Mi dispiace, ma dire "ma era pedanticamente corretto" non significa che non puoi essere chiamato bugiardo - anche se la gente non discute, lo sanno ancora.

— Steve314,

@ steve314 - pssh. La domanda originale riguardava i commenti. Costruire un uomo di paglia per questi rari scenari in cui il codice viene chiamato in modo fuorviante per discutere a favore del commento (e ignorare lo scenario molto comune di commenti non aggiornati) è assurdo.

— Telastyn,

1

Sono d'accordo con questo - non sto discutendo del punto che assumi, ma solo l'apparente definizione di "menzogna" che usi mentre lo fai. Il codice può mentire - non al compilatore, ma certamente ai lettori umani. È persino un obiettivo intenzionale in alcuni casi - cose come il contest offuscato C sarebbe un esempio relativamente benigno. Sofistica, come suggerisco nel mio commento a user61852. Solo perché un compilatore vede attraverso la bugia non significa che non sia una bugia.

— Steve314,

@Telastyn Immagino che non hai mai avuto un filtro per eseguire un reindirizzamento che ha effettivamente luogo un passaggio su spazi bianchi e quindi andare nel codice non chiamato da quel metodo, per non tornare mai, vero? Dio, odio gli sviluppatori! @ # $ Java fanno con Java.

— Erik Reppen,

0

Fai diverse domande.

Dovremmo cercare il codice bugiardo?

Ovviamente!

Dovremmo confrontare [codice] con qualsiasi documentazione esistente?

Ciò non potrebbe mai far male, anche se come menzionato in altre risposte, il più delle volte questo ti porterà a trovare problemi nella documentazione , non nel codice .

O il [codice] di solito è la migliore fonte per ciò che deve fare?

È sempre la migliore fonte per quello che sta facendo. La migliore fonte di ciò che il codice dovrebbe fare può essere (una combinazione di) cose diverse, 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;

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

Se è un codice agile, ha meno probabilità di mentire o quel codice non può mentire affatto?

Non sono sicuro di cosa intendi con "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ò ancora mentire. Quanto è probabile mentire, rispetto al codice creato ad esempio in progetti in stile cascata è una questione soggettiva (personalmente non penso che ci sia una grande connessione).

Nota a piè di pagina
Tutto quanto sopra presuppone che il codice possa mentire e che questo sia un esempio di base (anche se un po 'forzato):

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

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

Nota che se stai litigando con qualcuno, assicurati che l'altra persona non significhi che "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" che è così stretta che può dichiarare l'affermazione "il codice non può mentire" come un assioma / verità di base. In questo caso è probabilmente meglio concordare con il suo assioma.

— Jeroen
fonte

0

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

Puoi discutere se la parola "menzogna" è tecnicamente appropriata, ma questo codice implica chiaramente che x sarà talvolta maggiore di 5 e talvolta no. Se guardi il programma completo e scopri che questa funzione è chiamata in un solo posto e che x è sempre impostato su un costante 6, allora è una bugia.

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

doSomething()

Se doADifferentThing non viene chiamato in nessun altro punto del programma, potrebbe essere rimosso completamente dal programma.

Se la tua lingua supporta un assertqualche tipo, che è disattivato nelle build di produzione, ogni assertaffermazione è potenzialmente una bugia. Un typecast è un'altra affermazione che potrebbe essere una bugia.

— MatrixFrog
fonte