-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise rules and being to add meta data #200
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #200 +/- ##
==========================================
+ Coverage 75.21% 75.81% +0.60%
==========================================
Files 70 70
Lines 2606 2729 +123
Branches 317 317
==========================================
+ Hits 1960 2069 +109
- Misses 564 578 +14
Partials 82 82 ☔ View full report in Codecov by Sentry. |
|
||
Each component registered with the dependency injection container should have exactly one public constructor. Having multiple public constructors leads to ambiguity in dependency resolution and makes the codebase harder to maintain. | ||
|
||
This is a blocker rule - any component with multiple public constructors should be refactored to have only one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this callout for being "a blocker rule" mean, and is it important? Is it related to severity somehow? Ppl can override it anyway, no?
- Refactoring the code to better expose the behavior through public methods | ||
- Rethinking the design to avoid the need to test internals | ||
|
||
### Don't ❌ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we unify? Either use the cute icons, or not - for every doc (13 and before don't seem to have it)?
|
||
private static Dictionary<string, string> _props = new Dictionary<string, string>() | ||
{ | ||
{ AnalyzerConstants.KEY_TECH_DEBT_IN_MINUTES, "10" } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think some of these estimates are very optimistic :)
@@ -1,4 +1,5 @@ | |||
using System.Collections.Immutable; | |||
using System.Collections.Generic; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to bring in new using
but there seems to be no new code added that would require it
@@ -1,4 +1,5 @@ | |||
using System.Collections.Immutable; | |||
using System.Collections.Generic; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to bring in new using
but there seems to be no new code added that would require it
There 2 changes in this PR.
The second part is about me wanting to collect some more accurate data about how much tech debt is in a system, the reason i want to use the Analyzers for it is i want to be able to enforces as a part of linting creation people to think about how much work it is to fix the things they are flagging, because the person creating the rule will be the best one to make this call.
At the moment its just a simple "Time in minutes" we want to capture so that when we analyze a code base we can get a weighted estimate of how much technical debt for which problems are in there.
This is similar to the approach in software like Sonarqube