Interesting question, Manfred. Here are the answers:

Count of java files is done via:
  find . -name ".svn" -prune -o -name "target" -prune \
    -o -name "*.java" -print | wc -l

Count of java files with tabs is done by running "detab1.sh" (which just
fixes tabs) then:
 svn status | grep "^M" | wc -l

Count of java files with tabs or trailing whitespace is done by running
"detab.sh" then svn status as above.

shared/trunk:
# of java files:  396
# of files with tabs: 25
# of files with tabs/trailing spaces: 51

shared/trunk12:
# of java files:  390
# of files with tabs: 31
# of files with tabs/trailing spaces: 133

core/trunk:
# of java files:  351
# of files with tabs: 78
# of files with tabs/trailing spaces: 216

core/trunk12:
# of java files:  503
# of files with tabs: 120
# of files with tabs/trailing spaces: 385


It's interesting how many more classes there are in jsf1.2 than in
jsf1.1. Some of this is due to more unit tests, but much appears to be
real new classes needed to implement the extended spec.




On Wed, 2008-07-02 at 20:12 +0200, Manfred Geiler wrote:
> Simon,
> Do you have a number? How many files do have tab characters?
> I think (b - fix them) would be the better solution. But only if that
> does not change every second file.
> --Manfred
> 
> 
> On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> > Hi All,
> >
> > In the new checkstyle rules file I enabled checks for tab characters, as the
> > myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the
> > checkstyle report points out a lot of files containing tabs.
> >
> > It's no big deal, but do we want to:
> > (a) disable the checkstyle rule and ignore tabs or
> > (b) fix them?
> >
> > Tabs are a minor nuisance when viewing the source as some tools render 4
> > spaces, some 8.
> >
> > I've written a simple shellscript that can clean this up very easily, and am
> > happy to do so. The script also removes trailing whitespace from lines, of
> > which we also appear to have quite a lot.
> >
> > But doing this will create some large commit messages and make comparing
> > files with past versions noisier. It can also cause svn conflicts if people
> > have modified files they have not yet committed, unless they run the cleanup
> > script against their own working dir before doing svn update.
> >
> > So, option (a) or (b)?
> >
> > Regards, Simon
> >
> >
> 
> 
> 

Reply via email to