I agree with the comments about this being what a set is for - but it's also the case that prior to version 3.5, .NET didn't have a set type. The closest you could easily get (using just the built-in libraries and not writing your own set) was a dictionary where the value is irrelevant.
However, I wonder whether for just 30 strings in .NET earlier than 3.5, a List<string>
might not be the ticket. We know that hashsets work really well for big sets, but if you know you're using a small set of strings, a simple List<string>.Contains
call will be fairly quick. String.Equals
can check lengths to start with, and then check each character so it's probably going to reject non-matches very quickly.
In short, I'd probably use HashSet<string>
if you're using .NET 3.5, List<string>
if you're using .NET 2.0 or 3.0, and possibly ArrayList
if you're using .NET 1.1. That should give the simplest possible calling code, and the performance is likely to be fine. If you believe it's becoming a bottleneck, prove it with a profiler.