For a few years I've been using notation on class names, for example IDisposable for interfaces and names like AbstractCollection for abstract classes but recently I stopped and started named classes only using terms in their domain. I believed this described the code and make it more understandable and in some ways it was. It was easy to see what kind of type the class with the cost of obscuring what the class is responsible for, classes also get alphabetically sorted so similiar classes are not next to each other in the package (having a greater number of classes in a package is useful since package scope can be enforced).
Another problem is that the class is less flexible to change, actually its usage is less flexible. If this coding standard is imposed and a class needs to become an interface or abstract then the class name needs to change everywhere that its used, in a whole bunch of files. This makes the code commit really ugly, in the worst case you don't own all of the code that used the class so its not possible to easily change it. As long as the class didn't have a public constructor then its quite viable to make a class abstract or an interface.
The deal breaker for me was when I started to use the eclipse java browsing perspective, an excellent write up can be found
here. After dabbling with
Pharo Smalltalk I started to wonder why this was preferred, after a couple of awkward days I found that it was much easier to use and showed me much more useful information, more concisely, including the class type information that I was encoding in the class name.
