+1 to what Mike said. This only works IMO if it is enforceable via an automated task associated with the build.
Are there any common configs that other apache projects use that we might be able to adapt? (i.e. s the hadoop coding style enforced via checkstyle?) I'd also suggest that we publish IDE configs for Eclipse and Intellij to make this sort of thing a bit easier to conform to. On Wed, Nov 30, 2016 at 9:31 AM, Nick Allen <[email protected]> wrote: > +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]> >
