Transforming private Cop to ALCops

[MODUSCarstenScholling]

Hi Arthur,

You may remember the discussion more than a year ago in LinterCop repo: Migrating from private Cop to LinterCop.

Since then, a lot has changed, ALCops got some new rules, duplicating exactly, almost or partly rules we have in our cop.
I was finally able to transform some of our rules or mark them as replaced by some of your rules.

To begin, I have prepared a dummy PR here. Mainly for you to get an idea on how I would handle the transformation (re-using your patterns wherever possible).

1. To start, I have created a commit to easily setup my dev and build environment for VSCode (docs, PS), Because I usually used VS for C#: Setup local development environment
2. Then I added a modified copy of DC0004 for internal objects: DC0006 InternalProcedureRequiresDocumentation. I didn't want to modify the existing DC0004, because that would change the behavior. Or would you like to have this in one implementation raising 2 different IDs?
3. Step 3 was the addition of some new naming patterns for LC0092 with proper fallbacks to not break something: LC0092 NamingPatterns: New naming patterns LocalVariable, GlobalVariable, VarParameter with proper fallbacks
4. Finally, I added a configuration for punctuations, because we also allowed an exclamation mark: AC0014 ToolTip multiple possible punctuations. The default is still a dot. The message changed to reflect the configured punctuations.

I have a bunch of others in my pocket but would start with these. The PR above is an example on how I would add them. Of course, separated by new issues for every commit.

Please let me know if you have additional suggestions before I start with. For example, how you would like the documentation (should it be created in parallel because it is a different repo), or if I missed something.

[Arthurvdv]

First off: YES, absolutely! 🤗 I'd love to receive contributions for ALCops and it's fantastic that you're willing to bring parts of your private cop into the project. This is exactly the kind of collaboration that makes our BC community so great.

I've had a look through the changes and everything looks very promising. Regarding the documentation: yes, that should be a separate companion PR since the documentation lives in a different repository. My preference is to have the documentation in place before I publish a new beta release.

A couple of comments on the PR:

1. Development setup

I think we may have crossed paths a bit here. In the meantime, I've also added a setup script for the BC DevTools dependencies (c0264af). This should take care of installing the required dependencies for local development.

2. DC0006

My preference would be to have a single implementation that can raise two different diagnostic IDs. I think that will make the rule easier to maintain in the long run, since the business logic remains in one place.

Overall, I absolutely like the direction you're taking here and feel free to start opening issue/PRs for the individual changes.

[MODUSCarstenScholling]

As a trial run, I've now adjusted the wording for DC0004 and DC0005 and implemented DC0006–DC0010.

For now, I need to get a feel for what works best here and what the ideal workflow looks like.

You’ll notice that I’ve tweaked or moved a few minor things “on the fly” - I hope that’s OK.

I’ve also duplicated the documentation for DC0006-DC0010 based on the existing documentation for DC0004.

Please let me know if this is OK so far or if I should do something differently or better.

If the PR gets approved, I’ll have a few technical questions, but I’ll wait until after that.