Replace BetterCodeHub

[NicMcPhee]

While I quite like BetterCodeHub in many ways, we've had a variety of issues that have convinced me that we probably want to look for other alternatives.

Desired properties

• When possible, it would be nice to have checks that can be done in the IDE so that students get immediate feedback and don't have to wait for something to happen on GitHub (or elsewhere) to find out that there's an issue. This may not be possible everywhere (e.g., code duplication), but it would be nice when possible.
• Related to the previous, it would be good if things are fast; having to wait a zillion years for your GitHub Actions checks to complete is frustrating for everyone involved.
• We should still be able to run the checks in GitHub Actions as a backstop.
• It would be nice when possible to have the same tool handle both the client (JS/TS) code and the server (Java) code. That may not be very reasonable, though.

Desired checks

BetterCodeHub does 10 checks, but we don't really care about all of them (at least not in this context). The ones that I'd like us to have checks for include:

• Write short units of code: This is essentially a simple length check. I know that this irks @floogulinc, but I think that for beginning coders (which Software Design students really are), having something that squawks when functions/classes start to get long is a Good Thing. In a perfect world it would be nice if the check supported something like "Beyond X is a warning, but beyond Y is an error". That way they could go a little over the line and things would still build, but they'd get poked about it and know that they need to be watching that component.
• Write simple units of code: I think this is basically a cyclomatic complexity check. Again, it would be nice to have both warning and error settings.
• Write code once: This is one of the most important checks IMO, and to be honest the students rarely noticed when BCH started warning them about issues there, so it would be nice to surface this more explicitly. This kind of analysis is harder to do on-the-fly, so I'm not sure if we'll find something that will work in real-time in the IDE, but it would be cool if we could.
• Keep unit interfaces small: This is basically about keeping the number of arguments in a function under control, and can probably be checked by the same thing that checks unit length and complexity. I'm generally a fan of this, although the way Angular uses injection in constructors frequently leads to quite a few arguments. It would be nice to have something that can be configured to ignore those constructors, but that might require too much Angular knowledge to be reasonable? And, to be fair, I would consider this check a fairly low priority; I don't see a lot of code that violates this in egregious or problematic ways, probably because of all the structure that Angular and Javalin provide.
• Write clean code: I think that this should be mostly handled by other linters and the LGTM checks, so it shouldn't be a major issue.

Some that I think we can ignore:

• Separate concerns in modules: This is essentially looking for modules that call back and forth a lot in ways that suggest that they're no maintaining their "independence". I think that this is generally a good thing to care about, but it almost never has come up in a meaningful way in the course, and the structure imposed by Angular and Javalin tends to keep this under control. Probably the most likely source of trouble here would be poor design of services in Angular, but that's rarely been a major issue.
• Couple architecture components loosely: This is similar to the previous one, and not of great concern for all the same reasons.
• Keep architecture components balanced: In theory this could help point out when students are doing too much in the client and not enough in the server, but in practice that's never happened, and I doubt we'll be able to find a tool that would provide that kind of feedback in a meaningful way.
• Keep your codebase small: We've never come close to triggering this. 😜
• Automate tests: Our code coverage checks are actually a lot better than anything BCH does here.

Some tools to consider

• eslint: We're already using eslint, so it would be good to see which of these issues we can address with that. It would probably only be client issues, though, so we probably need something similar for the Java code. It looks like it can handle things like complexity, length, and depth.
• Megalinter: Seems to check a lot of things and cover a lot of languages. I need to read more about it; it looks like it's more a CI tool than a real-time in-the-IDE tool.
• jscpd: An npm based copy-paste-detector that, despite being an npm install, supports tons of languages. There also seems to be a VS Code extension that does this, so maybe we can do this in the IDE.
  • Their README lists a bunch of projects that use this package, including MegaLinter and super-linter (a GitHub Action combo of many different linters) and Codiga, which provides in-IDE linting feedback.
  • Turns out that MegaLinter is actually a fork/rewrite of super-linter with additional features. Not exactly sure what that means for us, but it's worth noting.

[kklamberty]

@NicMcPhee - In the meantime, do we want to remove CODE_QUALITY_CHECKS.md from the project since it refers (only) to projects (LGTM, BCH) that no longer exist?

[NicMcPhee]

Yes, I think that's the right way to go.

[NicMcPhee]

I feel that DeepSource and CodeQL are giving us most (if not all) of what we want. I can't figure out from their docs if either is checking for code duplication. I might just run a simple test to check that. If they aren't, then there are other tools (like jscpd) that can do that (& we could create a new issue for that). If they are, then we should just close this as having been resolved by a variety of other changes.