Honestly, they both look fine, but they do impart different meanings. "Staff" implies a set of employees dedicated to something like a company or project whereas "employees" could refer to multiple employees in any context.
If you're walking on to a new project, these subtleties make all the difference in understanding what's going on without having to rely on documentation.
In my case, we have anywhere from 3 to 20+ types of employees, and "staff" is the word commonly used to refer to one of those classifications. Certain information requires different levels of protection for some of those classifications. While people can transition between classifications, it's not a very common occurrence, and it only makes handling their information more difficult (and the old classification may apply to the information for a specific period of time after the change, or indefinitely for some types of data).
I basically end up with a "people" table which holds a very small amount of common data and is used in a lot of relationships.
Honestly, the distinctions require a great deal of documentation to fully understand. However, making the data less normalized and a little harder to comprehend also protects new people from making honest mistakes which could lead to legal issues.
> and probably call your collection employees.
Really ? IMHO this is a bad practice : it makes the code les readable and breaks the auto-completion ...
Doesn't break autocomplete in Visual Studio 2015...
What would you call it?
Which is better?
foreach (var employee in staff) {
}
or
foreach (var employee in employees) {
}