Why? Because we want encourage new participants to feel comfortable contributing to the discussion, and private discussions tend to lead to "inner circles" (yes, we old hands can often start to shut out the newer members - not a good thing). Also, a public forum often becomes a great archive for all our past knowledge. Help us build our collective information!

• SearchEngine - This is a facade class that wraps the entire SearchEngine component.
• Query - This is a query class that is used when a user is creating a search. It is filled with the search terms and symbols he uses.
• SearchTerm - This is a search term used in a query, such as 'Thomas' or 'Sally.'
• Operator - This a search operator used in a query, like 'AND' or 'OR'.

The problem with these class names is that they are in a package called contactlist.search, which has many other class mixed in. Typically, when we list this directory in a terminal window, it's ordered alpahbetically, and what we see is this:

This list tells us nothing about what classes belong together. It's really quite a mess. So instead, we add 'group prefixes' to the names to put all classes of the same component together. So, to bring all the classes of the Query component together, we'd do the following:

But actually, the Optimizer class also belongs with the Query component as it is used to optimize the query. But if we simply add the 'Query' prefix to the class name, the Optimizer class will be mixed in with the search terms:

So, what we can do is to further group the class names into 'sub groups' by adding another prefix after Query:

Now, everything that should be grouped together is right next to one another. Yay!
But, as a last optimization (here's where the underscores come in), just using camel case can lead to confusion as to what the groupings are. For instance, for the QueryGrammarSearchTerm class, the groups and subgroups for this could be interpreted like this:

   Query / GrammarSearch / Term <-- Bad intepretation of groups!!

Which is not what we had intended! Just using camel case leads to ambiguous groupings. For a simple packages with just a few classes, this is not a big deal, but most packages tend to grow and grow, and things can get confusing quickly. So, we add underscores to separate the different group names to help clarify the different parts. This leads us to:

So, to interpret the name of this class, what we get is:

• Query - is the first-level group-name of the class.
• Grammar - is the second-level group-name for this class.
• SearchTerm - is the actual name of the class itself! This is important: the last part of a hierarchical name is the name of the class if it had no groups!

This is so important, we'll say it again - The last part of a hierarchical name is the name of the class if it had no groups! Once you get used it, it makes a lot of sense and is easy to understand. Just keep in mind the whole idea of grouping is to let us keep related classes together.

One question you may have is, 'Why don't you just move these related classes into their own package?' There are many reasons why you shouldn't do this. The main one is that moving a group of class into its own package should not be done just to keep the naming of classes clearer. Packages are a major organizational structure that actually changes the physical location of the classes. We should only be moving classes into a new package if there is a larger, more structural reason to do so!

This can be interpreted in two ways:

In this first interpretation, the method name is seen like this: 'search-terms database,' with an implied hyphen between 'search' and 'terms.' For this interpretation, the purpose for this method is that it simply returns the search-terms DB object.

But, another possible interpretation could be:

In this second interpretation, there is an implied hyphen between 'terms' and 'database,' which would result in an interpretation like this: 'search terms-database.' The possible purpose of this method would then be to perform a search on the terms database and return the search results. So, to clarify this method name, we can simply add underscores to separate the different parts:

Ah! Much better! The unambiguous interpretation of this method is that it does a search operation. Great!

Now, you might say this seems like overkill and you can often figure out the meaning of a method name by looking at the comments or the code, but this isn't always possible (often, the code is not available and/or the dev didn't write any comments). Also, when a class gets complex with maybe dozens of different search methods each with its own nuances, it can become even more difficult to interpret the name. The goal here is to make it as easy as possible for a new dev using this class to understand the meaning of any name. If using a few, well-placed underscores helps him avoid a few moments of frustration, we should probably spend a little time and add them in.