# Is ToEnumerable<T> for multiple items a good practice?

In the similar vein as ToIEnumerable and FromSingleItem

Is this a good improvement for making lists on the fly?

SyntaxSugar.ToIEnumerable("test1","test2","test3");


vs.

new []{"test1","test2","test3"};


Code:

 public static class SyntaxSugar
{
public static IEnumerable<T> ToIEnumerable<T>(params  T[] items)
{
return items;
}
}


not technically an extension to prevent T clutter

Cons:

• longer codefragment

Pros:

• more finger friendly- no [] or {}
• Encapsulates the collection away from being treated as an array.

As developers we're pretty used to where the keys for all kinds of brackets, braces and parenthesis are and while I agree you may save (a negligible amount of) twists and turns of the wrist, you're just substituting keystrokes for keystrokes, IMO.

You've already made me (as a colleague) have to remember this exists, as opposed to what I know naturally within the language itself; I've no aversion to such a thing, obviously it is part of our job to build on things with the language, but only in cases where it is a concern - this really isn't a concern. Also, I now have to potentially type even more to get my list.

Or is it a concern?..

With all the other keystrokes required from day-to-day second-to-second that utilise modifier keys I think we can rule out the 'saving' this seems to want to achieve, when you look at it relatively.

On the other hand, for the most part we use a powerful IDE (I pity you if this isn't the case), any modern IDE will give you many shortcuts for productivity (such as Visual Studio's snippet insertion, Intellisense and auto-completion) which means we don't need to create unique constructs for such trivial concerns. Sure, it also means your construct can be utilised just as quickly, but becomes redundant as it isn't necessarily quicker. The argument could then be put forth that using these tools stands to mitigate human error.

And, what's wrong with an array? If you don't want something to be treated as an array, use a collection of different sorts.

• sure knowing where the keys are is not the issue, it's the headache of moving from the homekeys and back (and the related thought process interruption) multiple times, in addition to non-homekey shift modified keystrokes, typing errors while trying to do these maneuvers. – Maslow Apr 13 '11 at 19:09
• @Maslow I've updated my answer to further address keystrokes and and producivity [second last paragraph]. – Grant Thomas Apr 13 '11 at 19:29
• Thanks, I feel intellisense/autocomplete is superior to special symbols. I use interfaces (IList, IEnumerable,..) so I don't have to face [] often at all, resharper takes most of my {} typing out (or more than half with auto ( and { closures. I am doing these building sets from none deals a lot and hating it each time. @use a collection of different sorts.. if this is a collection from individual items, all other solutions/types to get to IEnumerable<T> would have the same or uglier construction. – Maslow Apr 13 '11 at 21:07
• @Maslow I just think it's unnecessary - and it's only really my opinion. :) – Grant Thomas Apr 13 '11 at 22:16

I'd kind of put it in the "marginally cool" basket. Its cool the language can do this stuff, but there is no real need to do it and won't really make anything clearer (and the typing advantage is incredibly negligible in this case). I would tend not to do this kind of stuff and opt for more vanilla code mainly because anyone who strikes this code the first time will be forced to go look at how ToIEnumerable is implemented to check it doesn't do some weird magic.