Re: [Codenarc-user] success stories?

[Chris M. <cm...@gm...>]

Philip,

*I have applied static analysis to a few codebases over the years, some
more challenging than others. *

*For greenfield projects, I tend to start strict and loosen up as necessary
-- enable all the rules you think you want, and then be willing to disable
when a rule is more trouble than it’s worth.*

*For an existing large codebase, I tend to start small and grow as able.
Select the small, core set of rules, fix the violations, and then expand
the ruleset incrementally as you have the opportunity. I’d probably rather
have a smaller ruleset with developer buy-in and acceptance, rather than a
larger ruleset with resentment.*

I don't know if it is helpful, but this blog post discusses using CodeNarc
*generic* rules for some custom, non-standard use cases, that might be
attractive to senior devs:
https://tenpercentnotcrap.wordpress.com/2013/08/04/codenarc-hidden-gems-using-codenarcs-generic-rules/


Good luck.

Chris

On Wed, Mar 7, 2018 at 3:01 AM, Philip Yurchuk <
phi...@ma...> wrote:

> Hi Marcin,
>
> Thanks for the encouragement! I think I've got a lot of points to justify
> it's use and endorsements from famous programmers, which will help. My
> challenge is demonstrating how to implement it. The big complaint is that
> such tools are too noisy, and I understand that viewpoint. I tried this on
> a personal project and got over 3,000 warnings or errors. My approach:
>
>
>    - Change the scope to remove config files, which have DSLs and idioms
>    that can clash with rules. Your config files should be carefully peer
>    reviewed anyway.
>    - Change the templates of your code generators (including in your IDE)
>    to produce compliant code. If you can't, exclude it in the scope.
>    - If you must, limit the scope to changed files, just to spur adoption.
>       - Code is read more than it is written, so a big benefit is gained
>    from everyone's code looking identical in style and idiom. (This is a key
>    point from my programmer productivity talk.) It takes less time and mental
>    effort to make the code compliant with the rules than it does to justify
>    why it doesn't need to change.
>    - Most of the time it's better to suppress a warning than kill the
>    rule.
>    - Corollary: if removing rules encourages adoption without adding
>       risk, give yourself permission to so.
>
> I'm very open to feedback ideas. Another challenge is to properly address
> the talk. I think this is hugely beneficial to junior devs, as learning the
> rules will accelerate your path to senior. So going over the rules that
> catch newbie bugs is very enlightening. But senior devs have the power to
> enforce it's use, and I don't want to bore them covering elementary rules
> on hashcode, equals, serialization, etc. I think CodeNarc's idiom
> enforcement is truly excellent for advanced developers, and I'm still going
> through them but I'm not seeing them as much in PMD or SpotBugs. The latter
> does have the advantage of bytecode analysis of files across the project.
>
> Thanks,
> Philip
>
>
> On 3/6/2018 11:58 AM, Marcin Erdmann wrote:
>
> Hi Philip,
>
> I'm a big fan of CodeNarc and use it where I can. Unfortunately I do not
> have any success stories but a generic observation that over the years I've
> encountered a lot of resistance from others when trying to add CodeNarc to
> projects. Maybe you need to have a certain level of OCD in you to
> appreciate how good it is at keeping the codebase consistent (for me that
> characteristic of CodeNarc is even more important that helping to spot
> bugs).
>
> Anyhow, good luck with your talk. I'd appreciate you sharing a link if a
> recording of it is made public. :)
>
> Marcin
>
> On Fri, Feb 16, 2018 at 12:35 AM, Philip Yurchuk <
> phi...@ma...> wrote:
>
>> Hi all,
>>
>> Big thanks to the developers for this tool! I'll be giving a talk to the
>> OCJUG next month about static code analysis, and being a Groovy guy,
>> CodeNarc will feature prominently. Maybe I'll get some Groovy converts, but
>> the purpose is to get people to start using these tools.
>>
>> Are there any great success stories with using these tools? How are you
>> persuading people to use them? I'm invoking an John Carmack (Doom, Quake,
>> Oculus VR), who is a huge proponent of such tools and admits his own code
>> is "riddled with errors." He also mentioned a multi-developer, multi-day
>> bug hunt that ended up being an error that the analysis tool flagged, but
>> he hadn't had a chance to fix.
>>
>> I'll also be showing how it fits Larry Wall's three virtues of a great
>> programmer. But specific success stories would be great to have. I do think
>> the rules themselves show how strong the tooling has become and will be
>> going over many.
>>
>> Thanks much,
>> Philip
>>
>> --
>>
>> [image: Made Up Name] <http://MadeUpName.com>
>>
>> Philip Yurchuk <http://linkedin.com/in/philipyurchuk/> / CEO
>> 714-585-5756 <%28714%29%20585-5756>
>>
>> Software Development and Staffing
>> http://MadeUpName.com
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Codenarc-user mailing list
>> Cod...@li...
>> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>>
>>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Codenarc-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codenarc-user
>
>