Actualmente hay un debate local en cuanto a qué código es más legibilidadcódigo .NET legibilidad y mantenibilidad
Tenemos un programador que viene del fondo de CA y cuando que los códigos de programador que parece
string foo = "bar";
if (foo[foo.Length - 1] == 'r')
{
}
tenemos otro programador que no le gusta esta metodología y prefieren utilizar
if (foo.EndsWith("r"))
{
}
qué manera de hacer este tipo de operaciones es mejor?
EndsWidth es más legible para alguien que nunca ha visto C o C++, C# o cualquier otro lenguaje de programación.
Cierto, pero ¿por qué alguien que nunca ha visto C, C++, C#, Objective-C, Java, Perl, PHP o cualquier otra derivada C intenta descifrar el código? Y recuerde, cualquiera que haya estado codificando en Python o VB estos días habrá visto uno de estos idiomas en algún momento. – Dinah
+1 porque esto no es C, e incluso me gusta C. –
@Dinah, considera una persona que ha hecho Java pero está viendo C#. Una cadena == no es lo mismo entre los dos idiomas. "EndsWith" es menos ambiguo. – statenjason
Vengo de un fondo C/C++ y yo voto por Endswith!
El segundo es más declarative in style pero no puedo decir con objetividad si es más legible la legibilidad de los senos es muy subjetiva. Personalmente, encuentro el segundo más legible, pero esa es solo mi opinión.
Aquí es un extracto de mi artículo:
más desarrolladores de C# están muy familiarizados con la escritura de código imperativo (incluso a pesar de que no lo sepan por que nombre). En este artículo, voy a presentarle un estilo alternativo de programación llamada declarativa programación. El código declarativo correcto es más fácil de leer, comprender y mantener.
Como profesionales, deberíamos estar esforzándonos para escribir mejor código cada día . Si no puedes mirar el código que escribiste hace tres meses con un ojo crítico y notas cosas que podrían ser mejor, entonces no has mejorado y no te están desafiando. I le desafío a escribir el código que es más fácil de leer y entender mediante el uso del código declarativo .
Bonita publicación de blog. El tema más común en la publicación: haz que tu intención sea lo más clara posible y la programación declarativa te ayuda a hacerlo. – Thomas
@AndrewHare ¿el enlace a su blog aún está disponible? No puedo acceder – nawfal
Le gustaría leer el blog ... ¡el enlace de arriba es 404! –
Creo que la segunda forma es mejor porque es más fácil de leer y porque la primera duplica la lógica del método EndsWith que es una mala práctica.
IMO, la intención del autor original es más clara en el segundo ejemplo. En el primero, el lector debe evaluar lo que el autor intenta lograr al obtener el último índice. No es difícil, pero requiere un mayor esfuerzo por parte del lector.
EndsWith es probablemente más seguro. Pero el indexador es probablemente más rápido.
Endswith probablemente verifique si la cadena de entrada está vacía. Probablemente ambos lanzarán excepciones de referencia nulas. Y el indexador fallará si la longitud es 0.
En cuanto a la legibilidad, ambos me dicen lo mismo, pero he estado programando por un tiempo. El .EndsWith(...) es probablemente más rápido de entender sin tener en cuenta el contexto.
Gracias votar abajo. ¿Qué tal un comentario? Estaba señalando que el código no es realmente el mismo (y estaba revisando mi declaración cuando votaste). –
Hace más o menos lo mismo. Sin embargo, se vuelve más complicado con más de un personaje en el argumento endswith. Sin embargo, el primer ejemplo es un poco más rápido ya que no usa funciones reales y, por lo tanto, no requiere pila. Es posible que desee definir una macro que pueda usarse para simplemente uniformizar todo.
¿Estás seguro de que el # 1 es más rápido? Esperaría que el compilador de C# hiciera automático [enlining] (http://en.wikipedia.org/wiki/Inline_expansion) en # 2. –
La pregunta es sobre la mantenibilidad. Elegir uno de estos "estilos" para el rendimiento es una micro-optimización que nunca valdrá la pena tan pronto como un programador gaste unos segundos extra tratando de entender lo que hace. –
@ Jørn Schou-Rode: El compilador no alineará nada. El JITer puede, pero depende de muchas cosas, incluida la cantidad de código detrás de la llamada al método. –
Ambos enfoques son válidos, pero el método endswith es más fácil de leer en mi opinión. También elimina el potencial de cometer errores de tipeo, etc. con la forma más complicada.
Creo que el criterio principal debería ser cuál de estos dice más claramente lo que el desarrollador quiere hacer. ¿Qué significa cada muestra realmente decir?
1) Acceder al carácter en el que uno menos que la longitud, y comprobar si es igual al personaje 'r'
2) Comprobar si termina con la cadena "r"
creo que deja en claro cuál es la respuesta más fácil de mantener.
A menos y hasta que no afecte el rendimiento del programa, no hay problema que pueda usar de cualquier manera. Pero agregar comentarios de código es muy importante para transmitir lo que se está logrando.
El primero necesita un comentario y el segundo no. – Adrian
"código está escrito para ser leído por los seres humanos y dicho sea de paso dirigido por computadoras" SICP
EndsWith FTW !!
Bondad,
Dan
Desde el punto de vista de manejo de errores, EndsWith.
Creo que la respuesta correcta sería la correcta. EndsWith devuelve correctamente false para la entrada de cadena vacía, mientras que la otra prueba arrojará una excepción tratando de indexar con -1.
Prefiero la segunda versión (EndsWith). ¡Es lo suficientemente claro como para que incluso mi gerente lo entienda!
El número 2 es mejor para leer y mantener. Ejemplo: verificar los 2 últimos caracteres ...
opción 1)
if (foo[foo.Length - 1] == 'r' && foo[foo.Length - 2] == 'a')
{
}
opción 2)
if (foo.EndsWith("ar"))
{
}
últimos 3? ¿últimos 4? ...
Haría esto: if (foo.substring (foo.Length-2,2) == "ar") – 37Stars
Reglas de legibilidad, especialmente si esto implica intento.
Con el primer ejemplo, debo descubrir la intención, que queda para la interpretación. Si parece tener un error, ¿cómo sé que no es intencional?
El segundo ejemplo me dice la intención. Queremos encontrar el personaje final. Armado con ese conocimiento, puedo proceder a evaluar la implementación.
No solo End es más legible, sino también más "correcto". Como regla general, si hay un método de marco proporcionado para hacer el trabajo ... úselo.
¿Qué pasa si foo == string.Empty?
tratando de encontrar una respuesta en este sentido, si no lo iba a escribir yo mismo. aquí está todo el camino en la parte inferior! – BritishDeveloper
La mejor práctica es escribir código que sea fácil de leer. Si utilizó el primero, los desarrolladores que están depurando su código pueden decir: "¿Qué intenta hacer este desarrollador?" Necesita utilizar métodos que se explican fácilmente. Si un método es demasiado complicado de entender, retire varios métodos de él.
Sin duda diría que la segunda, legibilidad y simplicidad son la clave!
Además, si el "if" tiene una línea, no incomoda el uso de llaves, utilice una sangría SOLA
'si el enunciado" si "tiene una línea, NO DEJE DE USAR BRAZOS, UTILICE UNA INDICACIÓN INDIVIDUAL', este es realmente un consejo arbitrario que ni siquiera justificó. No sabe cuándo el bloque "si" crecerá en más líneas. Si lo hace en otra rama, puede obtener un conflicto de combinación. Omitir frenillos también puede conducir a errores - ver http://stackoverflow.com/questions/359732/why-is-it-considered-a-bad-practice-to-omit-curly-braces para ver un montón de ejemplos. El estilo de codificación es una cuestión de gusto, pero no deberíamos presentar nuestras preferencias como un dogma, especialmente sin respaldarlas con ningún razonamiento. –
sí ... esto fue hace casi 4 años. He aprendido mucho desde entonces. gracias sin embargo! – Mike
Lo sé, puede ser un largo tiempo en la programación :) –
Hay que recordar que en el clásico C, la única diferencia entre una "cadena" y una serie de caracteres es la terminación del carácter nulo '\ 0', por lo que tuvimos que tratarlos de manera más activa en consecuencia y asegurarnos de que no nos fuéramos al final de la matriz. Entonces, el primer bloque de código basa su proceso de pensamiento en el concepto de una matriz de caracteres.
El segundo bloque de código basa el proceso de pensamiento en cómo manejar una cadena de forma más abstracta y con menos atención a su implementación bajo las cubiertas.
En pocas palabras, si está hablando de procesar caracteres como la idea principal detrás de su proyecto, vaya con la primera pieza. Si está hablando de preparar una cuerda para algo mayor y que no necesariamente tiene que enfocarse en la mecánica de las formas en que se construyen las cuerdas, o simplemente quiere hacerlo simple, vaya con el segundo estilo.
Parte de esto puede resumir las contribuciones de otros en este punto, pero de forma más análoga, ¿estás jugando a "Bingo()"? o ¿estás jugando un juego con una matriz bidimensional de enteros aleatorios, etc.?
Espero que esto ayude.
Jim
No hay que buscar una aguja en un pajar, pero no es "legible" la palabra correcta, en lugar de leer o readbly? – mare
El primer ejemplo no se debe usar en absoluto, incluso si fue más legible que el segundo ejemplo, ya que no se realiza ninguna comprobación de nulo o de longitud en foo. – Patrik
El segundo, ¿no se estrellaría el primero si la cadena estuviera vacía? – NibblyPig