Approcci per ridurre la complessità ciclomatica

Question

Approcci per ridurre la complessità ciclomatica

#1 da (6 voti)

4

Stavo eseguendo il nostro codice tramite JSHint, e ho deciso di passare i controlli contro la complessità ciclomatica, per poi proseguire con uno sprint a lungo refactoring. Un posto però mi ha sconcertato, ecco un frammento di codice:

var raf = null //raf stands for requestAnimationFrame

if (window.requestAnimationFrame) {
  raf = window.requestAnimationFrame;
} else if (window.webkitRequestAnimationFrame) {
  raf = window.webkitRequestAnimationFrame;
} else if (window.mozRequestAnimationFrame) {
  raf = window.mozRequestAnimationFrame;
} else if (window.msRequestAnimationFrame) {
  raf = window.msRequestAnimationFrame;
} else {
  raf = polyfillRequestAnimationFrame;
}

Non sorprendentemente, in questa implementazione CM è 5, il primo tentativo è stato quello di utilizzare la soluzione da MDN:

var requestAnimationFrame = window.requestAnimationFrame || window.mozRequestAnimationFrame ||
                          window.webkitRequestAnimationFrame || window.msRequestAnimationFrame;
window.requestAnimationFrame = requestAnimationFrame;

Che mi sembra semplicemente un trucco (sì, lo so, la maggior parte dei programmatori javascript a tempo pieno non sono d'accordo con me, tuttavia questo è un parere prevalente all'interno del nostro team). Scarabocchiando attorno al mio codice, ho trovato altri hack che potrei impiegare per il code-linter completo, tra quelli di cui ero fiero per circa 5 secondi c'era l'utilizzo delle comprensibilità degli array:

var rafs = [
             window.requestAnimationFrame,
             window.webkitRequestAnimationFrame,
             window.mozRequestAnimationFrame,
             window.msRequestAnimationFrame,
             polyfillRequestAnimationFrame
           ].filter(function (rafClosure) {
             return rafClosure !== null && rafClosure !== undefined;
           });
return rafs[0];

Tuttavia sono curioso di sapere se esiste una pratica più o meno standard di refactoring del codice di ramificazione lunga (che non è banale da ridurre)?

programming-practices javascript cyclomatic-complexity

posta David Sergey 04.04.2013 - 20:44

fonte

1 risposta

Leggi altre domande sui tag programming-practices javascript cyclomatic-complexity

Perché dovrei usare Control.Exception in Haskell? Quali di questi esempi di OOP dimostrano i concetti OOP corretti?

score 6 · Accepted Answer

Il primo campione è semplicemente sbagliato. Non è sbagliato in termini di risultato, ma lo stile è terribile. È ripetitivo e soggetto a errori. Il secondo esempio è in realtà il passo da compiere per ottenere il codice leggibile e ben scritto. Non è un hack. È solo un codice scritto male riscritto correttamente. Il fatto che riduca la complessità ciclomatica non mi sorprende, dato che ci sono meno operazioni (almeno nella fonte: sono abbastanza sicuro che ogni compilatore / interprete decente riscriverà il primo campione nel secondo in tutti i casi).

Il terzo campione è più complicato da leggere per i principianti che non hanno abbastanza pratica con gli array, con filtri, con chiusure, ecc. Personalmente, dato il secondo campione, eviterei il terzo. Tuttavia, la riduzione della complessità ciclomatica non è sorprendente nemmeno: stai migrando la complessità dal tuo codice al metodo filter .