IMO, even more important than technical debt is a test system and tests to make sure any changes don't break anything.
I could be wrong, but I think our customers would rather have us spend our time and energy on missing features like AMF right now. My 2 cents, -Alex From: Dave Fisher <dave2w...@comcast.net<mailto:dave2w...@comcast.net>> Reply-To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" <dev@flex.apache.org<mailto:dev@flex.apache.org>> Date: Thursday, July 6, 2017 at 9:24 AM To: "dev@flex.apache.org<mailto:dev@flex.apache.org>" <dev@flex.apache.org<mailto:dev@flex.apache.org>> Subject: Re: [FlexJS] technical debt Hi Justin, (I missed your double reply until I reviewed the thread before sending. This caused me to remove part of this email.) I looked at some of the major and minor Code Smells. I think that rather than accepting the ActionScript conventions that Sonar provides that most of these can be eliminated by resetting the rules to match this project’s ideas about how Flex smells. - Do we care about code being commented out? I think not. - Does a semicolon matter? - Is “:Object” really a critical issue? - Is refactoring “complexity” really a huge problem - Function has a complexity of 14 which is greater than 10 authorized. - This one: Replace == with === : has been discussed and I think your making the change suggested broke things. 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. Only once Sonar rules are properly tuned is it a powerful tool for assuring code quality. Until then it can be a nearly useless sink for scarce developer time and a chance for “hair on fire” concern over “technical debt”. I agree that like it is it could be a measure of usefulness for new developers in a commercial situation. Regards, Dave On Jul 5, 2017, at 11:53 PM, Justin Mclean <jus...@classsoftware.com<mailto:jus...@classsoftware.com>> wrote: Hi, Dave I assume the case statement issue you referring to is is the last one in this list [1]. It not a bug but style wise it’s a little odd and probably should still be fixed. Thanks, Justin 1. https://builds.apache.org/analysis/component_issues/index?id=org.apache.flex.flexjs.framework%3Aflexjs-framework-parent#types=CODE_SMELL|severities=CRITICAL
