A pattern of names you'll see in objecty code:
	* Parser parser = new Parser(...); parser.parse();
	* W''''''ebFetcher webFetcher = new W''''''ebFetcher(...); webFetcher.fetch("http://c2.com/cgi/wiki?RecentChanges");
	* ...and so on.
I consider it a smell, but I'm not sure if I'm justified. It's redundancy, to be sure... but is it the bad kind? What are your alternatives?

Looks to me as if the root cause of the odour here is not so much redundancy (that's merely the symptom) as sloppily chosen abstractions. How about this style:
	* Language''''''Statement e = new Expression(...); e.parse();
	* Document recentChanges = new Web''''''Document("http://c2.com/cgi/wiki?RecentChanges",...); recentChanges.fetch();

----

This is not a CodeSmell. It does not imply anything about the quality of the abstractions or structure of the code; it only reflects the arbitrary nature of available words in the vocabulary of the domain. For example, ''Pilot.controlAirplane()'' seems like a perfectly reasonable class/method name combination. But what if English didn't have the word 'pilot', or the programmer just didn't have that word in his/her vocabulary? Then the obvious choice would be ''Airplane''''''Controller.controlAirplane()'', which is exactly the same abstraction but would be a smell. Similarly, saying that ''General.command()'' is fine but ''Commander.command()'' smells doesn't make sense. Reorganizing the code to avoid these obvious and clear choices of class/method name would be inappropriate. ''This even applies to the page title itself. The word "Verber" here is used to refer to something that more commonly called an "agent". Is there a problem with A''''''gentNounDotVerb constructions?''

It could even be argued that, rather than being redundant, VerberDotVerb actually increases consistency and strengthens the relationship between class and method. After all, if you want to find the the parsing code in a program, you would look for a class named ''Parser'', and not for ''Expression'' or ''Language''''''Statement''. (In fact, I think ''Expression.parse()'' smells: expressions don't parse things.) For classes that only have one significant method, this pattern makes a lot of sense.

VerberDotVerb is a little ugly, especially when every class you have follows the pattern. But it doesn't signify anything fundamentally wrong that needs fixing.

----

VerberDotVerb constructs appear in my code when a class has one public method that does all of the real work. In that case, it makes sense to name the class Verber and the method Verb. Though I make the class name more specific when it's feasible, such as XmlParser.parse() -- JaredLevy

''If a class has only one public method, it should just be a function. ''ParseXml(...)'' is better than ''new XmlParser(...).parse().

----

Are you objecting to Fooer.foo() or fooer.foo()? A member function foo() of a class Fooer is probably not usually the best thing but I may choose to use: Baz fooer; fooer.foo(). I would use this if fooer is passed in as a parameter to a function that only cares that fooer has a method foo. -- AndrewQueisser

''More to the class one than the instance one. Though, I can't say I wouldn't sniff around if the instance one had the VerberDotVerb pattern. Why not use its class's noun name?''

----

It may say more about your choice of implementations than anything else. In C++, you would normally use operator (), such that
 Verber verber
 verber.verb(args)
becomes 
 Verber verb
 verb(args)
If the former smells, but the latter doesn't, this suggests to me that the VerberDotVerb pattern is a language smell, rather than a code smell.

----

See also : VerbSubject, CodeSmell, MethodObject, Execution in the Kingdom of Nouns http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html