Tengo estos dos códigos, ¿cuál es más legible?¿Qué es más legible?
foreach
decimal technicalPremium = 0;
foreach (Risk risk in risks)
{
technicalPremium = technicalPremium + risk.TechnicalPremium;
}
return technicalPremium;
LINQ
return risks.Sum(risk => risk.TechnicalPremium);
Si el equipo que trabaja en el código sabe lo que hace la versión de LINQ y conoce su funcionamiento interno, entonces es más legible
Creo que la segunda opción es mejor ya que debería ser más eficiente. Sin embargo, es menos obvio lo que está sucediendo (al menos para mí).
En realidad, LINQ en general * agrega * sobrecarga - sin embargo, será tan marginal (especialmente en este caso) como para apenas importar. En este caso, agrega una invocación de delegado por artículo y una cantidad de saltos de pila. No perdería la calma, n. ° 2 para mí ;-p –
Para alguien que puede leer LINQ, el LINQ.
Para alguien que tiene que interpretar el código paso a paso (utilizando IntelliSense/documentación de la más corta.
El código LINQ es a la vez muy fácil de leer y auto-documentado.
Ni. La primera de ellas es más detallado y puede ser entendido por todos. El segundo es más conciso y fácil de entender por todos, incluso con un conocimiento pasajero de linq.
Diría que puedes basar tu elección en el entorno en el que te encuentras.
Ir con linq. Si crees que necesita una explicación, un comentario de una línea se encargará de eso. A medida que la gente se acostumbre a linq, la necesidad de comentarios desaparecerá.
Diría la primera ya que no sé linq. A riesgo de documentarlo en exceso, usaría ese con una breve descripción de lo que está sucediendo. O simplemente diga que es linq para personas que quizás no tengan idea.
La primera opción es más legible para un rango más amplio de personas. La segunda opción tiene una 'barrera de entrada' en el sentido de que el lector podría o podría conocer y comprender LINQ. Es más sucinto y, por lo tanto, podría ser mejor si su audiencia supera esa barrera de entrada.
Si proporciona un comentario explicando su propósito, entonces elegiría la opción Linq.
La primera si no tiene conocimiento de Linq. Cualquier desarrollador puede leer y comprender el primero.
Aquí no hay problemas de legibilidad. Haga clic en Sum y presione F1.
Linq para la victoria.
No es necesario presionar F1. Pase el mouse sobre la suma y obtendrá una información sobre herramientas que describe la función;) – OregonGhost
¿Quién utiliza el mouse? Oh, dije Click ... Supongo que me tienes, jaja. –
Cada idioma tiene convenciones para la mejor manera de codificar tales cosas, por lo que lo más legible para las personas que usan ese idioma regularmente no es universal. Para un programador Java o C# normal, la primera opción es más legible. Para alguien acostumbrado a LINQ o programación funcional, el segundo es más legible.
Si su "programador normal de C#" no entiende Linq, (s) tiene un problema. –
Bueno, "entender" LINQ y conocer los métodos de extensión que alguien acaba de agregar a la clase de la lista y que ni siquiera conocía es probablemente una diferencia. Mientras que un desarrollador de .NET 2.0 podría entender el .Sum, podría preguntarse de dónde viene ese método Sum ... – hangy
Uso lo que prefiera, pero lo ocultas en un método:
return risks.SumTechnicalPremium();
No sé C#, pero la segunda alternativa se ve mucho más limpio para mí y pude entender lo que hace (bueno, con un poco de adivinanzas y verificación cruzada con la primera versión). Probablemente debido a algunos antecedentes funcionales. Pero en el primero tienes que buscar Prémium técnico en 4 (!) Lugares. El segundo es mucho más corto y más fácil de entender si solo estás leyendo el código.
o
decimal technicalPremium = 0;
foreach (Riesgo de riesgo en los riesgos) technicalPremium = technicalPremium + risk.TechnicalPremium;
return technicalPremium;
Veo gente diciendo que les gusta la primera "si no conoces a Linq". Sí, y el primero es ilegible si no conoces C#. Esta no es una cuestión de "que sea más legible", sino "¿qué características del idioma nos son cómodas de usar?"
Comience por tener una conversación con su equipo sobre las partes del lenguaje/framework/conjunto de herramientas que todos odian y declare que están fuera de los límites. Todo lo demás se considera parte del vocabulario estándar, y se espera que todos sean fluidos. Esta lista debe ir en su documento de estándares de codificación, justo al lado de "never make mutable value types" y "don't bother with trivial properties for non-public members".
Mientras Linq no esté en su lista de "exclusión", el segundo ejemplo es ahora más legible que el primero. ¿Por qué? Porque declara la intención del código, en lugar de simplemente presentar el mecanismo para que el lector lo descifre.
Si su objetivo es que sea más legible para "cualquier persona" que pueda venir después de usted, utilice el foreach. Interpreto que "más legible" significa que cualquier persona con experiencia en lo básico del lenguaje debería ser capaz de entender. Para alguien que no esté familiarizado con linq y aún use VS2005 o anterior, la sintaxis de linq sería confusa.
Diría que la primera parte del código es definitivamente más legible, y sería aún más legible si renombrara al menos el riesgo variable para que tuviera un nombre diferente al de la clase. Probablemente también sería mejor si cambiaras el nombre de los riesgos de la matriz.
Estoy de acuerdo con aquellos que dicen que el segundo será fácil de entender a medida que Linq se adopte más ampliamente. Sin duda es más sucinto.
Sin embargo, tengo cierta preocupación por la facilidad de depuración. Parece mucho más fácil recorrer el código en el foreach, para ver exactamente lo que está haciendo en cada pase.
Creo que depende de lo que quiere decir con "legible". El primer ejemplo indica claramente la lógica del programa y debe ser comprensible para cualquier persona con un fondo de programación.
Para mí, el segundo ejemplo es más intuitivo en función del contexto (es decir, está tomando una matriz (u otro tipo de colección) y está ejecutando un método denominado Suma en cada elemento de esa matriz). El único lugar donde el segundo ejemplo puede ser menos claro es en la expresión lambda propiamente dicha, especialmente para alguien que no ha tenido experiencia con lambdas o alraedy que tenga experiencia en programación funcional.
Creo que a medida que las lambdas se vuelven más frecuentes en la programación de .NET esto se convertirá en un problema menor. Tal como está, creo que hay una curva de aprendizaje muy pequeña para entender los conceptos básicos de cómo usar expresiones lambda en .NET.
El segundo, definitivamente. Tener un bloque de código tan grande para hacer algo tan simple como sumar es simplemente innecesario. Tampoco sé qué es LINQ, pero es perfectamente legible para mí.
¿Por qué en ForEach no se usa + = en lugar de repetir la variable? –