Hi, > - Do we care about code being commented out? I think not.
If we know why it was commented out sure. There’s always the concern is this code possibly needed or not? > - Does a semicolon matter? It marked as a minor issue but it can cause issues when JS code is optimised and/or minified. It’s easy and safe to fix. > - Is “:Object” really a critical issue? Critical no (and it's not marked as such) and in some cases it’s quite useful. Like all rules there are exceptions. Using a class with named properties gives you type safety and performance benefits. > - Is refactoring “complexity” really a huge problem If we want easy to test/easy to maintain code then it can be yes. > - This one: Replace == with === : has been discussed and I think your making > the change suggested broke things. It didn’t break things in any major way, the tests passed, examples worked and the application I’m working on worked. I believe there was one instance that caused an issue for Harbs. There are some other useful rules in there I’ll document them. > Probably the best approach would be to collect these into a wiki page and > then determine what conventions developers consider important. Once that is > done change the sonar configuration and show true technical debt. I think > that this is much less risky to the project and much less distraction to the > team. Sure I’ll go with that approach. Thanks, Justin
