geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Lund <kl...@apache.org>
Subject Re: [DISCUSS] Adoption of a Coding Standard
Date Mon, 24 Jun 2019 22:15:05 GMT
Java is complicated and Apache Geode is complicated, hence it's a large
Coding Standard. *Effective Java* is similarly *large* if you compare it to
the *Google Java Style Guide*.

The "*rules*" are "*guidelines*" -- I think you're being too literal. Also,
please remember what I said:

I'm not proposing we rigidly and blindly follow this Coding Standard. We
> can extend or even supersede portions of the adopted Coding Standard with
> our own Addendum. The Coding Standard Addendum would exist on the Apache
> Geode Wiki to define Geode-specific rules or recommendations. What I'd like
> to see happen is for us to use the SEI CERT Coding Standard for Java as a
> starting point for our own Coding Standard. The resulting Coding Standard
> for Geode can be as static or as living and evolving as we wish.
>

Is there an entry in the Coding Standard's Rules section that you feel is
irrelevant or incorrect? Please pick an example with a link to it so we can
discuss it.

PS: There aren't any other Coding Standards that I would personally write
or recommend.

On Mon, Jun 24, 2019 at 2:50 PM Alexander Murmann <amurmann@apache.org>
wrote:

> Hi Kirk,
>
> I think having a coding standard that goes beyond a formatting style guide
> is a great idea. There are many interesting things in the SEI CERT
> standard. However, it's also massive. I see 13 rules just about methods.
> Yet some guidelines that would be most important to me like limiting method
> length and number of parameters are missing.
>
> I wonder if we might be better off taking the rules we like from SEI CERT,
> adding our own and aiming for a much smaller set of guidelines. I'd hope
> for something like a one-pager. If it gets much longer than that, it
> becomes burdensome to read for newcomers and we want to make sure they can
> quickly take in what's most important.
>
> I also prefer "guidelines" over "rules". I'd like to have a discussion if
> someone is not following a guideline, rather than creating the impression
> that all rules must be followed, no matter what the circumstances are.
>
>
> On Mon, Jun 24, 2019 at 2:16 PM Kirk Lund <klund@apache.org> wrote:
>
> > Apache Geode has a Code Style Guide [1] which is currently defined as
> > following the Google Java Style Guide [2]. This style guide is a good
> > starting point, but it deals primarily with formatting of code and is a
> > fairly dated and static document that doesn't evolve much.
> >
> > I'd like to propose that the Geode dev community adopt a Coding Standard
> in
> > addition to the Style Guide. Specifically, I believe that having our
> > community follow the SEI CERT Coding Standard [3] for Java [4] would
> > benefit us greatly. There are also Coding Standards for C and C++ that we
> > could consider if we decide to use the one for Java.
> >
> > SEI CERT Coding Standards are completely documented on their wiki which
> is
> > open to having anyone join and become involved in their community. They
> are
> > also available in book form (including on amazon.com).
> >
> > From what I've studied, I believe the Coding Standard and Google Java
> Style
> > Guide will be compatible, but we could decide that the Coding Standard
> > supersedes anything in the Google Java Style Guide that is directly in
> > conflict just in case.
> >
> > I'm not proposing we rigidly and blindly follow this Coding Standard. We
> > can extend or even supersede portions of the adopted Coding Standard with
> > our own Addendum. The Coding Standard Addendum would exist on the Apache
> > Geode Wiki to define Geode-specific rules or recommendations. What I'd
> like
> > to see happen is for us to use the SEI CERT Coding Standard for Java as a
> > starting point for our own Coding Standard. The resulting Coding Standard
> > for Geode can be as static or as living and evolving as we wish.
> >
> > The Coding Standard can then provide helpful guidance in how we reshape
> > some of the Geode code base that is in greater need of refactoring. It
> > would also help guide us from following poor examples in the current code
> > base when introducing new code.
> >
> > [1] https://cwiki.apache.org/confluence/display/GEODE/Code+Style+Guide
> > [2] https://google.github.io/styleguide/javaguide.html
> > [3]
> >
> >
> https://wiki.sei.cmu.edu/confluence/display/seccode/SEI+CERT+Coding+Standards
> > [4]
> >
> >
> https://wiki.sei.cmu.edu/confluence/display/java/SEI+CERT+Oracle+Coding+Standard+for+Java
> >
>

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