I think it would be better if the people working on the code would learn what they are doing wrong ... But I agree that anyone fixing stuff would be good. In the end I'm planning on seeing a quality gate in the build that breaks the build if any new major issues are added.
Chris Von meinem Samsung Galaxy Smartphone gesendet. -------- Ursprüngliche Nachricht -------- Von: Alex Harui <[email protected]> Datum: 17.06.16 20:30 (GMT+01:00) An: [email protected] Betreff: Re: AW: AW: AW: Coding conventions? On 6/17/16, 11:04 AM, "Josh Tynjala" <[email protected]> wrote: >I think that having SonarQube providing automated analysis ike this is >very >good. However, we shouldn't consider its suggestions to be gospel either. >I >agree with Alex that we shouldn't hold back the next release just to make >SonarQube happy. I think it's a good idea to try to get at least some of >its "blocker" or "critical" suggestions out of the way in the following >release, though. Higher quality code will help with future stability, and >we're getting to a place where that's starting to be more important. It'll >be good to see some kind of measurement of progress there. FWIW, I've been wondering if we could incentivize some summer students to pick away at some of these SonarQube issues. They would learn or practice Java and GitHub. How much would they have to know about Flex? I would think they wouldn't have to know much. It would be tweak the code, run "ant all" or "maven" and if everything passes, send the patch or check it in. Or are these issues going to be more involved than that? Thoughts? -Alex
