Cuándo usar Regex vs Built in String Methods?

Question

He notado muchos pequeños debates sobre cuándo usar expresiones regulares y cuándo utilizar una función de cadena integrada como String.Replace() (.NET).

Parece que mucha gente recomienda siempre, siempre, siempre usar expresiones regulares siempre que trabaje con cadenas (además de solo mostrarlas). ¿Es esta realmente la mejor práctica o simplemente una impresión equivocada de mi parte? Parece excesivo usar regex cuando el problema es solo "Eliminar cualquier aparición de cualquiera de estas palabras de este texto".

Me gustaría obtener información para poder mejorar mi propio código y responder mejor a las preguntas de otras personas sobre la manipulación de cadenas (hay muchas de ellas).

Answer 1

Creo que es una impresión errónea utilizar Regex como solución global cuando es posible buscar/reemplazar cadenas.

Regex es intrínsecamente un proceso de coincidencia de patrones y se debe utilizar cuando los tipos de cadenas que desea unir son variables o solo se ajustan a un patrón en particular. Para casos en los que bastaría una simple búsqueda de cadenas, siempre recomendaría usar los métodos integrados de la clase String.

Nunca he visto ninguna estadística de rendimiento que sugiera que una búsqueda basada en Regex es más rápida o más eficiente que la indexación de cadenas. Además, los motores Regex varían en sus capacidades de ejecución.

Como si fuera poco, es bastante fácil construir un Regex que funciona bastante mal (usa mucho retroceso, por ejemplo) por lo que se requiere un profundo conocimiento de Regex si realmente quieres optimizar el rendimiento usando Regex matching . Por otro lado, es bastante simple incluso para un n00b realizar búsquedas o reemplazos basados ​​en cadenas.

Answer 2

Tiendo a pensar que si hay una función dedicada para manipular una cadena de la manera que desee como parte de la clase de cadena, debería estar muy cerca de 'bien' donde-como la expresión regular es de propósito general.

Pero como con cualquier cosa subjetiva, si le preocupa el tiempo de rendimiento de los diferentes métodos.

Luego, nuevamente, haga lo que sea más fácil de entender y realice un monitoreo del rendimiento para encontrar los cuellos de botella reales sobre la marcha.

Answer 3

Regex.Replace() es mucho más caro que el método String.Replace(). Use String.Replace() cuando sea posible y use Regex cuando sea necesario.

Echa un vistazo a este benchmark para ver las diferencias de tiempo.

Answer 4

Me encantan las expresiones regulares, pero si hay una función de tipo xxx-> replace ("foo", "bar") disponible, parece una tontería usar una herramienta eléctrica como regex cuando lo haría un simple destornillador.

Si el rendimiento es un problema, entonces regex puede consumir mucha CPU para sustituciones simples. (Regex generalmente resulta más eficiente en una búsqueda/transformación compleja que una serie de llamadas "más simples").

También me atrapan continuamente las diferencias de implementación "menores", como las pitones implícitas "^ ... $" en la coincidencia() incorporada. Estaba en el camino sin acceso a Internet en ese momento y terminé comprando otra copia del libro de Lutz para descubrir qué estaba pasando.

Answer 5

Obviamente, para operaciones complejas de búsqueda/coincidencia/reemplazo, las expresiones regulares son el camino a seguir. Para cosas simples como reemplazar una palabra por otra palabra, se prefieren los métodos de cadena normales.

Pero en muchos casos, no es tan simple. A veces te encuentras con una situación en la que puedes usar operaciones de cadena estándar, mientras que la solución de expresiones regulares es más elegante. Incluso si el algoritmo de la secuencia de vainilla es 10 veces más rápido, siempre es una buena idea preguntarse si importa en esa pieza de código en particular (por ejemplo, si el código no se ejecuta en un bucle).

Preferiría la legibilidad de una operación simple de expresiones regulares sobre un algoritmo más complejo pero más rápido que utiliza operaciones de cadenas puras.

Sólo mi 2 centavos ...