rf-5 - Szegedi Tudományegyetem

Download Report

Transcript rf-5 - Szegedi Tudományegyetem

Kód auditálás

© Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

N éhány fontos infó…

  Jövő héten ZH!!

 mindenki a saját gyakorlatán írja   20 pont – 20 perc kb. 10 kiskérdés előadás és gyakorlat anyagból!

Jövő hét végén M1!!

 az SVN csúszása miatt a határidő kitolva:  március 13. 24:00-ig  a leadandó anyagról részletes leírás: http://www.inf.u-szeged.hu/~ncsaba/rf21011II/rf2 2011-projektek.pdf

 a készítendő dokumentumot határidőre az SVN sajátprojekt/doc mappában kell elhelyezni!

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

Automatikus kód auditálás

       Forráskód elemzése külső szoftverrel Szabályok alapján szintaktikailag és szemantikailag Szabálygyűjtemények használata   Hivatalos ajánlások (pl. Sun coding convention, Microsoft) Saját szabályok (ill. hivatalosak módosított verziói) Egy adott szabálygyűjtemény szerinti elemzés Ha nem felel meg valamelyik szabálynak: hibajelzés  Mi a hiba, hol található Riportok és statisztikák készíthetőek Legtöbb automatikusan futtatható (automatic build), hiba esetén fejlesztők értesítése (notification) Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

CheckStyle

      http://checkstyle.sourceforge.net/ Statikus kódelemzés Java forráskódhoz Szabálysémákat (checks) definiál, amik testre szabhatóak  XML alapú leírás A szabályokat gyűjteménybe lehet rendezni (configuration file) Van saját szabályszerkesztője (+Eclipse alatt is) Integrálható ant-tal és az ismert IDE környezetekkel   Eclipse plugin site: http://eclipse-cs.sourceforge.net/update Ant task ként is futtatható Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

CheckStyle – checks

  Standard checks gyűjtemény:  Javadoc Comments, Naming conventions, Imports, Size Violations, Whitespace, Modifiers, Blocks, Coding Problems, Class Design, Duplicates, Metrics, Miscellaneous Paraméterezés:  XML ben ill. külön eszközökkel finomhangolható szabályok  pl. maximális sorméret NNN. darab karakter   Severity: error, warning, info, ignore  Beállítható, hogy egy szabályt mennyire veszünk súlyosnak Szabályok megtekintése Eclipse-ben:   Windows | Preferences | Checkstyle Properties a kívánt gyűjteményen, szabályok böngészhetők Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

CheckStyle futtatása

 Parancssorból     java -jar checkstyle-all-4.4.jar -c checkstyle_rules.xml Dummy.java  egy forrásfájlra, adott szabályokkal … -r src  rekurzívan az src mappában, eredmény konzolra … -o audit_result.txt  eredmény szövegfájlba … -o audit.xml -f xml  eredmény XML formátumban (bővebb)  Eclipseből (plugin telepítése szükséges)    Jobb klikk fájlon, csomagon, projekten  Check code with Checkstyle Checkstyle  Window | Show View | Other… | Checkstyle violations Automatikus ellenőrzés: Activate/Deactivate Checkstyle (elérése: projekten jobb klikk  Checkstyle) Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

PMD

       http://pmd.sourceforge.net/ Alternatíva Checkstyle mellé, hasonló szabályok Együtt is használják a kettőt, bár vannak átfedések XML alapú szabálygyűjtemény (ruleset)  Egy alap szabálygyűjteményt definiálnak a készítők is, ez a futtatható csomag része Az alapvető szabályok mellett van támogatás egyéb technológiákra is (pl.: JSP, JSF, JUnit…) Új szabályok írhatóak Javában és/vagy XPath-val Eclipse be szintén pluginként telepíthető  Update site: http://pmd.sf.net/eclipse Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

PMD – szabályok

 Alapvető szabálycsoportok:   Basic, Braces, Clone, Code size, Controversal, Coupling, Design, Finalizer, Import, Javabean, JUnit, Java Logging, Naming, Optimization, Strict Exception, String and StringBuffer, Security, Type resolution, Unused code (…) Testre szabhatóak (paraméterekkel)  Severity: 1-2 ( error ), 3-4 ( warning ), 5 (info )    1: bug, kritikus hiba 2: potencionális bug, rossz, sérült kód 3: zavaró kód, bug-gyanús, javítása erősen ajánlott 4: jó ízlést sértő  5: „nice to have”  Eclipseben: Window | Preferences | PMD | Rules Configuration  Bővebb információ: „Edit rule…” gombbal Rendszerfejlesztés gyakorlat - © Raffai Tamás

PMD – futtatás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék    Parancssorból  java -jar pmd-4.2.3.jar F ORRÁS M APPA [ -reportfile R IPORT F ÁJL ] F ORMÁTUM S ZABÁLYOK   pl. java -jar pmd-4.2.3.jar test html pmd_rules.xml

Kimeneti formátumok: text, xml, html, nicehtml (-xslt) … Ant task ként is futtatható, automatizálható Eclipse-ben     Jobb klikk fájlon, csomagon, projekten  Code With PMD ill. Clear PMD Violations PMD  Check Automatikusan a PMD perspektíva nyílik meg (letiltható) Generate reports  több formátumban, fáljba írva Find suspect Cut and Paste  kód duplikáció (projekten) Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

StyleCop 4.3

     http://code.msdn.microsoft.com/sourceanalysis/Rele ase/ProjectReleases.aspx?ReleaseId=1425 Sokáig csak belső eszköz volt a Microsoftnál, nemrég adták ki a nagyközönségnek .NET források elemzése (jelenleg csak C#) Visual Studio ba beépülő eszköz (2005, 2008) Szabályok:  Severity: Error, Warning, Message    Documentation, Layout, Maintainablitity,Naming, Ordering, Readability, Spacing Egyedi azonosítójuk van, MSDN-en részletes leírások Kiválasztható, hogy melyik szabályokat vegye figyelembe Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

StyleCop – futtatás

   Visual Studioban egy solutionre:   Jobb klikk solutionre vagy projektre  Run StyleCop Eredmény az „Error List” ablakban (View | Error List) Részletes leírás egy konkrét hibáról:    Jobb klikk az Error List ablakban egy hibára Show Error Help  offline súgó megnyitása a hibáról Példák megoldásra, link MSDN cikkekre Visual Studio designere által generált kód ellenőrzésének kikapcsolása:    Projekten jobb klikk  StyleCop Settings | Rules „Analyze designer files” kikapcsolása „Analyze generated files” kikapcsolása Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

FxCop 1.36

   http://www.microsoft.com/downloads/ (freeware) .NET Assemblyk auditálására (.exe, .dll)  Önálló program, saját GUI vezérlőfelülettel Alapvető szabálycsoportok:   Design, Globalization, Interoperability, Mobility, Naming, Performance, Portability, Security, Usage Célszerű együtt használni a két eszközt     Severity: Critical Error, Error, Critical Warning, Warning, Information Certainty: mekkora a % os valószínűsége hogy tényleges hibáról van szó (inkább csak informális adat) Fix category: javítása milyen hatással van a programra (Breaking, Non Breaking, Depends On Fix) Szabály osztálykönyvtárak (.dll), írhatunk sajátot is Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

FxCop 1.36 – futtatás

  Futtatás:      Start Menu | Microsoft FxCop | Microsoft FxCop 1.36

Project létrehozása  Projects | Add Targets  assembly k hozzáadása (egyszerre több is lehet) Analyze: kódelemzés lefuttatása Az alsó ablakban részletes leírás a hibákról, közvetlen linkkel a forráskódra ill. az MSDN help-re Az aktuális projekt, elemzés elmenthető Célszerű kikapcsolni az ellenőrzést generált kódokra   Project | Options… | Spelling & Analysis „Suppress analysis results against generated code” mezőt bekapcsolni Rendszerfejlesztés gyakorlat - © Raffai Tamás

Szegedi Tudományegyetem – Szoftverfejlesztés Tanszék

Nem kell félni, fájni fog…

   A kód auditáló eszközök érzéseket sérthetnek   „Szép” megoldásokra is beszólhatnak (pl. x %= y|65534 & !z ? ~y : y^z) „Don’t shoot the messenger” – PMD mottó Szabályokat ki állítja fel? Ki módosíthatja?

 Céges szabályzatok a kódminőségről   Projektmenedzserek, vezető fejlesztők Megrendelői igények (főleg outsourcing esetén) Mikor módosítsunk egy szabályt?

 Ha két v. több szabály egymásnak ellentmond    Ha a megfelelés költsége túl nagy a haszonhoz képest Suppress: adott helyen egy szabály figyelmen kívül hagyása Nem szabad csak azért módosítani mert úgy kényelmesebb!

Rendszerfejlesztés gyakorlat - © Raffai Tamás