Sorry Rob, that was an example, but I forgot to emphasize that.
Bruno
From: Rob Vesse <[email protected]>
To: [email protected]
Sent: Wednesday, May 13, 2015 8:37 PM
Subject: Re: Code policies
80 columns? I sincerely hope not
120 is the bare minimum in this day and age, we aren't coding on CRTs any
more people!
Rob
On 12/05/2015 22:22, "Bruno P. Kinoshita" <[email protected]> wrote:
>I think that something like checkstyle, PMD and FindBugs, and update the
>contribution page asking contributors to review their changes before
>sending PR's or patches would help.
>It would be good to avoid replicating unnecessary policies in the web
>site though. Like suggesting that we expect the contributor to use 80
>columns. That would mean that we would have to update the checktyle XML
>rule file and the web site if we decided to use 120 or any other number.
>We can probably leave some basic policies (no tabs, no unused imports,
>etc).
>WDYT?
>Bruno
>
>
> From: A. Soroka <[email protected]>
> To: "[email protected]" <[email protected]>
> Sent: Wednesday, May 13, 2015 2:07 AM
> Subject: Code policies
>
>From comments on some "clean up" PRs I submitted over this past weekend,
>it seems that it would be nice to have some rough code standards that
>could help newcomers _without_ inhibiting anyone from contributing.
>Possible policies that came up included:
>
> • Don't give a method signature that throws checked exceptions that
>aren't ever thrown from the code in that method unless an API supertype
>specs it.
> • Don't leave unused imports in. Any IDE can solve that problem with
>one keystroke. {grin}
> • If a type declares a supertype that isn't a required declaration,
>consider whether that clarifies or confuses the intent. The former is
>okay, the latter not so good.
> • Minimize the compiler warnings your code throws up. If you use
>@SuppressWarnings to hide them, please add a comment explaining the
>situation or a TODO with a potential future fix that would allow removing
>the suppression.
> • Remove unused local variables or fields or uninteresting unused
>private methods. If it's debugging detritus, consider replacing it with
>good logging code for future use, if that seems likely to become useful.
> • If there is valuable code in some unused private method, add a
>@SuppressWarnings with an explanation of when it might become useful. If
>there is valuable but "dead" code inside a "live" method, consider
>breaking it out into a private method and adding a @SuppressWarnings and
>an explanation.
>
>If we can develop a reasonable list of expectations for contributions
>(and presumably, for the current code base) I will be happy to write some
>text for project site pages and try to encode some of the expectations
>with Maven Checkstyles. To be clear, I'm not suggesting any kind of
>blocking step in the build process, just a chance for some handy feedback
>about code submissions.
>
>Thoughts?
>
>---
>A. Soroka
>The University of Virginia Library
>
>
>
