Style question : sort members ?

[Ian Young]

On 13 Feb 2014, at 23:54, Cantor, Scott <cantor.2 at osu.edu> wrote:

> Just my personal style, but I've been consistently doing:
> 
> - Constructor

My recollection is that there is something (maybe Checkstyle) that already wants certain ordering constraints to be obeyed, and I think having any constructors before any other methods is one of them. So I do this too.

> - Get/Set pairs for bean properties (but only providing set unless get is
> really needed)

Ditto.

> - doInit/doDestroy/etc.
> - actual class methods

Interestingly, I've dropped into what I think is Chad's set of conventions for the MDA, which appears to group the lifecycle methods (other than constructors) at the end. I can definitely see a case for doing what you're describing, though. Maybe I'll switch.

On 13 Feb 2014, at 23:50, Tom Zeller <tzeller at dragonacea.biz> wrote:

> Maybe take a look at n.s.i.service.ReloadableSpringService in
> idp-core, and suggest where the beanName field, setBeanName() and
> doInitialize() methods, which were added to implement BeanNameAware,
> should be moved to ?

Fields first, and again I believe that Checkstyle, or maybe part of Eclipse, has something to say about this already. I normally order these alphabetically when I don't have anything else to group them by.

Getters/setters next, normally in the same order as the associated fields.

I currently put the lifecycle methods right at the end, because Chad did that in the code I took over from him, but I think Scott's argument that they are better grouped just after the constructors makes sense.

> I just tacked the methods on at the end, semantically meaning "added last".

That's obviously not giving you any useful information when you look at the code again in a year's time, so I personally wouldn't use a scheme like that. I kind of assume you're joking, actually.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20140219/0d7a2371/attachment.bin