I agree with Dave. A little more consistent style is a good thing. I don't care that much what the style is, but we need something.
Straw man suggestion: minimally add to James style suggestions: - indent 4 spaces, never use tabs - 140 characters max per line - opening braces in K&R style (opening brace on same line that indicates start of block) - never just log an exception, handle it or rethrow it. - avoid RuntimeException unless you really want no-one to catch it before it kills the thread (or program) - ERROR message for real ERRORS, WARN to indicate user has provided bad, or poorly supported input, never for coding error - one statement per line, end with ; - always use braces with conditionals Or just pick a more complete style guide: Many apache projects, have one. There seems to be no standard coding convention, but we could pick one, eg commons: https://commons.apache.org/proper/commons-net/code-standards.html google (https://google.github.io/styleguide/javaguide.html) has one which I like except the 100 character line limit. As James says, we are not using keypunches any more One advantage to the google style is that this tool http://checkstyle.sourceforge.net/ is already configured to enforce it. What I would like to avoid is - different style in every file - having deltas change history with diffs that are the result of reformatting wars. This makes it hard to find the substantive changes. On Sat, Dec 12, 2015 at 2:54 PM, Dave Hirko <d...@b23.io> wrote: > James, > > This my be my naivety on open source projects, but I think we need to > codify a little more the development style guides. I like the start in the > wiki, but based on my experience working at Amazon for a number of years, > and how we do things at B23, we try and codify in a reasonable way code > style guidelines (note the word “reasonable”). Obviously not making it too > heavy handed, but specific enough to provide boundaries. Also don’t want > to spend too much time on style right now when there are a lot of commits > that need to be made! > > As an example, we use flake8 for Python, a clang-linter for C which are > both agnostic to IDE’s (although we all use Atom and share our config > files). There are a ton of style guides out there for Java, etc. There > was a great Java style guide and recommended JAR files Robert Sedgwick used > for Java for his undergraduate Algorithms courses at Princeton. > > I’ve observed on a number of other open source projects that its common to > see commit messages that just say “flake8.” When I look at the Hadoop, > Spark, Ansible code base, it seems to have a really consistent style which > is nice! > > One of our criticisms of the original OpenSOC code base was style and > quality - it was written in Java but Pythonic in style (which as you know > I've provided specific feedback a number of times over the past year!). We > heard it again from an active OpenSOC customer this week. The code worked, > but it was often needed refactoring here and there to fit in the conforms > of a specific syntax. > > Seems like starting off on the right foot here and now would help overall. > > We have some good style guides for Python and C here at B23, not so much > on the Java side. Anything we can do to help contribute on this, we would > be glad to help! > > Dave Hirko | d...@b23.io | 571.421.7729 > > > > > > > > > On 12/12/15, 11:14 AM, "Debo Dutta (dedutta)" <dedu...@cisco.com> wrote: > > >Regarding contribution to the wiki - do we submit docs with pictures etc > >when we need a bigger change. > > > >Simple Comments: > >* We need CLAs from folks who contribute. > >* Need some detailed code style guidelines like > >http://twitter.github.io/effectivescala/ or just point to scala/java > >guidelines like this (also for python/go if we go that route for some > >components) > >* Guidelines for code review should also be posted. Every reviewer must > >actually run the component and ensure unit tests are passed unless there > >is a CI gate system for this. > >* Features should not be accepted without tests. > >* We should at least use a logging infra for the code. > >* Ideally we need a CI gate for commits. > >http://docs.openstack.org/infra/manual/developers.html …. We need a > >precise process like this. Then it will be easier to grow the community. > >* Naming convention should also be in the style guide. > > > >Nits > >* Several lines with an extra dot after the itemized list > > > >On 12/12/15, 7:35 AM, "James Sirota" <jsir...@hortonworks.com> wrote: > > > >>Hi Debo, > >> > >>You propose changes by responding to this thread and we’ll incorporate > >>them into the document. > >> > >>Thanks, > >>James > >> > >> > >> > >>On 12/12/15, 8:34 AM, "Debo Dutta (dedutta)" <dedu...@cisco.com> wrote: > >> > >>>Ok can access but can’t edit … how do I get access? > >>> > >>>Looks like a gr8 start. > >>> > >>>On 12/12/15, 7:29 AM, "James Sirota" <jsir...@hortonworks.com> wrote: > >>> > >>>>Ok try now > >>>> > >>>> > >>>> > >>>> > >>>>On 12/12/15, 8:26 AM, "Debo Dutta (dedutta)" <dedu...@cisco.com> > wrote: > >>>> > >>>>>can¹t access the wiki > >>>>> > >>>>>On 12/12/15, 7:11 AM, "James Sirota" <jsir...@hortonworks.com> wrote: > >>>>> > >>>>>>I posted the proposed development guidelines for Metron that Andrew > >>>>>>and > >>>>>>the Rackspace team came up with. Does anyone want to add/edit/remove > >>>>>>anything in this wiki entry? I¹d love to get this solidified by mid > >>>>>>next > >>>>>>week so we can call a vote on it. We also need to fill out a couple > >>>>>>of > >>>>>>sections that don¹t have text in them. > >>>>>> > >>>>>> > https://cwiki.apache.org/confluence/display/METRON/Development+Guideli > >>>>>>ne > >>>>>>s > >>>>>> > >>>>>>Thanks, > >>>>>>James > >>>>> > >>>>> > >>> > > >
