On Wednesday, Aug 13, 2003, at 14:57 Europe/London, Mark Mahieu wrote:
[EMAIL PROTECTED] 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.
