Kódolási szabványok, kódmetrikák és a kódszerkezet vizsgálata
Statikus elemzésnél a forráskódot vagy más munkaterméket futtatás nélkül vizsgálunk, gyakran erre szolgáló eszközzel. Az eszköz jelezhet stíluseltérést, nem használt változót, összetett vezérlési szerkezetet, ismétlődő kódot vagy bizonyos gyanús adatfolyamokat. Ez gyors visszajelzés, de nem minden jelzés valódi hiba, és a jelzés hiánya sem igazolja a program helyességét.
A kölcsönző egy részletében a kölcsönzési korlátot ellenőrizzük. A követelmény „legfeljebb három aktív”. Az alábbi kódot érdemes szabály alapján olvasni: a feltétel mikor utasít el? A dinamikus teszt később a működést is ellenőrzi, különösen a határon és a mentés után.
function kolcsonoz(aktivDb, eszkozSzabad) {
if (aktivDb > 3 || !eszkozSzabad) return 'elutasítva';
return 'kiadva';
}A kódolási szabvány egységes névadást, tagolást, formázást, típushasználatot, hibakezelést és egyéb csapatszabályokat írhat elő. A linter például kiszűrheti a nem használt változót vagy a tiltott szerkezetet; a formatter egységesíti a sortörést és a behúzást. Egyes szabályok az olvashatóságot, mások a kockázatok korai felismerését szolgálják.
A jelzéseket súlyosság és kontextus szerint értékeljük. Egy elütött változónév fordítási hibát okozhat, míg egy eltérő idézőjel elsősorban konzisztencia kérdése. A hamis pozitív jelzésnél megindokolható a kivétel; a teljes figyelmeztetéslista válogatás nélküli elnémítása viszont elfedi a valódi problémát. Nem állíthatjuk, hogy minden kódbeli hibát megtalál egy eszköz.
A metrika mérhető jellemző, például kódméret, elágazások száma, ciklomatikus komplexitás, duplikáció vagy függvényhossz. Egy sok döntést tartalmazó függvényben több független útvonal lehet; emiatt nehezebb átlátni és célzott tesztekkel lefedni. A magas szám figyelmeztetés a felülvizsgálatra, önmagában nem bizonyít hibát, ahogy az alacsony sem garantál helyességet.
A ciklomatikus komplexitás egyszerű, egy belépési pontú kódrészletnél szemléletesen 1 plusz a független bináris döntési pontok száma. A tényleges eszközeredmény a nyelv és az összetett feltételek kezelésétől függhet. Az alábbi példában két külön if miatt legalább az alapútvonal és a két eltérő döntés vizsgálata indokolt; teljes útvonal-lefedettséghez az együttállásokat is mérlegelni kell.
function dij(alap, keses, diak) {
let osszeg = alap;
if (keses) osszeg += 500;
if (diak) osszeg *= 0.8;
return osszeg;
}A mélyen egymásba ágyazott feltételek, hosszú függvények és ismételt kódrészek megnehezítik a változtatást. Ha ugyanazt a kölcsönzési szabályt a webes felület és az API külön másolatban tartja, az egyik javítása után a másik eltérően viselkedhet. A duplikáció felismerése emiatt hasznos kiindulópont, de az összevonásról a működési és felelősségi határok ismeretében döntünk.
Adatfolyamra vonatkozó jelzés lehet egy érték használata inicializálás előtt vagy egy érték kiszámítása, amelyet sosem olvasnak ki. Statikus eszközök bizonyos útvonalakon tudnak következtetni, de a külső adatokkal és a futási környezettel kapcsolatos hibákhoz dinamikus ellenőrzés is kell. Az eszközjelzést tehát kategorizáljuk, utánajárunk, és tesztesettel erősítjük meg, ha a viselkedési hatás fontos.
Előbb oldd meg a feladatot, majd nyisd meg a segítséget és a mintamegoldást.
Az első kódrészletnél melyik aktivDb értéknél sérül a „legfeljebb három aktív” szabály? Milyen feltételre módosítanád a kódot?
A változó a művelet ELŐTTI aktív kölcsönzések száma.
aktivDb = 3 és szabad eszköz mellett a függvény kiadva értéket adna, így létrejönne a negyedik. Helyesen: if (aktivDb >= 3 || !eszkozSzabad) return 'elutasítva'. A 2 és 3 előállapotot külön dinamikus teszttel is ellenőrizni kell.
A linter három üzenetet ad: nem használt változó; eltérő behúzás; lehetséges inicializálatlan érték. Melyik milyen típusú kockázat, és mi a következő lépés?
Nem minden jelzés egyforma súlyú és egyik sem automatikusan bizonyított futási hiba.
Eltérő behúzás: főként stílus és olvashatóság, formatterrel egységesíthető. Nem használt változó: felesleges kód vagy félbehagyott logika jele lehet, vizsgálni kell. Lehetséges inicializálatlan érték: potenciális hibás útvonal, konkrét vezérlési úton ellenőrizni és tesztelni kell.
A dij függvényben két önálló if szerepel. Mekkora az egyszerű modell szerinti ciklomatikus komplexitás? Hány igaz/hamis kombinációt írj fel?
A komplexitás 1 + döntések; a kombinációk száma két bináris feltételnél 2×2.
Egyszerű modellben 1+2=3 a ciklomatikus komplexitás. Négy kombináció van: késés nem/diák nem; késés igen/diák nem; késés nem/diák igen; késés igen/diák igen. A 3 és 4 nem ugyanaz a mérőszám.
A webes felületen már >= 3 a korlát, az API-ban > 3 maradt. Mi a veszély, és milyen ellenőrzést javasolsz?
Az API felület megkerülésével is elérhető lehet.
A két helyen eltérő szabály inkonzisztens: közvetlen API-hívással a negyedik kölcsönzés létrejöhet. A szabályt a megfelelő szerveroldali helyen érvényesítjük, a duplikációt megvizsgáljuk, majd az API- és felületi 2→3, 3→4 eseteket újrateszteljük.
Mennyire volt hasznos? Az értékelést és a megjegyzést csak a tanár látja.