qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robbie Gemmell <robbie.gemm...@gmail.com>
Subject Re: AMQP 1.0 JMS client - supplementary coding standards
Date Wed, 05 Jun 2013 09:53:26 GMT
For TODOs, I usually just consider them all roughly equally (in that there
should be a comment saying what needs changed and why) without any special
classification. I tend to closely examine all my changes prior to commit so
if I mean to change something I have added a TODO for before commiting then
I probably would have, so I'm not sure I personally see much specific value
in TODO-SVN. For TODO-RELEASE, that seems like more of a JIRA thing for me;
either we think the JIRA being worked on isn't finished and would comment
on it to say there was something specific needing done to allow completing
it, or we think it is done but there is need of a new separate JIRA
blocking the release.

I would tend to mostly echo the previous comments on the toString() etc
stuff.

Robbie

On 4 June 2013 16: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