Ah, I expected a swift response about this. Luckily I'd already donned my tin hat :-)
On 4 June 2013 17:16, Rob Godfrey <[email protected]> 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 <[email protected]> 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 > > >
