Cees de Groot wrote:
> 
> Doug Way <dway at riskmetrics.com> said:
> >The Java project I'm working on strictly uses approach B.  There are *no* duplicate classnames among 1000 or so classes across many packages in the app.  A few imported classnames from other frameworks conflict, but very rarely.  (Two different external packages each had their own implementation of a Date object, which was confusing.)
> >
> Just to add a data point: in my current VW project, with some 400 classes and
> no 'thou shall not make up duplicate names' rule, we have one duplicate name
> and that has attended us to the fact that the name in fact was a bad name for
> both classes (FooBarProcessor, 'Processor' being much too
> abstract/generic/whatever). In Java, I used to have similar metrics.

Actually, I should correct my earlier point a bit... we do have one case of duplicate classnames.  Each of our packages/modules has a class called TestCase which handles unit tests.  This class name is the same for all packages.  This sort of name duplication makes sense, though, since it's a class that performs the same function for every package.

- Doug Way
  dway at riskmetrics.com