Errori stimati nel confronto dell'implementazione

1

Ho lavorato sul miglioramento di una libreria esistente per essere più manutenibile dopo aver tentato di implementare una funzione che volevo e ho trovato che il codice era difficile da modificare.

La libreria è un plugin grunt node.js chiamato grunt-contrib-jshint e la mia implementazione è in repo chiamato grunt-jshint-bfs .

Ho eseguito uno strumento di analisi del codice chiamato plato che genera un rapporto di analisi di origine che include la linea di metriche totale / media linee di codice, manutenibilità e errori stimati nel tentativo di confrontare le basi del codice per scopi di qualità del codice.

Il problema che sto avendo è quello di confrontare gli errori stimati tra i due progetti, dal momento che uno ha 2 file e l'altro ha molti più file sembrerebbe che l'esposizione agli errori aumenterebbe, o sto leggendo che sbagliato?

Questo è un link a rapporto del mio repository e < a href="https://dl.dropboxusercontent.com/u/9590085/plato/grunt-contrib-jshint/index.html"> rapporto grunt-contrib-jshint per il confronto.

    
posta Jacob 18.04.2013 - 18:44
fonte

1 risposta

1

Penso che tu stia leggendo male. Basandosi sulla lettura dei due rapporti, sembra che Platone deduca un valore di errore stimato dalla lunghezza e dalla complessità del codice. Funzioni più lunghe e complesse tendono ad avere valori di errore stimati più elevati. Sfortunatamente, Platone non fornisce alcuna documentazione (che io possa trovare) per i suoi algoritmi e approcci, a meno del codice sorgente stesso, e un paio di menzioni del complessità e lint librerie che utilizza. Questo mi dice che non è uno strumento serio, anche se i suoi rapporti sembrano grandiosi.

La distribuzione delle funzioni su più file (senza modificare le funzioni stesse) non dovrebbe fare alcuna differenza rispetto alla stima dell'errore totale. Plato, tuttavia, sembra preferire file di origine più brevi, quindi renderà più felice lo strumento spostando le funzioni su più file. Questa non è una grande giustificazione per farlo, IMO. È anche un peccato che Platone fornisca così pochi totali a livello di progetto per le varie metriche che genera. La divisione della fonte in file è arbitraria, ma i totali su tutti i file sono ciò che conta.

Come confronto, ecco il report di Platone su jquery di Platone. Mostra valori di errore stimati ben superiori a 1 per molti file. Questo significa che jquery (che viene utilizzato in una parte significativa delle pagine Web esistenti in questi giorni) ha molti errori? Ne dubito. Jquery, a causa del suo uso intensivo, è anche pesantemente testato, e probabilmente quasi privo di errori.

Penso che dovresti prendere i risultati di Platone con un pizzico di sale. Utilizza alcuni strumenti di analisi statica (e non particolarmente sofisticati, IMO) e misurazioni di massa che non sono buoni parametri per lo stile di codifica e la qualità di progettazione. Invece ti consiglio di fidarti del tuo intuito sulla qualità del codice e sviluppare il tuo senso di odori di codice [ Wikipedia , Jeff Atwood ].

E infine, ricorda che mentre la riduzione della complessità è un obiettivo degno, alcuni codici devono semplicemente essere complessi. Diluire artificialmente la complessità naturale (forse da molti strati di subroutine) può renderlo illeggibile da altri programmatori. Scrivi un buon commento e affidati ai tuoi colleghi per gestire qualcosa di un po 'difficile.

    
risposta data 19.04.2013 - 01:30
fonte

Leggi altre domande sui tag