novedades - new features c#
¿Qué es más legible? (21)
Tengo estos dos códigos, ¿cuál es más legible?
para cada
decimal technicalPremium = 0; foreach (Risk risk in risks) { technicalPremium = technicalPremium + risk.TechnicalPremium; } return technicalPremium;linq
return risks.Sum(risk => risk.TechnicalPremium);
Creo que depende de lo que quieres 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ás tomando una matriz (u otro tipo de colección) y ejecutando un método llamado 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.
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, me preocupa un poco la facilidad de la 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.
Cada idioma tiene convenciones para la mejor manera de codificar tales cosas, por lo que lo que es 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.
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í).
Diría que es el primero 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.
Diría que la primera parte del código es definitivamente más legible, y sería aún más legible si cambiaras el nombre del 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.
El código LINQ es muy legible y autodocumentado.
El primero si no tienes conocimiento de Linq. Cualquier desarrollador puede leer y comprender el primero.
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.
Ninguno. El primero 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.
Yo diría que puedes basar tu elección en el entorno en el que te encuentras.
No hay problema de legibilidad aquí. Haga clic en Sum y presione F1.
Linq por la victoria.
No sé c # pero la segunda alternativa me parece mucho más limpia y pude entender lo que hace (vale, con algunas conjeturas y verificaciones cruzadas 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.
Para alguien que puede leer LINQ, el LINQ.
Para alguien que tiene que interpretar el código paso a paso (usando intellisense / documentation el más corto).
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.
Si proporciona un comentario que explique su propósito, entonces elegiría la opción Linq.
Si su objetivo es hacer 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 siga usando VS2005 o anterior, la sintaxis de linq sería confusa.
Utiliza el que prefieras pero ocúltalo en un método:
return risks.SumTechnicalPremium();
Ve 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á.
o
decimal technicalPremium = 0;
foreach (riesgo de riesgo en riesgos) technicalPremium = technicalPremium + risk.TechnicalPremium;
devolver tecnicoPremio;
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í.
Veo gente diciendo que les gusta el primero "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 / marco / 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 " nunca hacer tipos de valores mutables " y " no molestarse con propiedades triviales para miembros no públicos ".
Mientras Linq no esté en su lista de "exclusión", el segundo ejemplo es mucho 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.