First: do not modify debugged, working, efficient code for no reason. Your decision looks good.
However, we can make some improvements to your decision.
public static List<string> GetNameSegments(string filename)
Creating an output list leads to implementation restrictions that are not required by the caller. This should be an IEnumerable<String> . In particular, since the caller in this case only cares about the first match.
var segments = filename.Split('_', '-').ToList();
Why ToList ? The list supports an array. You already have an array. Just use an array.
Since you no longer need to create a list, we can convert your two-loop solution into an iterator block:
public static IEnumerable<string> GetNameSegments(string filename) { var segments = filename.Split('_', '-'); foreach (var segment in segments) yield return segment; foreach (var s1 in segments) foreach (var s2 in segments) if (s1 != s2) yield return s1 + s2; }
Much nicer. Alternatively, we might notice that this has a request structure and just returns the request:
public static IEnumerable<string> GetNameSegments(string filename) { var q1= filename.Split('_', '-'); var q2 = from s1 in q1 from s2 in q1 where s1 != s2 select s1 + s2; return q1.Concat(q2); }
Again, much nicer in this form.
Now let's talk about efficiency. As often happens, we can achieve greater efficiency by increasing complexity. This code looks to be fast enough . Your example consists of nine segments. Suppose nine or ten are typical. Our solutions still consider first ten or so singletons, and then a hundred or so combinations. It's nothing; this code is probably fine. But what if we had thousands of segments and considered millions of possibilities?
In this case, we must restructure the algorithm. One possibility would be this general solution:
public bool IsMatch(HashSet<string> segments, string name) { if (segments.Contains(name)) return true; var q = from s1 in segments where name.StartsWith(s1) let s2 = name.Substring(s1.Length) where s1 != s2 where segments.Contains(s2) select 1;
Your original solution is quadratic in the number of segments. It is linear; we rely on a standing order containing the operation. (This assumes, of course, that string operations are constant time, because the strings are short. If it is not, then we have another kettle of fish to fry.)
How else can winnings be obtained in the asymptotic case?
If we had the property that the collection was not a hash set, but rather a sorted list, we could do even better; we could binary search the list to find the beginning and end of the range of possible prefix matches, and then pour the list into a hashset to make suffix matches. This is still linear, but may have a lower constant coefficient.
If we become aware that the target line is small compared to the number of segments, we can attack the problem from the other end. Generate all possible combinations of sections of the target line and check if both halves are in the segment . The problem with this solution is that it is quadratic in memory usage in row size. So what we want to do is build a special hash on character sequences and use it to populate the hash table, rather than the standard string hash. I am sure you will see how the solution will go from there. I will not state the details.