4 results found
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
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
Add Color to the Treemap Metric Panel to be able to observe a second metric on the treemap.4 votes
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
- Don't see your idea?