geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Blewitt <Alex.Blew...@ioshq.com>
Subject Re: Suggested coding convention: sort methods
Date Wed, 13 Aug 2003 14:13:51 GMT
On Wednesday, Aug 13, 2003, at 14:57 Europe/London, Mark Mahieu wrote:

> Dirk.Weibel@ferguson.com wrote:
>
>> I'm also 1+ on consistant coding standards/conventions, regardless 
>> what form they take.  Maybe I'm missing something, but what's the 
>> difference between automatically enforcing style and manually 
>> refactoring a class to be in conformance with the standard?
> Depends on the environment.  In one like this which is heavily reliant 
> on identifying changes via line number references and diffs, any 
> code-reformatting not done 'centrally' is just asking for extra 
> hassle.  I'm not saying it /can't/ work though...
>
> Maybe the thing to do is look for some decent sized open source 
> projects which have attempted to standardize on more than just the 
> 'Sun coding conventions' and see how they've fared.  Anyone know any?

I don't think that centrally it is extra; once the majority of the code 
follows standard X, then the reformatting shouldn't change much.

There maybe a few big changes when it starts, but those will be akin to 
the amount of changes with an initial import; thereafter they don't 
change much.

The only reason I suggested formatting on name is that basically it's 
one of the few 'stable' sorts that can be done. A number of other 
conventions are used intermittently (such as associating get/set 
accesors, putting filelds near acessors, grouping together methods by 
interface) which may help with readability of code.

But most (all?) of these group-it-by-meaning conventions can fall over; 
for example, an accessor may be part of a JB proprety (get/set/field) 
and also a member of an interface (get only). Or it may be the case 
that there are some methods required by two or more interfaces.

Essentially, a convention that works sometimes but not other cases 
isn't something that should be used. A standard needs above all else, 
consistency.

The initial formatting (based on name, possibly subgrouping 
fields/methods etc.) is one that is stable; there aren't any cases when 
it doesn't work. (Yes, you still have to define if fields come at the 
top/bottom, but that's just choosing a flavour, in much the same was a 
2-3-4-5-spaces is better (delete where applicable))

Note that the reason for ordering /isn't/ to make it more readable, 
it's to make it generate significantly less diffs as it gets into the 
source code control system. A source file can be optimally sorted 
(using any mechanism, not just the name one) and if it is stable then 
there won't be anything that breaks it.

Anyway, that's why I suggested it -- I'm not trying to push it or say 
we should use it in this project, just food for thought.

Alex.


Mime
View raw message