2011-09-26 26 views
6

Dopo alcune ricerche ho capito che non è possibile analizzare le strutture ricorsive (come HTML o XML) usando le espressioni regolari. È possibile elencare in modo completo gli scenari di codifica giornalieri in cui evitare di utilizzare espressioni regolari perché è semplicemente impossibile eseguire quella particolare attività utilizzando le espressioni regolari? Supponiamo che il motore regex in questione non sia PCRE.Quando non dovrei usare le espressioni regolari?

+1

Penso che la tua domanda sia troppo ampia. Non è abbastanza lontano da "quando usare uno strumento". Non puoi davvero aspettarti una risposta definitiva per tutti i casi possibili, vero? Quando usare uno strumento: quando lo capisci, quando semplifica il tuo lavoro, quando rende il codice più chiaro invece che più complicato ... Quando usare regex? Quando devi abbinare i pattern alle stringhe. Non posso fare molto meglio di così. – Kobi

+0

Sono d'accordo che 'quando usare regex' è una domanda ampia. Ma penso che sia utile essere a conoscenza di scenari comuni in cui non è possibile utilizzare regex per svolgere una determinata attività. Ciò farà risparmiare molto tempo allo sviluppatore. –

+0

Vedi anche questa domanda, con un [esempio di "parsing con regex"] (http://stackoverflow.com/a/15589159/287948). –

risposta

26

Non usare le espressioni regolari quando:

  • la lingua che si sta tentando di analizzare non è un regular language, o
  • quando ci sono parser prontamente disponibili specificamente realizzati per i dati che si sta tentando di analizzare .

L'analisi di HTML e XML con espressioni regolari è in genere una cattiva idea, sia perché non sono lingue normali, sia perché esistono già librerie che possono analizzarle per voi.

Come altro esempio, se è necessario verificare se un numero intero è compreso nell'intervallo 0-255, è più facile capire se si utilizzano le funzioni della libreria della lingua per analizzarlo su un numero intero e quindi controllarne il valore numerico anziché provare scrivere l'espressione regolare che corrisponde a questo intervallo.

+1

risposta EPIC. Punti completi –

+2

I punti completi sono uno! +1 –

+0

Lo capisco, ma voglio solo conoscere alcuni scenari di codifica giorno per giorno in cui dovrei stare lontano dalle espressioni regex. Come l'analisi di HTML o XML. –

2

La mia regola pratica è usare espressioni regolari quando non esiste altra soluzione. Se esiste già un parser (ad esempio, XML, HTML) o cerchi solo stringhe anziché schemi, non è necessario utilizzare espressioni regolari.

Chiedi sempre a te stesso "posso risolvere questo problema senza utilizzare le espressioni regolari?". La risposta a questa domanda ti dirà se dovresti usare le espressioni regolari.

7

sarò me stesso plagiato dal mio post sul blog, When to use and when not to use regular expressions ...

siti web pubblici non dovrebbe consentire agli utenti di inserire le espressioni regolari per la ricerca. Dare il pieno potere della regex al pubblico per il motore di ricerca di un sito web potrebbe avere un effetto devastante. Esiste un attacco regular expression denial of service (ReDoS) che dovrebbe essere evitato a tutti i costi.

L'analisi HTML/XML non deve essere eseguita con espressioni regolari. Prima di tutto, le espressioni regolari sono progettate per analizzare uno regular language che è il più semplice tra lo Chomsky hierarchy. Ora, con l'avvento delle definizioni dei gruppi di bilanciamento nel sapore .NET delle espressioni regolari, puoi avventurarti in un territorio leggermente più complesso e fare alcune cose con XML o HTML in situazioni controllate. Tuttavia, non ha molto senso. Sono disponibili parser per XML e HTML che svolgeranno il lavoro in modo più semplice, efficiente e affidabile. In .NET, XML può essere gestito con il vecchio modo XmlDocument o ancora più facilmente con Linq to XML. O per HTML c'è lo HTML Agility Pack.

Conclusione

Le espressioni regolari hanno la loro utilità. Continuo a sostenere che in molti casi possono salvare molto tempo e impegno per il programmatore. Naturalmente, dato il tempo infinito delle risorse &, si potrebbe quasi sempre creare una soluzione procedurale più efficiente di un'espressione regolare equivalente.

La vostra decisione di abbandonare regex dovrebbe essere basato su 3 cose:

1.) L'espressione regolare è così lenta nello scenario che è diventato un collo di bottiglia?

2.) La soluzione procedurale è effettivamente più veloce da scrivere & rispetto all'espressione regolare?

3.) Esiste un parser specializzato che farà meglio il lavoro?

+0

Grazie, Steve. Il tuo post sul blog cancella molto! –

Problemi correlati