.net - Las mejores formas de dar formato a las consultas LINQ.

formatting code-readability

Question

Antes de que ignore / vote-to-close esta pregunta, considero que es una pregunta válida porque la claridad del código es un tema importante de discusión, es esencial para escribir un código mantenible y agradecería enormemente las respuestas de aquellos que lo han encontrado antes .

Recientemente me he encontrado con este problema, las consultas LINQ pueden ser bastante desagradables muy rápido debido a la gran cantidad de anidamiento.

A continuación se muestran algunos ejemplos de las diferencias en el formato que he encontrado (para la misma consulta relativamente no compleja)

Sin formato

var allInventory = system.InventorySources.Select(src => new { Inventory = src.Value.GetInventory(product.OriginalProductId, true), Region = src.Value.Region }).GroupBy(i => i.Region, i => i.Inventory);

Formato elevado

var allInventory = system.InventorySources
    .Select(src => 
        new { 
            Inventory = src.Value.GetInventory(product.OriginalProductId, true), 
            Region = src.Value.Region })
                .GroupBy(
                    i => i.Region, 
                    i => i.Inventory);

Formato de bloque

var allInventory = system.InventorySources
    .Select(
        src => new 
        { 
            Inventory = src.Value.GetInventory(product.OriginalProductId, true), 
            Region = src.Value.Region 
        })
        .GroupBy(
            i => i.Region, 
            i => i.Inventory
        );

Formato de lista

var allInventory = system.InventorySources
    .Select(src => new { Inventory = src.Value.GetInventory(product.OriginalProductId, true), Region = src.Value.Region })
    .GroupBy(i => i.Region, i => i.Inventory);

Quiero crear un estándar para el formato de linq para que maximice la legibilidad y la comprensión y se vea limpio y profesional. Hasta ahora no puedo decidir, así que dirijo la pregunta a los profesionales aquí.

Answer 1

Es muy subjetivo.

Yo uso el método de formato de bloque.

También verifico el código de Stylecop y me aseguro de que no muestre ninguna advertencia de stylecop.

Answer 2

Me he decidido por el formato de bloque. Molestó mi sentido de "espacio desperdiciado" por un tiempo, pero al final todos sintieron que era más legible para más personas. Como ya estábamos poniendo llaves en nuevas líneas, encajaba mejor con el resto del código. También hay menos espacio para la interpretación. Mantenemos un archivo cs en la tienda pública que tiene ejemplos de formato ... cuando a alguien se le ocurre un trozo único de linq, lo agregamos al archivo ... realmente ayuda a los nuevos.

Answer 3

Mi formato:

var allInventory = system.InventorySources
  .Select(src => new
  {
    Inventory = src.Value.GetInventory(product.OriginalProductId, true),
    Region = src.Value.Region
  })
  .GroupBy(
    i => i.Region,
    i => i.Inventory
  );

Notas:

• Los parentes de apertura sobre métodos nunca son dignos de una nueva línea.
• Los parens de cierre coinciden con la sangría de la línea que contiene el paren de apertura.
• Src => new permanece en la misma línea que Select, porque simplemente no es digno de una nueva línea.
• El tipo anónimo siempre recibe un tratamiento de bloque, como si se usara fuera de una consulta (pero el paren de cierre no es digno de una nueva línea).
• Los dos parámetros de la sobrecarga de GroupBy no se suelen llamar. Aunque podría caber fácilmente en una sola línea, use una línea adicional para aclarar que algo inusual está sucediendo.

Answer 4

Para mí, depende de la longitud de la consulta que tengo que hacer. Para declaraciones breves y simples como una selección básica o uniones simples, iré con el Formato de lista porque lo hace agradable y fácil de leer sin colocar mi código sobre un montón de líneas.

Si tiendo a tener una instrucción linq bastante compleja o más grande, utilizo el formato de bloque para que sea más fácil para otras personas leer y seguir lo que estaba tratando de hacer.

No creo que sea una mala práctica tener un formato diferente para diferentes afirmaciones, siempre y cuando sea coherente con la forma en que lo aborda.