title: Best Practice List/Array/ReadOnlyCollection creation (and usage)
body: <p>My code is littered with collections - not an unusual thing, I suppose.  However, usage of the various collection types isn't obvious nor trivial.  Generally, I'd like to use the type that's exposes the "best" API, and has the least syntactic noise.  (See <a href="https://stackoverflow.com/questions/570083/best-practice-when-returning-an-array-of-values-net">Best practice when returning an array of values</a>, <a href="https://stackoverflow.com/questions/4337393/using-list-arrays-best-practices">Using list arrays - Best practices</a> for comparable questions).  There are guidelines suggesting what types to use <strong>in an API</strong>, but these are impractical in normal (non-API) code.</p>
  
  <p>For instance:</p>
  
  <pre><code>new ReadOnlyCollection&lt;Tuple&lt;string,int&gt;&gt;(
      new List&lt;Tuple&lt;string,int&gt;&gt; {
          Tuple.Create("abc",3),
          Tuple.Create("def",37)
      }
  )
  </code></pre>
  
  <p><code>List</code>'s are a very common datastructure, but <strong>creating them in this fashion involves quite a bit of syntactic noise</strong> - and it can easily get even worse (e.g. dictionaries).  As it turns out, many lists are never changed, or at least never extended.  Of course <code>ReadOnlyCollection</code> introduces yet more syntactic noise, and it doesn't even convey quite what I mean; after all <code>ReadOnlyCollection</code> may wrap a <em>mutating</em> collection.  Sometimes I use an array internally and return an <code>IEnumerable</code> to indicate intent.  But most of these approaches have a very low signal-to-noise ratio; and that's absolutely critical to understanding code.</p>
  
  <p>For the 99% of all code that is <em>not</em> a public API, it's not necessary to follow Framework Guidelines: however, I <em>still</em> want a comprehensible code and a type that communicates intent.</p>
  
  <p><strong>So, what's the best-practice way to deal with the bog-standard task of making small collections to pass around values?</strong>  Should array be preferred over <code>List</code> where possible?  Something else entirely?  What's the best way - clean, readable, reasonably efficient - of passing around such small collections?  In particular, <strong>code should be obvious</strong> to future maintainers that <em>have not</em> read this question and don't want to read swathes of API docs yet still understand what the intent is.  It's also really important to <strong>minimize code clutter</strong> - so things like <code>ReadOnlyCollection</code> are dubious at best.  Nothing wrong with wordy types for major API's with small surfaces, but not as a general practice inside a large codebase.</p>
  
  <p>What's the best way to pass around lists of values without lots of code clutter (such as explicit type parameters) but that still communicates intent clearly?</p>
  
  <p><strong>Edit:</strong> clarified that this is about making short, clear code, not about public API's.</p>