qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Harvey <p...@philharveyonline.com>
Subject Re: AMQP 1.0 JMS client - supplementary coding standards
Date Tue, 04 Jun 2013 16:37:07 GMT
Ah, I expected a swift response about this.  Luckily I'd already donned my
tin hat :-)

On 4 June 2013 17:16, Rob Godfrey <rob.j.godfrey@gmail.com> wrote:

> I'm not really a big fan of enforcing commons lang for toString  -
> sometimes you want/need to have a specific string representation of an
> object.


Indeed - that's why I wrote "should" rather than "must".  I accept that
there are exceptional cases but believe there's a benefit in the other 90%
of classes doing things in the same way as each other.

For clarity I will add the usual "should vs must" distinction at the top of
the wiki page.


>  Similarly I think we should be intelligent in defining equals and
> hashCode() methods.
>
> What I'd actually prefer to say is that every object should define a
> toString().
>

Yep, that's in the main coding standards already.

>
> In general I'd like to avoid having dependence on external libraries unless
> we *really* need to.
>

You presumably believe that the use of EqualsBuilder and HashCodeBuilder
for faciliating the bug-free implementation of equals() and hashCode() does
not merit the inclusion of commons-lang as a dependency?


>
> On slf4j for logging... I think we should work out what we're going to do
> with logging in proton and then see if we want to adopt the same approach.
>

OK let's do that soon.  The longer we continue without a proper logging
approach the harder it will be to introduce one.

>
> -- Rob
>
>
> On 4 June 2013 17:55, Phil Harvey <phil@philharveyonline.com> wrote:
>
> > Given that the AMQP 1.0 JMS Client sub-project is starting from a clean
> > slate, this is an opportunity to define some Java coding standards that
> are
> > somewhat tighter than our existing ones [1].  I've therefore created a
> wiki
> > page for supplementary standards [2] that only apply to this project.
> >
> > I realise I am laying myself open to accusations of being overly
> > prescriptive.  However, I find it easier to work with a codebase if
> > standard things like logging, toString, TODO comments etc are always done
> > in the same way (unless there's exceptional circumstances).
> >
> > If you're interested in this topic I recommend that you use Confluence's
> > "watch page" feature to keep track of further updates.
> >
> > Comments welcomed.
> >
> > Phil
> >
> > [1]
> https://cwiki.apache.org/confluence/display/qpid/Java+Coding+Standards
> > [2]
> >
> >
> https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+JMS+Client+Coding+Standards
> >
>

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