Estándar de nomenclatura de LINQ - Expresión de Lambda

Question

Normalmente seguimos el estándar de codificación/nomenclatura para todas las sintaxis de C#. Por ejemplo, si declaramos cadena dentro del método, usamos el formato Scope-datatype-FieldName. (lstrPersonName)

List<Person> icolPerson; 
private LoadPersonName() 
{ 
    string lstrPersonaName; 
} 

estoy pensando en cómo seguimos el estándar de nombres en Lambda Expression. Especialmente cuando definimos los argumentos para el delegado de func, usamos nombres en corto como x. Por ejemplo

var lobjPerson = icolPerson.Where(x => x.person_id = 100) 

Si mira la línea de arriba, X no sigue ningún estándar. También leí que un propósito de la expresión lambda es reducir el código largo.

estoy aquí para buscar ayuda para obtener el enfoque correcto para nombrar el estándar.

var lobjPerson = icolPerson.Where(x => x.person_id = 100) 

O

var lobjPerson = icolPerson.Where(lobjPerson => lobjPerson .person_id = 100) 

Answer 1

He realizado una gran cantidad de programación en VBScript (ASP), y allí el uso de la notación húngara para realizar un seguimiento del tipo de datos fue crucial para mantener la cordura. En un lenguaje tipo seguro como C#, no encuentro uso alguno para usar la notación húngara de esa manera.

Los nombres de variables descriptivas hacen mucho por la legibilidad del código, pero no siempre tiene que describir cada aspecto de una variable. Un nombre como persons indica que se trata de una colección de objetos personales, ya sea un List<Person> o IEnumerable<Person> que generalmente no es tan importante para entender qué está haciendo el código, y el compilador le dice inmediatamente si está intentando hacer algo completamente incorrecto.

Uso con frecuencia nombres de variable de una sola letra, donde el alcance de la variable es muy limitado. Por ejemplo, la variable de índice i en un bucle pequeño o en expresiones lambda.

Answer 2

No hay el enfoque correcto en absoluto. Naming estándar como cualquier otro estándar de codificación (como espacios y nuevas líneas después/antes de expresiones) es una convención dentro del grupo. Así que solo escriba su código como desee y como debería hacerlo en su empresa. ¡Pero hazlo constantemente!

prefiero usar prefijo de subrayado en los nombres de los campos privados. pero su estilo (visibilidad + tipo + nombre) me parece una cita antigua de código WInAPI (notación húngara) =).

Answer 3

por lo general sólo tiene que utilizar la primera letra del tipo que estoy consultando por lo que en su caso ya que es de tipo Persona que haría:

var lobjPerson = icolPerson.Where(p => p.person_id = 100); 

Otro ejemplo si era decir tipo Car lo haría:

var lobjCar = icolCar.Where(c => c.car_id = 100); 

lo hago por la rapidez, sin embargo, no creo que haya nada malo utilizando nombres completos en la consulta es decir car => car.car_id

Answer 4

Como lon Como su expresión lambda es solo una declaración, mantendría el nombre de la variable lo más breve posible. El objetivo general de nombrar es hacer que el código sea legible, y en estos casos, el nombre del método y el contexto general deberían ser suficientes.

No es necesario que use x todo el tiempo. Para un objeto Person, tendería a usar p en su lugar.

Si necesita escribir una expresión más compleja que incluya llaves y puntos y comas, diría que se aplican todas las reglas de nombres normales.

Answer 5

Creo que el estándar de nomenclatura que usas (notación húngara) era la necesidad de la hora cuando las herramientas de alto perfil como Visual Studio no estaban presentes. Hoy tienes tecnologías como Intellisense que te dicen la mayoría de las cosas que estás haciendo mal con una variable mientras escribes, como asignar un int a una cadena. Por lo tanto, a partir de hoy, no es una parte exclusiva de las buenas convenciones de codificación o estándares como solía ser. La mayoría de las personas siguen la envoltura pascal o la envoltura de camello en estos días. Si alguien lo usa, creo que es más por una preferencia personal.

Habiendo dicho eso, según la forma en que codifique y nombre sus variables, debe seguir el segundo enfoque. De nuevo, esto se reduce a tu preferencia personal.

PD: Este comentario no significa que estoy mirando hacia abajo en su uso de la notación húngara. :)

Answer 6

Mis lambdas utilizan uno los argumentos de la letra, por lo general la primera letra de lo que sería el nombre del parámetro:

• buttons.Select(b => b.Text);

• services.Select(s => s.Type);

Pero a veces añado unas pocas letras más para aclarar las cosas, o para desambiguar entre dos parámetros.

Y cuando no hay mucho significado que se atribuye a las cosas que uso x s y y s:

• values.Aggregate((x, y) => x + y);

Todo dicho, el estándar que utilizo para lambda es la falta en primer lugar, expresividad más tarde, porque el contexto tiende a ayudar a entender las cosas (en el primer ejemplo es obvio que el b representa un botón).

Answer 7

Si su colección se llama algo- persons, entonces es obvio que cuando está haciendo persons.Where(p => p.Whatever) que p es una persona. Si tus lambdas son tan complicadas que no es inmediatamente obvio cualesquiera que sean los parámetros que estás usando, entonces no deberías usar lambdas en absoluto, o hacer que sean drásticamente más simples.

En cuanto a sus otras convenciones, ¿de qué sirve usar húngaro para llamar a que personName es una cadena? Es obvio que un nombre sería una cadena. ¿Y por qué necesitas un prefijo para recordarte que una variable es un local? Su declaración es necesariamente en el mismo método, por lo que no puede ser hace tanto tiempo que ya lo ha olvidado. Si tiene, entonces sus métodos son demasiado largos o complejos.

Simplemente haga que sus identificadores describan apropiadamente qué es que significa de la variable, entonces el resto será obvio.

Answer 8

LINQ no es solo para los desarrolladores que solían escribir consultas para bases de datos sino también para los programadores funcionales.

Así que no se preocupe si no está muy cómodo con el tipo de consultas SQL, tenemos una opción muy buena llamada "Expresión Lambda".

Aquí voy a demostrar el escenario para ambas opciones con un pequeño ejemplo. Este ejemplo tiene una matriz de enteros y solo estoy recuperando los números pares usando el poder de LINQ.

Aquí vamos

using System; 
using System.Collections.Generic; 
using System.Text; 
using System.Query; 
using System.Xml.XLinq; 
using System.Data.DLinq; 

namespace LINQConsoleApplication1 
{ 

class Program 
{ 
    static void Main(string[] args) 
    { 
     int[] arrInt = {1,2,3,4,5,6,7,8,9,10}; 

     #region Place to change 

     //Language Integrated Query 

     var aa = from s in arrInt 

       where s % 2 == 0 
       select s; 

     #endregion 

     foreach (var item in aa) 
     { 
      Console.WriteLine("{0}", item); 
     } 

     Console.ReadKey(); 

    } 

} 

} 

Si no desea utilizar el enfoque diferente de la consulta de la Lengua entonces usted es libre de utilizar la expresión Lambda.

Así que simplemente reemplace el área #region con los siguientes resultados del bloque de código serán idénticos.

 #region Place to change 

     //Lambda Expression 

     var aa = arrInt.Where(s => s % 2 == 0); 

     #endregion