There aren't any super clear reasons as why to use this type of syntax in the first place.
In general, try to avoid having having boolean arguments that at a distance may look arbitrary.
includeManagement will (most likely) affect the result greatly. But the argument looks like it carries "little weight".
The use of an enum has been discussed, not only will it look like the argument "carries more weight", but it will also provide scalability to the method. This might however not be the best solution in all cases, since your
ReturnEmployeeIds-method will have to scale alongside the
WhatToInclude-enum (see NiklasJ's answer). This might give you a headache later.
Consider this: If you scale the
WhatToInclude-enum, but not the
ReturnEmployeeIds-method. It might then throw a
ArgumentOutOfRangeException (best case) or return something completely unwanted (
null or an empty
List<Guid>). Which in some cases might confuse the programmer, especially if your
ReturnEmployeeIds is in a class-library, where the source-code is not readily available.
One will assume that
WhatToInclude.Trainees will work if
WhatToInclude.All does, seeing that trainees is a "subset" of all.
This does (of course), depend on how
ReturnEmployeeIds is implemented.
In cases where a boolean argument could be passed in, I try to instead break it up into two methods (or more, if needed), in your case; one might extract
ReturnRegularEmployeeIds. This covers all bases and is absolutely self-explanatory to whoever implements it. This will also not have the "scaling"-issue, mentioned above.
Since there are only ever two outcomes for something that has a boolean argument. Implementing two methods, takes very little extra effort.
Less code, is seldom better.
With this said, there are some cases where explicitly declaring the argument improves readability. Consider for instance.
GetLatestNews(10) is still pretty self-explanatory, the explicit declaration of
max will help clear up any confusion.
And if you absolutely must have a boolean argument, which usage cannot be inferred by just reading
false. Then I would say that:
var ids = ReturnEmployeeIds(includeManagement: true);
.. is absolutely better, and more readable than:
var ids = ReturnEmployeeIds(true);
Since in the second example, the
true might mean absolutely anything. But i would try to avoid this argument.