- Documentation
- Getting Started
- JArchitect Analysis
- JArchitect Plugin for Sonar
- Code Rule and Query
- JArchitect Features
- Build Process Integration
- Code Metrics Definitions
- Code Coverage FAQ
- Trend Monitoring
Rich Code Search Facilities
Introduction
What the tremendous success of Google told us is that being able to find the right information quickly is essential. Here both Time spent searching and Relevancy of the result found are the important assets.
We, developers, spend a significant amount of time searching code elements in our code base. Every developer tools, come with some sort of search criteria. So let's focus on what makes the JArchitect’s Code Rich Searching Experience unique.
Contrary to other tools, JArchitect Code Search supports numerous criterias including Searching by Name, Size, Complexity, Coupling, Popularity, Coverage, Visibility, Mutability, Purity, Change and Coverage of Changes. Let's begin with what is certainly the most used criteria for searching in a code base, Search by Name.
Search by Name
-
Suppose one wants to search a method that contain the keyword "asc" in the name but doesn’t remember where it is.
The first step is searching for methods whose names include the sub-string "asc":
- The asc keyword is highlighted in method result. This helps to spot more quickly the searched code element(s).
- Method can be grouped by declaring project/package/type. This make the search much more efficient because in the general case, we have a clue of where the method searched should be declared.
- Under the hood, the search is based on the CQLinq Query below, generated from the user inputs.
from m in Methods
where m.NameLike (@"asc")
select new { m, m.NbLinesOfCode }
Several things to notice here:
Performance of Search
Something that cannot be shown on screenshots is that JArchitect search is fast, very fast: for example matching the 117.618 methods of the JVM that contain an "a" in the name is immediate.
Multi Regex Support
Let’s refine our search criteria. Suppose that the method to find, is a click event handler for a cancel button. Notice now the CQLinq Query generated that contains 2 NameLike clauses:
from m in Methods
where m.NameLike (@"get") &&
m.NameLike (@"as")
select new { m, m.NbLinesOfCode }
More generally the CQLinq condition NameLike can be parameterized with any regular expression. You suddenly remember that your method should begin with "get", upper case. Just click the lower case tick box and suffix your regex with ^, which means in regex terms begin with:
Search Tier Code by Name
The search can also easily include tier code elements. Clicking the Include Third-Party tickbox has for effect to discard the !IsThirdParty CQLinq restrictive condition.
Search on Full Name
Also, you can extend the search to the full name. In other words, one can match any method whose name, type or package contains "get".
Refining Search by Name with CQLinq
And because all this is based on CQLinq, you can easily edit the CQLinq Query generated and refine it at whim, like for example, to match static methods with "get" in the name.
Search by other Criterias than Name
It is possible to search for methods, fields, types, packages and projects according to many other criterias than name. Keep in mind that in any case, all JArchitect searching facilities are actually some CQLinq queries generator. So all the search criterias supported target particular CQLinq clauses.
Search by Size
It is possible to search for methods, types, packages and projects according to their size. The size if measured with the metric Lines of Code. If this metric is not available, the metric number of IL instructions is chosen.
Search by Complexity
It is possible to search for methods, types, packages and projects according to their complexity. The size if measured with the metric source file Cyclomatic Complexity. If this metric is not available, the metric IL Cyclomatic Complexity is chosen.
Search Coupling in Code
It is possible to search for code elements according to their coupling. The Afferent Coupling metric value of a code element X represents the number of code elements users of X. The Efferent Coupling metric value of a code element X represents the number of code elements used by X.
Typically high Afferent Coupling indicates a popular code element. A high Efferent Coupling indicates a god code element, meaning a code element that has intimate knowledge of a large portion of the code base. Hence, a too high Efferent Coupling value for a type or a method should be considered as a code smell.
Search by Popularity
It is possible to search for types and methods according to their popularity. The popularity of a code elements is computed according to the Ranking metric (the same metric originally used by Google to compute page rank).
Search by Visibility
It is useful to search methods, fields or types according to their level visibility (private, protected, internal, internal protected, public). As shown in the screenshot, it is also possible to also ask for code elements that could have a more restrictive level of visibility. For example, if a method is tagged as CouldBePrivate by JArchitect, it means that it is not declared as private and, in the context of the application it is only used inside its declaring type.
Search by Immutability / Purity
It is possible to search for immutable types and fields, and pure methods.
Search in Diff between two versions of the code
It is possible to search for Diff between 2 snapshots of the code base. This possibility is described in the section Advanced Code Diff with JArchitect.
