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, including Visual Studio, come with some sort of search criteria. So let's focus on what makes the NDepend’s Code Rich Searching Experience unique.

Contrary to other tools, NDepend 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
    In Visual Studio, the two shortcuts Alt+M and Alt+C can be used to search Methods or Classes by name.

    Suppose one wants to search a click handler method but doesn’t remember where it is. The first step is searching for methods whose names include the sub-string "Click":



    Several things to notice here:
    • The Click keyword is highlighted in method result. This helps to spot more quickly the searched code element(s).
    • Method can be grouped by declaring assembly/namespace/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 (@"Click") 
      select new { m, m.NbLinesOfCode }




    Performance of Search

    Something that cannot be shown on screenshots is that NDepend search is fast, very fast: for example matching the 388.746 methods of the .NET Framework v4.0 that contain an "e" 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 (@"Click") && 
          
    m.NameLike (@"Cancel") 
    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 "Cancel", 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 namespace contains "Click". For example, all methods declared in a class named like ToolClickedEventArg, are now matched.






    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 "Click" in the name.








Search by other Criterias than Name

It is possible to search for methods, fields, types, namespaces and assemblies according to many other criterias than name. Keep in mind that in any case, all NDepend 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, namespaces and assemblies according to their size. The size if measured with the metric Lines of Code. If this metric is not available (because PDB files were not available at analysis time) the metric number of IL instructions is chosen.








    Search by Complexity

    It is possible to search for methods, types, namespaces and assemblies according to their complexity. The size if measured with the metric source file Cyclomatic Complexity. If this metric is not available (because PDB files or source files were not available at analysis time) 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. More details on this topic can be found in Code metrics on Coupling, Dead Code, Design flaws and Re-engineering.








    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 NDepend, 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. More about this topic can be found in he article Immutable types: understand their benefits and use them.








    Search by Code Coverage Ratio by Tests

    It is possible to search for methods, types, namespaces and assemblies according the ratio of their coverage by tests. Code coverage data are extracted from results produced by dedicated third party tools as explained in the Coverage FAQ section.








    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 NDepend.








    Search by Code Coverage by Tests of Diff

    It is possible to search for refactored or new code elements not properly covered by tests. This possibility is especially useful for team who care for code coverage. Here the following code query is generated:
    from m in Application.Methods 
    where m.CodeWasChanged() && m.PercentageCoverage < 100 
    orderby m.PercentageCoverage descending, 
            
    m.NbLinesOfCodeCovered, 
            
    m.NbLinesOfCodeNotCovered, 
            
    m.NbLinesOfCode 
    select new { m, m.PercentageCoverage, 
                 
    m.NbLinesOfCodeCovered,               
                 
    m.NbLinesOfCodeNotCovered, 
                 
    m.NbLinesOfCode }
    More details can be found in the article Are you sure your added and refactored code is covered by tests?.