2008-12-05 10 views
5

Mira lo prueba:que vuelven vacíos colecciones

[TestFixture] 
public class Quick_test 
{ 
    [Test] 
    public void Test() 
    { 
     Assert.AreEqual(0, GetByYield().Count()); 
     Assert.AreEqual(0, GetByEnumerable().Count()); 
    } 

    private IEnumerable<string> GetByYield() 
    { 
     yield break; 
    } 

    private IEnumerable<string> GetByEnumerable() 
    { 
     return Enumerable.Empty<string>(); 
    } 
} 

Cuando escribo métodos stub que utilizan generalmente la forma Enumerable.Empty de hacerlo. Me tropecé con un viejo código que escribí donde lo hice por el camino de rendimiento.

Esto me llevó a preguntarse:

  • que es atractivo visualmente más a otros desarrolladores?
  • ¿Hay problemas ocultos que nos hagan preferir uno sobre el otro?

Gracias!

+0

No relacionado directamente con la pregunta; pero como pareces usar MbUnit, hay una afirmación dedicada para verificar enumeraciones vacías: Assert.IsEmpty (GetByYield()). Es probablemente más legible que usar la aserción de igualdad clásica contra el número de elementos. –

Respuesta

6

yo preferiría cualquier método que ofrece la más clara lo que significa para el desarrollador. Personalmente, ni siquiera sé cómo se rompe el rendimiento ; línea es, por lo que volver a 'Enumerable.Empty(); `sería preferido en cualquiera de mis bases de código.

+2

I * do * sé lo que hace el salto de rendimiento, pero sigo creyendo que Enumerable.Empty() es una expresión de intento mucho más clara. –

1

Aún más rápido podría ser:

T[] e = {}; 
return e; 
+0

Eso nos choca desde los de una línea a dos. Tal vez esta sería otra alternativa a lo largo de ese mismo pensamiento? return new string [0]; – Rob

4

Enumerable.Empty: la documentación afirma que "almacena en caché una secuencia vacía". Reflector confirma Si el comportamiento de caché es importante para usted, existe una ventaja para Enumerable.Empty

Cuestiones relacionadas