metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Leet <>
Subject Re: [DISCUSS] Code Reformatting next steps
Date Fri, 11 Aug 2017 13:31:40 GMT
is updated to reflect the code style standards.  It also includes
instructions for setting up warnings and autoformatting in both IntelliJ
and Eclipse.

However, the current standard is to not update files that don't match the
overall style.  The larger, one-off, reformats are just to get things into
a consistent style such that we expect everything to actually follow our
style.  IntelliJ lets you reformat at module level (including file masks),
so any module level reformat (best case) is to just reformat on a *.java
mask and make sure nothing went wrong.  I have tested this before on our
project, hence 1087.

Updating the PR template is a good callout though. I'll create a ticket for

On Fri, Aug 11, 2017 at 9:18 AM, Otto Fowler <>

> We should add something to the PR template about this.  Did we change the
> contributor’s guide?
> Also, are there common steps to take with Intellij, so that we all do the
> same thing
> for mass reformats?
> On August 11, 2017 at 08:14:21, Justin Leet ( wrote:
> Now that METRON-746 <> is in, we
> have a consistent code formatting setup where (for the most part) it can
> be
> autoapplied.
> Barring one existing PR, the main thing is just picking a module, doing
> the
> format, and testing it out. Obviously, I'd like to avoid collisions with
> any major PRs out there (say METRON-777
> <>), so things like parsers are
> out.
> Does anybody have any thoughts on what should be grabbed first? Maybe
> metron-stellar since it's pretty easy to test and even though it gets PRs,
> they're typically fairly small and contained?
> The main hiccup before being able to do any blanket reformatting is this
> PR:
> METRON-1087: Adjust license headers to be comments instead of Javadoc
> <>
> Without it, all the license headers get reformatted in Javadoc style when
> autoformatted (this actually happened before, but since we didn't actually
> format our code much it was pretty benign). Once this is in, I'm fine
> doing
> any headers that sneak in via PRs, it's a pretty easy find/replace in the
> editor.
> Once we're confident this works fairly smoothly, it should be pretty easy
> to branch out and start hitting more modules in whatever priority order we
> want.
> Justin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message