Quali cose suonano all'istante quando suona il codice? [chiuso]

Ho partecipato a un evento di artigianato del software un paio di settimane fa e uno dei commenti fatti è stato "Sono sicuro che tutti riconosciamo il codice errato quando lo vediamo" e tutti hanno annuito in modo sagace senza ulteriori discussioni.

Questo genere di cose mi preoccupa sempre perché c'è quel vero che tutti pensano di essere un guidatore sopra la media. Anche se penso di poter riconoscere il codice errato, mi piacerebbe saperne di più su ciò che gli altri considerano odori di codice poiché raramente è discusso in dettaglio nei blog delle persone e solo in una manciata di libri. In particolare, penso che sarebbe interessante sentire qualcosa che puzza di codice in una lingua ma non in un'altra.

Inizierò con uno semplice:

Codice nel controllo del codice sorgente che ha un'alta percentuale di codice commentato - perché è lì? doveva essere cancellato? è un lavoro a metà finito? forse non avrebbe dovuto essere commentato e fatto solo quando qualcuno stava testando qualcosa? Personalmente trovo questo tipo di cose davvero fastidioso anche se è solo la strana linea qua e là, ma quando vedi blocchi di grandi dimensioni intervallati dal resto del codice è totalmente inaccettabile. Di solito è anche un'indicazione che il resto del codice sarà probabilmente di dubbia qualità.

/* Fuck this error */

Tipicamente trovato all'interno di un try..catchblocco senza senso , tende ad attirare la mia attenzione. Quasi pure /* Not sure what this does, but removing it breaks the build */.

Un altro paio di cose:

• Più ifistruzioni complesse nidificate
• Blocchi Try-catch utilizzati per determinare un flusso logico su base regolare
• Funzioni con nomi generici process, data, change, rework,modify
• Sei o sette diversi stili di controventatura in 100 linee

Uno che ho appena trovato:

/* Stupid database */
$conn = null;
while(!$conn) {
    $conn = mysql_connect("localhost", "root", "[pass removed]");
}
/* Finally! */
echo("Connected successfully.");

Bene, perché dover forzare le tue connessioni MySQL è il modo giusto di fare le cose. Si scopre che il database stava avendo problemi con il numero di connessioni, quindi hanno continuato a scadere. Invece di eseguire il debug di questo, hanno semplicemente tentato ancora e ancora finché non ha funzionato.

La bandiera rossa principale per me sono i blocchi di codice duplicati, perché mostra che la persona o non capisce i fondamenti della programmazione o era troppo spaventata per apportare le modifiche appropriate a una base di codice esistente.

Contavo anche la mancanza di commenti come una bandiera rossa, ma di recente ho lavorato su un ottimo codice senza commenti che ho rimandato.

Codice che cerca di mostrare quanto sia intelligente il programmatore, nonostante non aggiunga alcun valore reale:

x ^= y ^= x ^= y;

• 20.000 funzioni di linea (esagerazione). Qualsiasi funzione che richiede più di un paio di schermate necessita di un nuovo factoring.

• Sulla stessa linea, file di classe che sembrano andare avanti per sempre. Probabilmente ci sono alcuni concetti che potrebbero essere astratti in classi che chiarirebbero lo scopo e la funzione della classe originale e probabilmente dove viene usata, a meno che non siano tutti metodi interni.

• variabili non descrittive, non banali o troppe variabili banali non descrittive. Questi fanno dedurre ciò che sta realmente accadendo un enigma.

{ Let it Leak, people have good enough computers to cope these days }

Quel che è peggio è che proviene da una biblioteca commerciale!

Commenti così dettagliati che se ci fosse un compilatore inglese, si compilerebbe ed eseguirà perfettamente, ma non descrive nulla che il codice non lo faccia.

//Copy the value of y to temp.
temp = y;
//Copy the value of x to y.
y = x;
//Copy the value of temp to x.
x = temp;

Inoltre, i commenti sul codice che avrebbero potuto essere eliminati se il codice avesse aderito ad alcune linee guida di base:

//Set the age of the user to 13.
a = 13;

Codice che genera avvisi quando viene compilato.

Funziona con numeri nel nome invece di avere nomi descrittivi , come:

void doSomething()
{
}

void doSomething2()
{
}

Per favore, fai in modo che i nomi delle funzioni significino qualcosa! Se doSomething e doSomething2 fanno cose simili, utilizzare nomi di funzioni che differenziano le differenze. Se doSomething2 è una rottura delle funzionalità di doSomething, chiamalo per la sua funzionalità.

Numeri magici o stringhe magiche.

   if (accountBalance>200) { sendInvoice(...); }

   salesPrice *= 0.9;   //apply discount    

   if (invoiceStatus=="Overdue") { reportToCreditAgency(); }

• Forse non è il peggiore, ma mostra chiaramente il livello degli implementatori:

  if(something == true) 

• Se una lingua ha un costrutto ciclo o iteratore, l'uso di un ciclo while dimostra anche il livello di comprensione della lingua da parte degli implementatori:

  count = 0; 
  while(count < items.size()){
     do stuff
     count ++; 
  }
  
  for(i = 0; i < items.size(); i++){
    do stuff 
  }
  //Sure this is not terrible but use the language the way it was meant to be used.
  

• La cattiva ortografia / grammatica nella documentazione / nei commenti mangia quasi quanto il codice stesso. Il motivo è dovuto al fatto che il codice era destinato alla lettura umana e all'esecuzione delle macchine. Questo è il motivo per cui usiamo linguaggi di alto livello, se la tua documentazione è difficile da superare, mi fa preventivamente formare un'opinione negativa della base di codice senza guardarla.

Quello che noto immediatamente è la frequenza di blocchi di codice profondamente nidificati (if's, while's, ecc.). Se il codice frequentemente supera i due o tre livelli di profondità, questo è un segno di un problema di progettazione / logica. E se arriva come 8 nidi in profondità, è meglio che ci sia una buona ragione per non romperlo.

Durante la valutazione del programma di uno studente, a volte posso dire in un momento in stile "battito di ciglia". Questi sono gli indizi istantanei:

• Formattazione scadente o incoerente
• Più di due righe vuote di fila
• Convenzioni di denominazione non standard o incoerenti
• Codice ripetuto, più ripetute sono le parole, più forte è l'avvertimento
• Quello che dovrebbe essere un semplice pezzo di codice è eccessivamente complicato (ad esempio, controllando gli argomenti passati al principale in modo contorto)

Raramente le mie prime impressioni sono errate e queste campane di avvertimento hanno ragione circa il 95% delle volte . Per un'eccezione, uno studente che non conosceva il linguaggio stava usando uno stile di un linguaggio di programmazione diverso. Scavare e rileggere il loro stile nel linguaggio dell'altra lingua mi ha rimosso i campanelli d'allarme e lo studente ha quindi ottenuto il pieno merito. Ma tali eccezioni sono rare.

Quando si considera un codice più avanzato, questi sono i miei altri avvertimenti:

• La presenza di molte classi Java che sono solo "strutture" per contenere i dati. Non importa se i campi sono pubblici o privati ​​e utilizzano getter / setter, probabilmente non fa ancora parte di un progetto ben congegnato.
• Classi che hanno nomi scadenti, come essere semplicemente uno spazio dei nomi e non c'è vera coesione nel codice
• Riferimento a modelli di progettazione che non sono nemmeno utilizzati nel codice
• Gestori di eccezioni vuoti senza spiegazione
• Quando estraggo il codice in Eclipse, centinaia di "avvisi" gialli allineano il codice, principalmente a causa di importazioni o variabili non utilizzate

In termini di stile, in genere non mi piace vedere:

• Commenti Javadoc che fanno solo eco al codice

Questi sono solo indizi per codice errato. A volte ciò che può sembrare un cattivo codice in realtà non lo è, perché non conosci le intenzioni del programmatore. Ad esempio, potrebbe esserci una buona ragione per cui qualcosa sembra eccessivamente complesso: potrebbe esserci stata un'altra considerazione in gioco.

Preferito preferito / pipì dell'animale domestico: IDE ha generato nomi che vengono commessi. Se TextBox1 è una variabile importante e importante nel tuo sistema, hai un'altra cosa in arrivo la revisione del codice.

Variabili completamente inutilizzate , specialmente quando la variabile ha un nome simile ai nomi delle variabili utilizzati.

Molte persone hanno menzionato:

//TODO: [something not implemented]

Mentre vorrei che le cose fossero implementate, almeno hanno preso nota. Quello che penso sia peggio è:

//TODO: [something that is already implemented]

I Todo sono inutili e confusi se non ti preoccupi mai di rimuoverli!

Un metodo che mi richiede di scorrere verso il basso per leggere tutto.

Congiunzioni nei nomi dei metodi:

public void addEmployeeAndUpdatePayrate(...) 


public int getSalaryOrHourlyPay(int Employee) ....

Chiarimento: il motivo per cui suona un campanello d'allarme è che indica che il metodo probabilmente viola il principio della singola responsabilità .

Collegando ovviamente il codice sorgente di GPL in un programma commerciale, a codice chiuso.

Non solo crea un problema legale immediato, ma nella mia esperienza, di solito indica disattenzione o disinteresse che si riflette anche altrove nel codice.

Lingua agnostica:

• TODO: not implemented
• int function(...) { return -1; } (lo stesso di "non implementato")
• Generare un'eccezione per un motivo non eccezionale.
• Uso improprio o incoerente di 0, -1o nullcome valori di ritorno eccezionali.
• Asserzioni senza un commento convincente che dice perché non dovrebbe mai fallire.

Specifico per la lingua (C ++):

• Macro C ++ in minuscolo.
• Variabili C ++ statiche o globali.
• Variabili non inizializzate o non utilizzate.
• Tutto array newciò che apparentemente non è sicuro per RAII.
• Qualsiasi utilizzo di array o puntatori apparentemente non sicuro ai limiti. Questo include printf.
• Qualsiasi utilizzo della parte non inizializzata di un array.

Specifico per Microsoft C ++:

• Qualsiasi nome identificativo che si scontra con una macro già definita da uno qualsiasi dei file di intestazione di Microsoft SDK.
• In generale, qualsiasi utilizzo dell'API Win32 è una grande fonte di campanelli d'allarme. Tenere sempre aperto MSDN e cercare gli argomenti / restituire le definizioni dei valori in caso di dubbio. (Modificato)

Specifico per C ++ / OOP:

• Ereditarietà dell'implementazione (classe concreta) in cui la classe genitore ha metodi sia virtuali che non virtuali, senza una chiara distinzione concettuale evidente tra ciò che dovrebbe / non dovrebbe essere virtuale.

Bizzarro stile di rientro.

Ci sono un paio di stili molto popolari e le persone porteranno quel dibattito alla tomba. Ma a volte vedo qualcuno che usa uno stile di rientro davvero raro, o addirittura cresciuto in casa. Questo è un segno che probabilmente non hanno codificato con nessuno diverso da loro stessi.

Utilizzo di molti blocchi di testo anziché enumerazioni o variabili definite a livello globale.

Non bene:

if (itemType == "Student") { ... }

Meglio:

private enum itemTypeEnum {
  Student,
  Teacher
}
if (itemType == itemTypeEnum.Student.ToString()) { ... }

Migliore:

private itemTypeEnum itemType;
...
if (itemType == itemTypeEnum.Student) { ... }

Parametri debolmente digitati o valori di ritorno sui metodi.

public DataTable GetEmployees() {...}

public DateTime getHireDate(DataTable EmployeeInfo) {...}

public void FireEmployee(Object EmployeeObjectOrEmployeeID) {...}

• Più operatori ternari uniti insieme, quindi invece di assomigliare a un if...elseblocco, diventa un if...else if...[...]...elseblocco
• Nomi variabili lunghi senza sottolineatura o CamelCasing. Esempio da un codice che ho estratto:$lesseeloginaccountservice
• Centinaia di righe di codice in un file, con pochi o nessun commento, e il codice è molto ovvio
• ifDichiarazioni eccessivamente complicate . Esempio dal codice: a if (!($lessee_obj instanceof Lessee && $lessee_obj != NULL))cui mi sono concentratoif ($lessee_obj == null)

Odore di codice: non seguire le migliori pratiche

Questo genere di cose mi preoccupa sempre perché c'è quel vero che tutti pensano di essere un guidatore sopra la media.

Ecco un lampo di notizie per te: il 50% della popolazione mondiale è al di sotto della media dell'intelligence. Ok, quindi alcune persone avrebbero un'intelligenza esattamente nella media, ma non facciamoci schizzinosi. Inoltre, uno degli effetti collaterali della stupidità è che non puoi riconoscere la tua stessa stupidità! Le cose non sembrano così belle se si combinano queste affermazioni.

Quali cose suonano all'istante quando suona il codice?

Sono state menzionate molte cose positive e in generale sembra che non seguire le migliori pratiche sia un odore di codice.

Le migliori pratiche di solito non vengono inventate in modo casuale e spesso sono lì per un motivo. Molte volte può essere soggettivo, ma nella mia esperienza sono per lo più giustificati. Seguire le migliori pratiche non dovrebbe essere un problema, e se ti stai chiedendo perché sono come sono, cercalo piuttosto che ignorarlo e / o lamentarti di questo - forse è giustificato, forse no.

Un esempio di una buona pratica potrebbe essere l'uso dei ricci con ogni if-block, anche se contiene solo una riga:

if (something) {
    // whatever
}

Potresti non pensare che sia necessario, ma di recente ho letto che è una delle principali fonti di bug. Sempre utilizzando le parentesi sono stati discussi anche su Stack Overflow e verificare che le istruzioni if ​​abbiano parentesi è anche una regola in PMD , un analizzatore di codice statico per Java.

Ricorda: "Perché è la migliore pratica" non è mai una risposta accettabile alla domanda "perché lo stai facendo?" Se non riesci a capire perché qualcosa è una buona pratica, allora non è una buona pratica, è una superstizione.

Commenti che dicono "questo perché il design del sottosistema Froz è totalmente interrotto".

Questo va avanti per un intero paragrafo.

Spiegano che deve avvenire il seguente refattore.

Ma non l'ha fatto.

Ora, avrebbero potuto dirgli che non potevano cambiarlo dal loro capo in quel momento, a causa di problemi di tempo o di competenza, ma forse era perché le persone erano meschine.

Se un supervisore pensa che j.random. il programmatore non può fare un refactoring, quindi il supervisore dovrebbe farlo.

Ad ogni modo ciò accade, so che il codice è stato scritto da una squadra divisa, con possibili politiche di potere, e non hanno riformattato i progetti del sottosistema corrotto.

Storia vera. Potrebbe succedere a te.

Qualcuno può pensare a un esempio in cui il codice dovrebbe legittimamente fare riferimento a un file in base al percorso assoluto?

Catturare le eccezioni generali:

try {

 ...

} catch {
}

o

try {

 ...

} catch (Exception ex) {
}

Uso eccessivo della regione

In genere, l'utilizzo di troppe regioni mi indica che le tue classi sono troppo grandi. È un flag di avvertimento che segnala che dovrei indagare di più su quel bit di codice.

Convenzioni di denominazione delle classi che dimostrano una scarsa comprensione dell'astrazione che stanno tentando di creare. O che non definisce affatto un'astrazione.

Un esempio estremo viene in mente in una classe VB che ho visto una volta che era intitolata Dataed era lunga più di 30.000 righe ... nel primo file. Era una classe parziale suddivisa in almeno mezza dozzina di altri file. La maggior parte dei metodi erano wrapper attorno a proc memorizzati con nomi come FindXByYWithZ().

Anche con esempi meno drammatici, sono sicuro che abbiamo appena "scaricato" la logica in una classe mal concepita, dato che ha un titolo del tutto generico, e se ne è pentita in seguito.

Funzioni che reimplementano le funzionalità di base della lingua. Ad esempio, se vedi mai un metodo "getStringLength ()" in JavaScript anziché una chiamata alla proprietà ".length" di una stringa, sai che sei nei guai.

#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...
#define ...

Naturalmente senza alcun tipo di documentazione e l'occasionale nidificato #defines