+1. Makes svn blame useless by creating a date in time when everything was touched.
On Thu, Jan 23, 2014 at 10:07 AM, sebb <seb...@gmail.com> wrote: > 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 > >
