Skip to content

NDepend User Voice

Welcome to the NDepend User Voice page. Let us know what you would like to see in future versions of NDepend. This site is for suggestions and ideas. If you need to report a bug, please send us an email at support@ndepend.com

We look forward to hearing from you!

Thanks – Patrick Smacchia
NDepend Team

NDepend Users Voice

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

5 results found

  1. Support for X# source code analysis

    X# is an open source .Net language based on Roslyn. Its origin are Visual Objects, Visual FoxPro and finally xBase, Its under active development and used by thousands of developers in Europe and the US. It would be great if metrics based on the source code like comments and CC would be available for X# too.

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  Code Metrics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  2. Halstead metrics in NDepend

    I would like to strongly advise the implementation in NDepend, of Halstead metrics that are already available in CppDepend. I frequently used the CppDepend maintainability index and other economic metrics to justify important and strategic refactoring.

    I utilize other tools to measure the scope and monetary values of changes in C# code base. Yet, I apply other formulas, but without the same accuracy. To apply different formulas may induce contradictions that I must explain, which transform my project meetings almost to courses in software engineering metric and indicators.

    To hold the same metrics on both CppDepend and NDepend provides uniformity…

    38 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    1 comment  ·  Code Metrics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  3. Add code churn metrics from source control

    It would be extraordinarily useful to include code churn metrics from source control. This would be an extremely helpful metric to help decide what parts of the codebase a team should look to start cutting down complexity, dependencies, and other issues.

    I use code churn when it's available to help identify modules, classes, or methods that we should focus on. Items with high churn indicate they're getting touched a lot, which often indicates brittle sections of the codebase.

    Since this is totally dependent on each particular source control system, it would make sense to start with only one or two…

    27 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  Code Metrics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  4. NDepend should not consider exception catch() parameters as method variables

    NDepend's method variable count metric considers each exception catch statement to add another variable to the method's variable count. I can understand how those strictly would be considered function variables, but how is this helpful for code quality? Properly handling exceptions should not compete with keeping the method variable count low. Surely it is not bad practice to catch a number of specific exceptions. It seems like bad practice to create a separate wrapper function just to try/catch exceptions in the inner function. How would one refactor this to make it better?

    2 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  Code Metrics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close

  5. Add Color to the Treemap Metric Panel

    Add Color to the Treemap Metric Panel to be able to observe a second metric on the treemap.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    0 comments  ·  Code Metrics  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
  • Don't see your idea?

NDepend User Voice

Categories

Feedback and Knowledge Base

(thinking…)