# Nicht aufgerufene Methoden in Eclipse ermitteln



## Sniper (10. Aug 2008)

Hallo liebe Community,

ich habe ein großes Projekt in Eclipse entwickelt. Nun möchte eine Refactoring durchführen. Meine Frage ist, wie ich nicht aufgerufene Methoden in Eclipse ermitteln kann? Gibt es ein Tool dafür?

Gruss,
Sniper


----------



## maki (10. Aug 2008)

Ich nutze Cobertura, um die Coverage vo Unittests zu ermitteln.
EMMA soll auch gut sein.


----------



## Sniper (10. Aug 2008)

Hallo,
vielen Dank für deine Antwort. Gibt es in Eclipse kein Tool dafür?

Gruss,
Sniper


----------



## maki (10. Aug 2008)

Es gibt Maven2 Plugins für beide, ob es eines für Eclipse gibt weiss ich nicht.


----------



## kama (10. Aug 2008)

Hallo,

schau Dir das mal an:

http://www.ucdetector.org/

MfG
Karl Heinz Marbaise


----------



## Guest (10. Aug 2008)

http://www.eclemma.org
Funktioniert auch einwandfrei mit Ganymede.


----------



## Sniper (10. Aug 2008)

vielen Dank für die Antworten. Es sind Tools, die ich benötigt habe.

Gruss,
Sniper


----------



## Guest (29. Aug 2008)

Anonymous hat gesagt.:
			
		

> http://www.eclemma.org
> Funktioniert auch einwandfrei mit Ganymede.



Das ist falsch: Mit Eclemma findet man keinen unnötigen Code.
Richtig ist: Man kann Methoden finden, die nicht durch die JUnit Tests aufgerufen werden. Das ist aber was anderes.

http://www.ucdetector.org/ dagegen findet Code, der nicht referenziert wird.


----------



## maki (29. Aug 2008)

> http://www.ucdetector.org/ dagegen findet Code, der nicht referenziert wird.


Code der nicht referenziert wird ist nicht unbedingt ungenutzt, man denke an Reflection und DI.


----------



## ARadauer (29. Aug 2008)

ja klar steht aber auch auf der homepage



> Limitations
> The problems found by UCDetector, are only suggestions.
> Before deleting or changing your code you should really know what you are doing!
> If UCDetector tells you, that there are no references of your class, method or field your code still may be used by:
> ...


----------



## maki (29. Aug 2008)

Das macht das Ding in größeren Projekten(und wo sonst sollte man nach Dead Code suchen???) nutzlos


----------



## SlaterB (29. Aug 2008)

nutzlos ist übertrieben,
normalerweise weiß man doch etwas Bescheid, auf welche Teile der Applikation über DI oder Reflection zugriffen werden,
idealerweise sind das ja wohldefinierte vorgeschaltete Klassen/ haben besondere Namen/ packages oder so,
z.B. die Menge aller Hibernate-Beans,

während andere ganz deutlich eine andere Aufgabe/ einen anderen Zugriff haben,
etwa die Logik/ Berechnungsklassen


----------



## Murray (29. Aug 2008)

Und wie sollte man auch anders nach unbenutztem Code suchen können? Wenn man davon ausgehen muss, dass es noch (Fremd-)Code gibt, den man  bei der Analyse nicht berücksichtigen kann oder wenn man damit rechnen muss, dass per Reflection auf den Code zugegriffen wird, dann kann es da wohl keine sichere Lösung geben.


----------



## maki (29. Aug 2008)

Murray hat gesagt.:
			
		

> Und wie sollte man auch anders nach unbenutztem Code suchen können? Wenn man davon ausgehen muss, dass es noch (Fremd-)Code gibt, den man  bei der Analyse nicht berücksichtigen kann oder wenn man damit rechnen muss, dass per Reflection auf den Code zugegriffen wird, dann kann es da wohl keine sichere Lösung geben.


Man nimmt eben EMMA oder Cobertura, um die Coverage von Tests zu ermitteln,* eben dass was wirklich aufgerufen/durchlaufen wird*.
Es soll Wege geben diese Tools auf nicht-Tests laufen zu lassen, waren mir aber zu Komplex.


----------



## Murray (29. Aug 2008)

maki hat gesagt.:
			
		

> Man nimmt eben EMMA oder Cobertura, um die Coverage von Tests zu ermitteln,* eben dass was wirklich aufgerufen/durchlaufen wird*.
> Es soll Wege geben diese Tools auf nicht-Tests laufen zu lassen, waren mir aber zu Komplex.


wie auch immer diese Tools funktionieren: entweder arbeiten sie durch Analyse der Sourcen, oder sie protokollieren irgendwie mit, welche Code-Teile in einem echten Programmlauf aufgerufen werden. Ersteres funktioniert nicht, wo andere Referenzen als direkte Aufrufe verwendet werden (Reflection) oder wo Fremdcode nicht analysiert werden kann, letzteres setzt voraus, dass der Programmablauf, der protokolliert wird, eben alles umfasst, was in der Praxis vorkommt - und um das zu garantieren, müsste man also schon wissen, was der "dead code" ist.


----------



## maki (29. Aug 2008)

Mit EMMA sollte es die Möglichkeit geben, Code zu instrumewntieren und diesen dann auf einen Testserver zum laufen zu bringen, nachdem man alle möglichen Anwendungsfälle durchgespielt hat, sollte man sehen was gar nicht mehr benutzt wird.

Soweit meine Theorie, war mir dann aber zu umständlich umzusetzen, speziell der Teil "nachdem man alle möglichen Anwendungsfälle durchgespielt hat" hört sich nicht so prickelnd an.


----------



## Gast (29. Aug 2008)

Clover: Coverage von Unittests

http://www.atlassian.com/software/clover


----------



## spj (19. Sep 2008)

Sniper hat gesagt.:
			
		

> ICH habe ein großes Projekt in Eclipse entwickelt.


Für das hier beschriebene Szenario scheint mir UCDetector das Richtige zu sein, da der Programmierer seinen Code kennt. Das heisst, er weiss wahrscheinlich:
 - welcher Code per Reflection aufgerufen wird
 - welcher API Code von "ausserhalb" aufgerufen wird

Zum Thema Reflection bietet UCDetector immerhin:
 - Volltextsuche nach voll qualifizierten Klassennamen
 - Filter für Klassen/Methoden/Feld Namen
 - Filter für Bean Methoden
Das löst das Reflection Problem natürlich nicht vollständig.

Ein Schwachpunkt von EMMA ist, dass Testcode vorhanden sein MUSS, was nicht immer gegeben ist.

Mit UCDetector kann man sofort loslegen.


----------



## Tobias (19. Sep 2008)

Ich könnte mir eine Lösung mit AspectJ vorstellen ... Hab's allerdings nicht ausprobiert. Sowas wie:


```
aspect CodeUnusedTest {
    declare error : !(execution(*..*.*(..)) : "Methode wird nicht benutzt";
}
```

mpG
Tobias


----------

