A múltkori bejegyzésben átismételtük az XPath alapú szabályok alapjait, most pedig nézzünk meg néhány egyszerű gyakorlati példát a kód ellenőrző plugin-ok fejlesztésre.
Általános esetben érdemes elkerülni a java.sql.Statement használatát, helyette pedig a java.sql.PreparedStatement paraméter binding-gal való alkalmazása javasolt. XPath alapú szabállyal megfogalmazva ez a következőként nézne ki:
//ClassOrInterfaceType[@Image='java.sql.Statement' or @Image='Statement']
A fenti kifejezéssel minden olyan osztály és interface típusú deklaráció kijelzésre kerül, aminek a neve Statement vagy java.sql.Statement. Érdemes megemlíteni, hogy a csomagnévvel specifikált nevet és az egyszerű osztálynevet is definiálni kell a szabályban, mivel a fejlesztők mindkét verziót használhatják a forráskódban! A szabállyal azonban probléma jelentkezhet abban az esetben, ha a kódbázisban egy saját Statement osztály is használatban van, mivel erre is illeszkedne a szabály második feltétele. Megoldásként az előbbi szabályt érdemes kibővíteni az import deklarációkra vonatkozó megkötésekkel:
or /ImportDeclaration/Name[@Image='java.sql'])]
Az SQL query-k készítésekor érdemes előre megadni az oszlopneveket, így a lekérdezések végrehajtásakor valóban csak azok az adatok kerülnek át a klienshez amire szükség is lesz. A szabály megsértését az alábbi XPath alapú kifejezéssel tudnánk kijelezni:
//Expression[descendant::Literal[contains(upper-case(@Image), 'SELECT')]
and descendant::Literal[contains(@Image, '*') ]]
Ez a kifejezés minden olyan string-re illeszkedik akár összefűzésen keresztül is, ahol a select és a * literálok is szerepelnek. Mivel nem lehetünk biztosak abban, hogy a kódban a select betűit kis vagy nagy betűsen, netán vegyesen adták meg, ezért az upper-case() XPath függvénnyel nagybetűsre alakítjuk a vizsgálat előtt.
A folytatásban pedig egy összetettebb példát fogunk megnézni.
Statement használatának a kijelzése
Általános esetben érdemes elkerülni a java.sql.Statement használatát, helyette pedig a java.sql.PreparedStatement paraméter binding-gal való alkalmazása javasolt. XPath alapú szabállyal megfogalmazva ez a következőként nézne ki:
//ClassOrInterfaceType[@Image='java.sql.Statement' or @Image='Statement']
A fenti kifejezéssel minden olyan osztály és interface típusú deklaráció kijelzésre kerül, aminek a neve Statement vagy java.sql.Statement. Érdemes megemlíteni, hogy a csomagnévvel specifikált nevet és az egyszerű osztálynevet is definiálni kell a szabályban, mivel a fejlesztők mindkét verziót használhatják a forráskódban! A szabállyal azonban probléma jelentkezhet abban az esetben, ha a kódbázisban egy saját Statement osztály is használatban van, mivel erre is illeszkedne a szabály második feltétele. Megoldásként az előbbi szabályt érdemes kibővíteni az import deklarációkra vonatkozó megkötésekkel:
//ClassOrInterfaceType[(@Image='Statement' or @Image='java.sql.Statement')
and (/ImportDeclaration/Name[@Image='java.sql.Statement'] or /ImportDeclaration/Name[@Image='java.sql'])]
SELECT * jellegű lekérdezések kijelzése
Az SQL query-k készítésekor érdemes előre megadni az oszlopneveket, így a lekérdezések végrehajtásakor valóban csak azok az adatok kerülnek át a klienshez amire szükség is lesz. A szabály megsértését az alábbi XPath alapú kifejezéssel tudnánk kijelezni:
//Expression[descendant::Literal[contains(upper-case(@Image), 'SELECT')]
and descendant::Literal[contains(@Image, '*') ]]
Ez a kifejezés minden olyan string-re illeszkedik akár összefűzésen keresztül is, ahol a select és a * literálok is szerepelnek. Mivel nem lehetünk biztosak abban, hogy a kódban a select betűit kis vagy nagy betűsen, netán vegyesen adták meg, ezért az upper-case() XPath függvénnyel nagybetűsre alakítjuk a vizsgálat előtt.
A folytatásban pedig egy összetettebb példát fogunk megnézni.
Nincsenek megjegyzések:
Megjegyzés küldése
Megjegyzés: Megjegyzéseket csak a blog tagjai írhatnak a blogba.