billwagner / effectivecsharpanalyzers Goto Github PK

Style.

Consider if this can be an analyzer. If so, how would it work.

Design Guidance, won't fix.

I don't think this lends itself to analysis. The item says that if you are implementing this kind of relationship, do it in the standard way. It would have to find code that does a comparison, but doesn't use this API signature. I don't think that's possible.

Warning level.

Should be easy: Any field init in a ctor that doesn't use an argument should be a candidate.

Warning class.

This guidance relies on known the history of the development of the base and derived classes. That's unknowable for a static analyzer.

Won't fix.

This is likely several analyzers. A later comment will create sub-tasks for all the different ways to go south here.

Worth experiementing with, but this may not be a good choice for an analyzer.

Warning.

Find all event declarations.
Look for all code that raises the event.

Warning.

Can this find every format string in all APIs? (e.g. Console.WriteLine)?

style.

Style.

Also, might be very hard to analyze.

Warning.

It's a variation of Item 12, so should be possible to analyze for.

Design and knowledge. There's really nothing for an analyzer to do here.

It should be a warning.

This may become a won't fix item. I don't know how to find what is an expensive resource when I find what variables are captured.

Nothing to write an analyzer for. Won't fix.

Design Guidance

Won't fix.

Should be a warning if this can be found.

This might be harder than I think, but it's worth trying to consider.

Warning level.

This is very design oriented. It's not applicable for an analyzer.

Won't fix.

style.

If the first argument is a closed generic type, consider making an extension method? This may not be a high-value item.

Style.

More design oriented. This might be hard.

I can't see how to find code that isn't doing this, but could.

Won't fix.

Warning.

Look for any class that has Exception as a base class (or any other exception class as a base)
Make sure all ctors are defined.

warning.

This may be a good one, or it may be too open ended.

Style.

This may be hard to find, It's looking for member fields that are new'ed up twice in a constructor path.

The most likely case is initialization and ctor.

Warning.

This could be very hard to find, but likely worth it.

As this gets started, I'll define a set of sub-issues for when boxing and unboxing happens.

Design guidance.

Won't fix.

Style.

And, this will get modified in the future with pattern matching.

Look to find where strings are used as symbols.

This should be a warning.

I can't see how to find all issues here.

As I learn, this may or may not be worth pursuing.

Consider if this is a warning.

Should be a straightforward element to implement.

This might not be perfect, but likely worth the investment.

Style.

Is this analyzable?

Style.

Not sure if this can be an analyzer.

Style.

This is hard to know if the constant value will change.

Check for static, fields, and locals.

Warning.

May be difficult to find.

This should be a warning for var vs. explicit.

Style

This is not easily analyzed.

Start it as won't fix.

Style.

Consider that any catch with an unconditional rethrow would be a candidate.

style.

This might be hard to analyze. It's looking for repeated init logic in multiple ctors.

Warning.

Style, I think.

This should be a warning.

Look for type parameters that are fields.
See if the generic class 'owns' that field.
Look for IDisposable support.

Style.

This is a lower priority. It may be reclassified as won't fix. This is hard to find.

Style.

This may also have lots of variants about what should be found.