If the commit says "sort members" that's a good tip ;) Some IDEs like Eclipse can compare class structures not just files.
The grouping of setter and getters together is one subjective ordering as would be grouping together the read methods separately from the write methods. I have one or more POV when I write code and yet other POVs when implementing use cases. I just do not see a subjective arrangement that is not tied to a specific use case, or even a single use case for an 80/20. Gary -------- Original message -------- From: sebb <seb...@gmail.com> Date:01/23/2014 13:07 (GMT-05:00) To: Commons Developers List <dev@commons.apache.org> Subject: Re: svn commit: r1560382 - /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java I think there is a big difference between creating a class with sorted methods, and retrospectively sorting methods in an existing class. That may improve the readibility of the class, or it may make the class much harder to read. For example with getters/setters: if these are kept together in pairs, then it is immediately obvious if one half is missing (deliberately or not). Not so easy to spot if one has to compare two long lists which are at nearly opposing ends of the alphabet. Unless the class is seriously messy, I would say leave well alone. It's very difficult to review the commit mails to be sure nothing was accidentally changed. It makes subsequent comparisons between versions much harder to do. It won't please everyone. On 23 January 2014 17:25, Paul Benedict <pbened...@apache.org> wrote: > Yes, and Gary's argument is a very high priority driver behind my > alphabetizing. I don't want to maintain groupings. I have concluded a long > time ago that my time is wasted doing that stuff in code. > > > On Thu, Jan 23, 2014 at 11:18 AM, Gary Gregory <garydgreg...@gmail.com>wrote: > >> Adopting a guideline like this is still a subjective arrangement. It's >> also takes time to maintain, not something I'm found of doing. To reach his >> own I suppose. >> >> G >> >> -------- Original message -------- >> From: sebb <seb...@gmail.com> >> Date:01/23/2014 09:15 (GMT-05:00) >> To: Commons Developers List <dev@commons.apache.org> >> Subject: Re: svn commit: r1560382 - >> /commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVPrinter.java >> >> On 23 January 2014 07:34, Emmanuel Bourg <ebo...@apache.org> wrote: >> > Le 23/01/2014 08:03, Benedikt Ritter a écrit : >> >> I personally don't like alphabetically sorted classes. For example if a >> >> public method calls a private method, I like to have the private method >> >> beneath the public method that uses it. This way I can read through a >> claa >> >> top to bottom without out to much jumping back and forth. But that's >> just a >> >> matter of taste, I guess. >> >> >> >> What do others think? >> > >> > +1 >> >> As far as methods are concerned, usually I find it helpful to group >> them into the following general sections: >> >> group + protected >> package >> private >> >> Within a group, alphaorder is not always the most appropriate - for >> example getter/setter pairs more naturally belong together. >> Also getter/setters are not generally the most interesting methods, so >> can be relegated further down the file. >> I prefer to see related methods together (which may involve mixing >> private/public in the same section) >> >> I don't see the point of sorting the methods just for the sake of it. >> If the methods are logically grouped it can make the code much easier to >> follow. >> >> As far as data items are concerned, I do find it easier if they are >> organised in sections. >> Even here, there may be private fields that relate directly to a >> public field, in which case they should be together. >> Within a data section, generally the fields should be sorted, but only >> within functional groups. >> >> I favour logical ordering rather than strict lexicographical ordering. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > Cheers, > Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
