+1 to checkstyle. Maybe even tackle that effort project-by-project instead of one giant PR. But however it gets done, its got to get done.
On Tue, Nov 29, 2016 at 6:23 PM, Michael Miklavcic < [email protected]> wrote: > For 3, I think we should implement checkstyle, perform a one-time mass > normalization check-in, and then move forward from there. Right now we are > at the whim of individual preferences. I don't have a huge issue with this > in incubation and while features and architecture rapidly change, but we > should settle down as we approach maturity. > > On Nov 29, 2016 4:10 PM, "Matt Foley" <[email protected]> wrote: > > > 1. I think we need to emphasize good unit testing more. I guess > METRON-37 > > integrated Cobertura with our build process, but how often does it run > and > > where is JUnit code coverage reported? > > > > 2. Regarding the missing Code Style Guidelines, I’ve always thought the > > Hadoop Style guide was good: short and sweet, and relatively easy to > agree > > to (for such a deeply “religious” topic :-) See > https://wiki.apache.org/ > > hadoop/CodeReviewChecklist The core of it is simply “use Sun's code > > conventions < http://www.oracle.com/technetwork/java/javase/ > > documentation/codeconvtoc-136057.html > except indentation is 2 spaces, > > not 4”. > > > > 3. Other useful things: > > - In a PR, maintain the existing style of the file. > > - Don’t combine code changes with lots of edits of whitespace or > comments; > > it makes code review too difficult. It’s okay to fix an occasional > comment > > or indenting, but if wholesale comment or whitespace changes are needed, > > make them a separate PR. > > > > 4. How about mandating Javadoc comments for all public APIs, and > > generating Javadocs for release builds? I’m a big fan of this, and it > > isn’t much effort on an on-going basis; we did it in Hadoop. This is how > > you scale “self-documenting code” as you get past a few tens of KLOC – > good > > comments and transparent coding make the code self-documenting at the > small > > scale, Javadocs make the system self-summarizing at the large scale. > > Metron is now about 66 KLOC, just line-counting Java files and > subtracting > > the ASF License headers (admittedly not excluding other whitespace or > > comments – but there aren’t that many comments! :-) I’d be willing to > help > > with retroactive cleanup, if there was support for the idea. > > > > Cheers, > > --Matt > > > > > > On 11/29/16, 1:20 PM, "James Sirota" <[email protected]> wrote: > > > > We have a really old (and incomplete) coding guidelines document that > > I'd like to clean up prior to our graduation. Does anyone have anything > in > > particular they wanted to add/change about this document? Please post > > suggestions to this thread and I will incorporate them > > > > https://cwiki.apache.org/confluence/display/METRON/ > > Development+Guidelines > > > > ------------------- > > Thank you, > > > > James Sirota > > PPMC- Apache Metron (Incubating) > > jsirota AT apache DOT org > > > > > > > > > > > > > -- Nick Allen <[email protected]>
