Boolean naming convention

I have a class that stores the data related to all employees in a particular department.
In this class, I am having a list of employees and other fields.
Also, I am having a property which returns a bool, indicating whether an employee exists or not. I am a bit confused regarding the naming of this property.

class Employee_Details
{
  #region Private Fields
  private List<Employee> employees;
  #endregion

  #region Fields
  // Gets a value indicating whether an employee exists
  public bool DoesEmployeeExists  // what should be the name of this property?
  {
    get
    {
      return this.employees.Any();
    }
  }
  #endregion      
}

Is the property name DoesEmployeeExists correct, or should I use any other name?

I would use simply HasEmployees.

In case of Boolean, I always try to use hasSomething or isSomething. In Java, many libraries use this strategy (it’s just a convention). And I like it, because it’s so easy to read when you see:

if(annoyingEmployee.isRemovable() && !annoyingEmployee.hasBirthday()) {
  manager.fireEmployee(annoyingEmployee);
} 

class Employee_Details

This class is badly named. First, .Net naming conventions say you shouldn’t use underscore for this, the class should be called EmployeeDetails. Second, the name seems to imply it contains details about a single employee. Better names would be EmployeesDetails or something like EmployeeList.

#region Private Fields

I don’t see any reason to use #region here, especially since it’s for a single field.

#region Fields

If you’re going to have regions, at least don’t lie in their descriptions. This #region contains properties, not fields.

// Gets a value indicating whether an employee exists

Consider using XML documentation comments. That way, the IDE (and other tools) can understand them.

public bool DoesEmployeeExists

I think a better name is indicated by the implementation: AnyEmployees. But probably even better name would be a negated one: something like NoEmployees or Empty.

Also consider whether this property actually makes sense. I think a better option would be exposing the private list as something like IEnumerable<Employee> or IReadOnlyList<Employee>, which you probably have to do anyway. That way, any user of your class can run any query they want on the list, and you won’t have to create separate properties or methods for each kind of query.

First, @svick is absolutely right about the class name, regions and xml comments.

But to address your basic question, I would have the class implement either ICollection or IList depending upon how you use the rest of the class. If neither works for you, consider Count… but I wuld really go with IList, as that would allow them to get the answer without you doing much at all other than providing some wrappers around your private variable.