Suchen Sie in Eclipse nach auskommentiertem Code für alle Dateien

@Jorn sagte:

  

Ich denke, [ das OP ] möchte Code finden, der auskommentiert ist, nicht Code, der einen Kommentar hat.

Wenn die Absicht darin besteht, auskommentierten Code zu finden, dann glaube ich nicht, dass es generell möglich ist. Das Problem ist, dass es unmöglich ist, zwischen Kommentaren, die als Code oder Pseudo-Code geschrieben wurden, und Code, der auskommentiert wird, zu unterscheiden. Diese Unterscheidung erfordert menschliche Intelligenz.

Jetzt haben IDEs normalerweise eine "toggle comments" Funktion, die den Code auf eine bestimmte Art und Weise kommentiert. Es wäre möglich, ein Werkzeug / Plugin zu schreiben, das dem von a bestimmte IDE. Aber das ist wahrscheinlich nicht gut genug, vor allem, da die Neuformatierung des Codes normalerweise die Eigenschaften beseitigt, die den auskommentierten Code erkennbar gemacht haben.

Wenn das Problem darin besteht, auskommentierten Code zu finden, ist es eine Möglichkeit, Kommentare zu finden und zu entscheiden, ob ein Kommentar Code enthalten kann.

Ein einfacher Weg dies zu tun, ist nach einem Kommentar zu suchen, der Code-ähnliche Dinge enthält. Ich wäre versucht, nach Kommentaren zu suchen, die ein ";" enthalten. Zeichen (oder ein anderer seltener Indikator wie "="); es wird ziemlich schwierig sein, irgendeinen interessanten kommentierten Code zu haben, der das nicht enthält und in meiner Erfahrung mit Kommentaren sehe ich nicht viele, die Leute schreiben, die das enthalten. Eine Regexp-Suche nach dieser sollte ziemlich einfach sein, selbst wenn sie einige zusätzliche falsche Positive (z.B. // in einem String-Literal) auffing.

Ein ausgefeilterer Weg, dies zu erreichen, ist die Verwendung eines Java-Lexers oder -Parsers. Wenn Sie einen Lexer haben, der Kommentare an Token zurückgibt (nicht alle von ihnen, Java-Compiler sind nicht an Kommentaren interessiert), dann können Sie einfach die Lexeme nach einem Kommentar durchsuchen und die Semikolonprüfung durchführen, die ich oben beschrieben habe. Sie werden mit diesem Ansatz keine falschen positiven Treffer für Kommentare wie in String-Literalen erhalten.

Wenn Sie einen Re-Engineering-Parser haben , der Kommentare als Teil des AST erfasst (wie z. B. unsere SD Java-Frontend ), Sie können den Syntaxbaum mechanisch nach Kommentaren durchsuchen und den Kommentarkontext an den Parser zurückgeben um zu sehen, ob der Inhalt Code-ähnlich ist, und jeden Bericht zu melden, der diesen Test modulo einer größenabhängigen Fehlerrate übergibt (10 Fehler in 15 Zeichen bedeutet "ist wirklich ein Kommentar"). Jetzt erfordert der "Code-like" Test Der Reengineering-Parser ist bereit, einen beliebigen Teilstring der (Java) Sprache zu erkennen. Unser DMS-Software-Reengineering-Toolkit , das dem Java-Frontend zugrunde liegt, kann dies tatsächlich tun, indem es den Zugriff auf die vergrabene Grammatik nutzt in der Front-End, wie es bereit ist, eine Analyse für jede Sprache (nicht) Terminal zu starten, und diese Frage ist "Können Sie eine Folge von (Nicht-) Terminals finden, die die Zeichenfolge verbrauchen?".

Die Ansätze für Lexer und Parser sind kleine und große Vorschlaghämmer. Wenn OP dies nur einmal tun wird, kann er sich an die manuelle Regex-Suche halten. Wenn das Problem darin besteht, die Codebasis wiederholt zu überprüfen (in großen Organisationen erforderlich), möchte er ein Tool, das regelmäßig ausgeführt werden kann.