2009-06-15 17 views
18

मुझे पता है कि कोई मुझे बता रहा है कि RegEx से बचा जाना चाहिए, क्योंकि यह हेवीवेट है या इसमें भारी प्रसंस्करण शामिल है। क्या ये सच है? इसने मेरे कानों में एक झुकाव बनाया, अब तक मेरे गले लगा रहे हैं।क्या मुझे नियमित अभिव्यक्ति से बचना चाहिए?

मुझे नहीं पता कि उसने मुझे यह क्यों बताया। क्या यह अनुभव से हो सकता है या केवल तीसरी हाथ की जानकारी (आप जानते हैं कि मेरा क्या मतलब है ...)?

तो, स्पष्ट रूप से कहा गया है, मुझे नियमित अभिव्यक्तियों से क्यों बचना चाहिए?

मुझे एसओ समुदाय में स्वामी से जानकारी उनके साथ साझा करने के लिए जानकारी चाहिए। धन्यवाद दोस्तों!

+7

हां, ओपनजीएल से भी बचा जाना चाहिए, सुना है कि यह भारी प्रसंस्करण से भरा है .. – 0scar

+1

यह भी देखें: http://stackoverflow.com/questions/842288/are-regular-expressions-over-hyped (जो बहुत अधिक होता बेहतर सवाल अगर लेखक ने लंबे विचार टुकड़े को तोड़ दिया था ...) – Shog9

+0

यह सुनिश्चित नहीं है कि उन्होंने आपको उस प्रश्न के लिए क्यों डांटा ...सभी को कहीं से शुरू करना है और यह जानना एक अच्छा विचार है कि आप कुछ क्यों कर रहे हैं या क्यों नहीं ... +1 – bytebender

उत्तर

26

उनसे मत बचें।वे एक उत्कृष्ट उपकरण हैं, और जब उचित रूप से का उपयोग किया जाता है तो आप बहुत समय और प्रयास बचा सकते हैं। इसके अलावा, ध्यान से इस्तेमाल किया गया एक अच्छा कार्यान्वयन विशेष रूप से सीपीयू-गहन नहीं होना चाहिए।

+0

व्यक्तिगत रूप से, मुझे RegEx पसंद है, आपको बहुत सारे कोड बचाता है (और समय) पाठ इनपुट मान्य करते समय। कोड को खोलने की तुलना में रेगेक्स के लिए सीपीयू समय बलिदान करना बुद्धिमान हो सकता है (जो बग प्रवण है) ... – jerbersoft

+9

दाएं। यदि आपने पिछले बीस वर्षों में पार्सर्स लिखने में बिताया है, जहां आप अब मिनटों में किसी भी रेगेक्स के बराबर एक निर्दोष "लंबे हाथ" लिख सकते हैं (एक हाथ आपकी पीठ के पीछे बंधे हुए हैं, जबकि blindfolded ...) तो हर तरह से , उनके साथ परेशान मत करो। लेकिन हम में से अधिकांश के लिए, एक नियमित अभिव्यक्ति लिखना बराबर पार्सिंग कोड लिखने से तेज़ है, भले ही हमें ऐसा करने के दौरान वाक्यविन्यास देखना पड़े! और यहां तक ​​कि एक मामूली जटिल अभिव्यक्ति को नेस्टेड स्विच स्टेटमेंट के दो पृष्ठों की तुलना में समझना आसान है ... – Shog9

+2

@ शोग 9: हटाए गए डुप्लिकेट पर सिर के लिए धन्यवाद। मुझे लगता है कि उस सवाल का शब्द उसकी गिरावट थी। जवाब निश्चित रूप से बचाव के लायक हैं, इसलिए मैंने उन्हें विलय कर दिया। –

18

ओवरहाइड? नहीं। वे बेहद शक्तिशाली और लचीले हैं।

अधिक उपयोग किया गया? पूर्ण रूप से। विशेष रूप से जब HTML को पार्स करने की बात आती है (जो अक्सर यहां आती है)।

यह उन "नौकरी के लिए सही उपकरण" परिदृश्यों में से एक है। कुछ बहुत दूर जाते हैं और सब कुछ के लिए इसका इस्तेमाल करने की कोशिश करते हैं।

आप सही हैं हालांकि आप सबस्ट्रिंग और/या विभाजित के साथ कई चीजें कर सकते हैं। आप अक्सर उन लोगों के साथ एक बिंदु तक पहुंच जाएंगे जहां आप जो कर रहे हैं वह इतना जटिल हो जाएगा कि आपको विधि बदलनी है या आप बहुत अधिक नाजुक कोड लिखना समाप्त कर देते हैं। Regexes (अपेक्षाकृत) विस्तार करने के लिए आसान हैं।

लेकिन हाथ लिखित कोड लगभग हमेशा तेज होगा। इसका एक अच्छा उदाहरण Putting char into a java string for each N characters है। रेगेक्स समाधान टर्सर है लेकिन इसमें कुछ समस्याएं हैं जो एक हाथ लिखित लूप नहीं है और बहुत धीमी है।

+0

या वास्तव में किसी भी प्रकार की गतिविधि में जिसे "पार्सिंग" कहा जा सकता है। –

+3

एक संकलित (अच्छी तरह से लिखित) regex वास्तव में बेहद तेज़ हो जाता है। यह सिर्फ एक राज्य मशीन है। मुझे लगता है कि बहुत से गति के मुद्दों को लोगों को यह समझ में नहीं आ सकता है कि एक संकलित रेगेक्स में रेगेक्स के स्ट्रिंग प्रस्तुति को बदलने के लिए काफी बड़े पैमाने पर जुर्माना हो सकता है। – user21714

+1

असल में पर्ल रेगेक्स इंजन तेजी से लिखा गया है, अगर आप खुद को नियमित रूप से लिखते हैं, लेकिन मामलों के सबसे सरल हैं। यह निश्चित रूप से मानता है कि रेगेक्स अच्छी तरह से शुरू करने के लिए डिज़ाइन किया गया था। –

3

यदि अधिक लोगों को पता था कि एक सभ्य पार्सर जनरेटर का उपयोग कैसे किया जाए, तो नियमित अभिव्यक्तियों का उपयोग करने वाले कम लोग होंगे।

4

ओवरहाइड? नहीं

उचित रूप से कम उपयोग किया गया? हां

+0

मैंने इस उत्तर को एक हटाए गए प्रश्न से पुनर्प्राप्त किया जो वही था, लेकिन थोड़ा अलग तरीके से लिखा गया था। आप मिलान के लिए अपने उत्तर के शब्द को समायोजित करना चाह सकते हैं। –

5

मुझे लगता है कि यदि आप भाषा में प्रोग्रामिंग सीखते हैं जो नियमित रूप से अभिव्यक्तियों को बोलता है तो आप उनके प्रति गुरुत्वाकर्षण करेंगे क्योंकि वे इतनी सारी समस्याओं को हल करते हैं। आईई, आप स्प्लिट का उपयोग कभी नहीं सीख सकते हैं क्योंकि regexec() समस्याओं का एक बड़ा सेट हल कर सकता है और एक बार जब आप इसका इस्तेमाल कर लेते हैं, तो कहीं और क्यों देखें?

दूसरी ओर, मैं शर्त लगाता हूं कि सी और सी ++ प्रोग्रामर सबसे अधिक विकल्पों के लिए सबसे पहले विकल्प देखेंगे, क्योंकि यह भाषा में नहीं बनाया गया है।

7

"जब आपके पास हथौड़ा होता है, तो सब कुछ नाखून जैसा दिखता है।"

नियमित अभिव्यक्तियां एक बहुत उपयोगी उपकरण हैं; लेकिन मैं मानता हूं कि वे उपयोग की जाने वाली हर जगह के लिए आवश्यक नहीं हैं। उनके लिए एक सकारात्मक कारक यह है कि क्योंकि वे जटिल होते हैं और जहां वे होते हैं, उनका उपयोग बहुत अधिक होता है, नियमित अभिव्यक्तियों को लागू करने के लिए एल्गोरिदम को बेहतर ढंग से अनुकूलित किया जाता है। उस ने कहा, नियमित अभिव्यक्ति सीखने में शामिल ओवरहेड ... उच्च हो सकता है। बहुत ऊँचा।

नियमित रूप से अभिव्यक्तियों को हर लागू स्थिति के लिए उपयोग करने के लिए सबसे अच्छा उपकरण है? शायद नहीं, लेकिन दूसरी ओर, यदि आप स्ट्रिंग सत्यापन के साथ काम करते हैं और हर समय खोज करते हैं, तो आप शायद नियमित अभिव्यक्तियों का बहुत उपयोग करते हैं; और एक बार ऐसा करने के बाद, आपके पास पहले से ही किसी भी अन्य टूल की तुलना में उपकरण का अधिक उपयोग करने के लिए आवश्यक ज्ञान का उपयोग करना आवश्यक है। लेकिन अगर आपके पास यह अनुभव नहीं है, तो सीखना प्रभावी रूप से उस कार्यान्वयन के लिए आपकी उत्पादकता पर एक ड्रैग है।तो मुझे लगता है कि यह उस समय पर निर्भर करता है जब आप एक नया प्रतिमान सीखने के इच्छुक हैं, और आपके प्रोजेक्ट में शामिल होने वाले भाग का स्तर। कुल मिलाकर, मुझे लगता है कि नियमित अभिव्यक्ति सीखने के लायक हैं, लेकिन साथ ही, सीखने की प्रक्रिया स्पष्ट रूप से चूस सकती है।

3

मेरी धारणा में, वे लोगों द्वारा काफ़ी overused किया है (मैं इस चर्चा इतने पर कई बार मिला है)। क्योंकि वे कोड का एक बहुत छोटा टुकड़ा में सूचक क्षमता का एक बहुत देने

लेकिन वे एक बहुत ही उपयोगी निर्माण कर रहे हैं।

आप केवल इस तरह के एक पश्चिमी ऑस्ट्रेलियाई कार पंजीकरण संख्या के रूप में एक उदाहरण देखें करने के लिए है। आरई जाँच करने के लिए इस में काफी लंबे समय तक किया जाएगा, तो एक सामान्य 9-यदि बयान या थोड़ा बेहतर पाशन संस्करण में, कोड, जबकि

re.match("[1-9] [A-Z]{3} [0-9]{3}") 

होगा।

मैं शायद ही कभी मेरी कोड में जटिल आर ई का उपयोग करें क्योंकि:

  • मैं कैसे आरई इंजन काम करते हैं और मैं डोमेन ज्ञान का उपयोग कर सकते तेजी से समाधान ऊपर कोड करने के लिए (पता है कि 9-यदि संस्करण लगभग निश्चित रूप से तेजी से किया जाएगा एक शॉट आरई संकलन/निष्पादन चक्र से); और
  • यदि कोड तर्कसंगत रूप से टूट गया है और टिप्पणी की गई है तो मुझे कोड अधिक पठनीय लगता है। अधिकांश आरईएस के साथ यह आसान नहीं है (हालांकि मैंने एक देखा है जो इनलाइन टिप्पणियों की अनुमति देता है)।

मैं देखा लोगों को एक निश्चित स्थान पर एक निश्चित-आकार-स्ट्रिंग निकालने के लिए आर ई के उपयोग का सुझाव देते हैं। इन लोगों का उपयोग क्यों न करें substring() मेरे बाहर है। मेरा व्यक्तिगत विचार यह है कि वे सिर्फ यह दिखाने की कोशिश कर रहे हैं कि वे कितने चालाक हैं (लेकिन यह शायद ही कभी काम करता है)।

+0

सबस्ट्रिंग() उदाहरण काफी सच है, मुझे यह भी समझ में नहीं आता कि क्यों कुछ लोग रेगेक्स के हर समय उपयोग करने का आग्रह करते हैं। –

1

रेगुलर एक्सप्रेशन सबसे अधिक उपयोगी बातें प्रोग्रामर सीख सकते हैं में से एक हैं, वे तेजी लाने और यदि आप जानते हैं कि कैसे उन्हें संभाल करने के लिए अपने कोड को कम करने के लिए अनुमति देते हैं।

2

स्क्रिप्टिंग भाषाओं (जैसे रूबी, पायथन, पर्ल, जावास्क्रिप्ट और लुआ) में नियमित अभिव्यक्तियों का उपयोग करने का एक बहुत अच्छा कारण है: ध्यान से अनुकूलित नियमित अभिव्यक्ति के साथ एक स्ट्रिंग को पार्स करना समकक्ष कस्टम से तेज़ी से निष्पादित करता है जबकि लूप जो स्कैन करता है स्ट्रिंग चरित्र-दर-चरित्र। संकलित भाषाओं के लिए (जैसे सी और सी ++, और सी # और जावा ज्यादातर समय) आमतौर पर विपरीत सत्य है: कस्टम जबकि लूप तेजी से निष्पादित होता है।

एक और कारण है कि नियमित अभिव्यक्ति इतनी लोकप्रिय क्यों होती हैं: वे प्रोग्रामर के इरादे को बेहद कॉम्पैक्ट तरीके से व्यक्त करते हैं: एक सिंगल-लाइन रेगेक्सपी लूप के दौरान 10- या 20-लाइन जितनी अधिक कर सकती है।

1

गैर-रेगेक्स समकक्ष की तुलना में नियमित अभिव्यक्तियों को अक्सर समझना आसान होता है, खासतौर पर देशी नियमित अभिव्यक्तियों वाली भाषा में, विशेष रूप से कोड अनुभाग में जहां अन्य चीजें रेगेक्स के साथ करने की आवश्यकता होती है।

इसका मतलब यह नहीं है कि वे अधिक उपयोग नहीं कर रहे हैं। String.contains ('?') की तुलना में एकमात्र समय स्ट्रिंग.contains ('?') से बेहतर है, अगर यह आस-पास के कोड के साथ काफी अधिक पठनीय है, या यदि आप उसे जानते हैं तो कंटेनस को रीजिक्स के साथ लागू किया जाता है।

1

मैं अक्सर अपने आईडीई में रेगेक्स का उपयोग त्वरित फिक्स कोड के लिए करता हूं। रेगेक्स के बिना निम्नलिखित करने का प्रयास करें।

glVector3f (-1.0f, 1.0f, 1.0f); -> glVector3f (center.x - 1.0f, center.y + 1.0f, center.z + 1।0 एफ);

regex के बिना, यह एक दर्द है, लेकिन regex के साथ ...

s/glVector3f\((.*?),(.*?),(.*?)\)/glVector3f(point.x+$1,point.y+$2,point.z+$3)/g 

बहुत बढ़िया।

2

ओवरहाइड? नहीं, अगर आपने कभी पार्सिंग या कंपाइलर कोर्स लिया है, तो आप समझेंगे कि यह अतिरिक्त कहने जैसा है और गणित की समस्याओं के लिए गुणा को खत्म कर दिया गया है।

यह पार्सिंग समस्याओं को हल करने के लिए एक प्रणाली है।

कुछ समस्याएं सरल हैं और नियमित अभिव्यक्तियों की आवश्यकता नहीं है, कुछ कठिन हैं और बेहतर उपकरण की आवश्यकता है।

+0

@ अज्ञात: मैंने हटाए गए प्रश्न से विलय करके इस उत्तर को पुनर्प्राप्त किया। आप इस प्रश्न को फिट करने के लिए थोड़ा सा अपना शब्द समायोजित करना चाह सकते हैं। –

1

मैं सहमत हूं कि नियमित अभिव्यक्तियों को कभी-कभी गलत तरीके से उपयोग किया जाता है। निश्चित रूप से बहुत सरल मामलों के लिए जो आप वर्णन कर रहे हैं, लेकिन ऐसे मामलों के लिए जहां एक अधिक शक्तिशाली पार्सर की आवश्यकता है।

एक विचार यह है कि कभी-कभी आपके पास ऐसी स्थिति होती है जिसे प्रश्न चिह्न चरित्र की उपस्थिति के लिए परीक्षण की तरह कुछ सरल करने की आवश्यकता होती है। लेकिन यह अक्सर सच है कि स्थिति अधिक जटिल हो जाती है। उदाहरण के लिए, एक प्रश्न चिह्न चरित्र खोजने के लिए किसी स्थान या प्रारंभ से पहले नहीं है, और नहीं है जिसके बाद अल्फान्यूमेरिक वर्ण है। या चरित्र या तो एक प्रश्न चिह्न या स्पेनिश "¿" हो सकता है (जो किसी शब्द की शुरुआत में प्रकट हो सकता है)। तुम्हें नया तरीका मिल गया है।

यदि ऐसी स्थिति में विकसित होने की उम्मीद है जो सादा कॉल के साथ String.contains("?") पर कम करना आसान है, तो शुरुआत से ही एक बहुत ही सरल नियमित अभिव्यक्ति का उपयोग करके इसे कोड करना आसान हो सकता है।

1

यह नौकरी के लिए सही उपकरण पर आता है।

मैं आमतौर पर नियमित अभिव्यक्तियों के खिलाफ दो तर्क सुनता हूं: 1) वे कम्प्यूटेशनल रूप से अक्षम हैं, और 2) उन्हें समझना मुश्किल है।

ईमानदारी से, मैं समझ नहीं पा रहा हूं कि या तो वैध दावे कैसे हैं।

1) यह अकादमिक अर्थ में सच हो सकता है। एक जटिल अभिव्यक्ति स्वयं पर दो बार खत्म हो सकती है। क्या यह वास्तव में मायने रखता है? इन दिनों सर्वर प्रोसेसर कितने लाखों कंप्यूटेशंस कर सकता है? मैंने कुछ पागल अभिव्यक्तियों के साथ निपटाया है, और मेरे पास कभी बोतल गर्दन होने के लिए एक regexp देखा है। अब तक यह बैंडविड्थ के बाद डीबी इंटरैक्शन है।

2) लगभग एक सप्ताह तक मुश्किल। सबसे जटिल regexp HTML से अधिक जटिल नहीं है - यह केवल एक परिचित समस्या है। यदि आपको हर 3 महीने में एक बार HTML की आवश्यकता होती है, तो क्या आपको हर बार 100% मिल जाएगा? उनके साथ दैनिक आधार पर काम करें और वे किसी भी अन्य भाषा वाक्यविन्यास के समान स्पष्ट हैं।

मैं सत्यापन सॉफ्टवेयर लिखता हूं। REGEXP की दूसरी प्रकृति है। कोड की हर पांचवीं पंक्ति में एक regexp है, और मेरे जीवन के लिए मैं समझ नहीं पा रहा हूं कि लोग उनके बारे में एक बड़ा सौदा क्यों करते हैं। मैंने कभी भी रेगेक्सप धीमी गति से प्रसंस्करण नहीं देखा है, और मैंने देखा है कि सबसे सुस्त 'प्रोग्रामर' सिंटैक्स उठाते हैं।

Regexp शक्तिशाली, कुशल और उपयोगी हैं। उनसे क्यों बचें?

3

इससे बचें नहीं, लेकिन खुद से पूछें कि क्या वे आपके कार्य को हल करने के लिए सबसे अच्छे उपकरण हैं। शायद कभी-कभी रेगेक्स का उपयोग करना या डीबग करना मुश्किल होता है, लेकिन कुछ स्थितियों में वे वास्तव में उपयोगी होते हैं। प्रश्न प्रत्येक कार्य के लिए apropiate उपकरण का उपयोग करना है, और आमतौर पर यह स्पष्ट नहीं है।

21

यदि आप सामान्य स्ट्रिंग ऑपरेशंस के साथ आसानी से वही काम कर सकते हैं, तो आपको नियमित अभिव्यक्ति का उपयोग करने से बचना चाहिए।

ज्यादातर स्थितियों में नियमित अभिव्यक्तियों का उपयोग किया जाता है जहां एक ही ऑपरेशन को सामान्य स्ट्रिंग ऑपरेशंस की पर्याप्त मात्रा की आवश्यकता होती है, तो निश्चित रूप से नियमित अभिव्यक्तियों से बचने में कोई बात नहीं है।

+2

सामान्य ज्ञान की तरह लगता है लेकिन लोग इसे भूल जाते हैं। – xenon

+0

तर्क क्या है? एक अच्छा कंपाइलर पर एक precompiled फिर एक स्ट्रिंग ऑपरेशन से धीमा क्यों होगा? –

+2

"सामान्य ज्ञान इतना आम नहीं है" - वोल्टायर;) – Guffa

8

मूल पार्सर या सत्यापनकर्ता के रूप में, नियमित अभिव्यक्ति का उपयोग करें जब तक कि आप जो अन्यथा लिखने या सत्यापन कोड को पढ़ना आसान नहीं पढ़ते, उन्हें पढ़ना आसान हो जाएगा।

जटिल पार्सर्स (यानी रिकर्सिव डेसेंट पार्सर्स) के लिए केवल रेक्सिक्स का उपयोग केवल अक्षीय तत्वों को सत्यापित करने के लिए करें, उन्हें न ढूंढें।

नीचे की रेखा है, सर्वोत्तम रेगेक्स इंजन सत्यापन कार्य के लिए अच्छी तरह से ट्यून किए जाते हैं, और कुछ मामलों में आप जो कोड लिख सकते हैं उससे अधिक कुशल हो सकते हैं, और अन्य में आपका कोड बेहतर प्रदर्शन करेगा। जैसा कि आप फिट देखते हैं, हस्तलिखित राज्य मशीनों या रेगेक्स का उपयोग करके अपना कोड लिखें, लेकिन यदि प्रदर्शन परीक्षण आपको दिखाता है कि रेगेक्स महत्वपूर्ण रूप से अक्षम है तो रेगेक्स से हस्तलिखित कोड में बदलें।

+2

+1 यह इंगित करने के लिए कि रेगेक्स अक्सर इस पोस्ट पर जटिल पार्सर्स –

5

आप जानते हैं कि मैं बहुत से लोगों को "युवा" कहता हूं, मैंने RegEx के बारे में बहुत आलोचना की है। आप जानते हैं, "उसे एक समस्या थी और रेगेक्स का उपयोग करने की कोशिश की, अब उसे दो समस्याएं हैं"।

गंभीरता से, मुझे यह नहीं मिला। यह किसी अन्य की तरह एक उपकरण है। अगर आपको कुछ पाठ के साथ एक साधारण वेबसाइट की आवश्यकता है, तो आपको PHP/ASP.NET/STG44 की आवश्यकता नहीं है। फिर भी, इस पर कोई चर्चा नहीं है कि उनमें से किसी से बचा जाना चाहिए या नहीं। कितना अजीब।

मेरे अनुभव में, RegEx शायद सबसे उपयोगी टूल है जिसे मैंने कभी डेवलपर के रूप में सामना किया है। जब यह # 1 सुरक्षा समस्या की बात आती है तो यह सबसे उपयोगी टूल है: उपयोगकर्ता इनपुट को पार्स करना। कोडिंग के दिनों और संभावित रूप से छोटी गाड़ी बनाने (पढ़ने: क्रैपी) कोड बनाने के दिनों में मैंने मुझे घंटे बचा लिया है।

आधुनिक CPUs के साथ, मुझे नहीं लगता कि यहां प्रदर्शन समस्या क्या है। मैं कुछ गुणवत्ता और सुरक्षा के लिए कुछ चक्र बलिदान देने के लिए तैयार हूं। (हालांकि यह हमेशा मामला नहीं है, लेकिन मुझे लगता है कि वे मामले दुर्लभ हैं।)

फिर भी, RegEx बहुत शक्तिशाली है। महान शक्ति के साथ महान जिम्मेदारी आती है। इसका मतलब यह नहीं है कि आप इसे जब भी कर सकते हैं इसका उपयोग करेंगे। केवल जहां यह शक्ति का उपयोग करने लायक है।

जैसा ऊपर बताया गया है, रेगेक्स के साथ एचटीएमएल पार्सिंग पूरी तरह से लोड बंदूक के साथ रूसी रूले की तरह है। कुछ भी ज्यादा मत करो, RegEx शामिल है।

+0

+1 के लिए सही समाधान नहीं है। जानकारीपूर्ण। – jerbersoft

+2

+1 और उस पर आमीन। बेशक आप रेगेक्स का उपयोग नहीं करते हैं जहां एक साधारण स्ट्रिंग प्रतिस्थापन करेगा, लेकिन कोई भी प्रोग्रामर जो रेगेक्स के आसपास अपने सिर नहीं ले सकता है, वह सही पेशे में नहीं है, लेकिन वे आसान नहीं हैं, लेकिन वे बस * नहीं * वह * कठिन। – Cruachan

12

आप अपने प्रश्न में "रेगेक्स" को बहुत अधिक तकनीक के साथ प्रतिस्थापित कर सकते हैं और आपको ऐसे लोग मिलेंगे जो तकनीकी रूप से इस तरह के दावों को तकनीक सीखने के लिए तकनीक को समझते हैं या आलसी समझते हैं।

नियमित अभिव्यक्तियों के बारे में भारी वजन नहीं है। नियमित अभिव्यक्तियों का उपयोग करके प्रोग्रामर स्वयं को परेशानी में डालते हैं सबसे आम तरीका यह है कि वे एक नियमित अभिव्यक्ति के साथ बहुत कुछ करने की कोशिश करते हैं। यदि आप उनके इच्छित उद्देश्यों (सरल पैटर्न मिलान) के लिए नियमित अभिव्यक्तियों का उपयोग करते हैं, तो आपको प्रक्रियात्मक कोड लिखने के लिए कठोर दबाव डाला जाएगा जो बराबर नियमित अभिव्यक्ति से अधिक कुशल है।नियमित अभिव्यक्तियों के साथ सभ्य प्रवीणता को देखते हुए, नियमित अभिव्यक्ति को लिखने में बहुत कम समय लगता है, पढ़ने में आसान होता है, और विज़ुअलाइजेशन के लिए रेगेक्सबड्डी जैसे टूल में चिपकाया जा सकता है।

+0

स्पेक्ट्रम के दूसरे छोर पर लोग - समान रूप से अज्ञानी, लेकिन उत्साही वैसे भी - मामलों में मदद नहीं करते हैं। जो लोग मुझे सबसे ज्यादा बग करते हैं वे हैं जो पिथी सलाह के साथ स्ट्रिंग-मैनिपुलेशन प्रश्नों का जवाब देते हैं, "रेगेक्स का उपयोग करें"। क्षमा कीजिय? यदि ओपी को रेगेक्स के बारे में कुछ पता था, तो क्या आपको नहीं लगता कि वह उनके बारे में सोचा होगा? अक्सर नहीं, रीजिक्स नौकरी के लिए गलत उपकरण है। (मैं इस साइट के बारे में बात नहीं कर रहा हूं, मैं ज्यादातर इसे सूर्य के जावा मंचों में देखता हूं।) –

+0

@Alan: ठीक है। यद्यपि रेगेक्स पुशर्स मौजूद हैं, लेकिन यह साइट "क्या आपने jQuery की कोशिश की है?" जगह। बेशक, jQuery एक शानदार छोटी लाइब्रेरी है और उनके सही दिमाग में कोई भी इसे टालना चाहिए ... लेकिन यह हर नौकरी के लिए उपकरण नहीं है। (विशेष रूप से: कभी-कभी आपको jQuery के बजाय regex का उपयोग करना चाहिए) जेएस मामले के लिए – Shog9

4

आपको हर कीमत पर फ्लोटिंग-पॉइंट नंबरों से भी बचना चाहिए। वह तब होता है जब आप एम्बेडेड-पर्यावरण में प्रोग्रामिंग कर रहे हों।

गंभीरता से: यदि आप सामान्य सॉफ़्टवेयर-विकास में हैं तो आपको वास्तव में रेगेक्स का उपयोग करना चाहिए यदि आपको ऐसा कुछ करने की ज़रूरत है जो सरल स्ट्रिंग-ऑपरेशंस के साथ हासिल नहीं की जा सके। मैं कहूंगा कि कोई भी सामान्य प्रोग्रामर कुछ ऐसा लागू करने में सक्षम नहीं होगा जो रेगेक्सप्स का उपयोग करके सबसे अच्छा किया गया है जो कि अनुरूप नियमित अभिव्यक्ति से तेज़ है। एक बार संकलित हो जाने पर, एक नियमित अभिव्यक्ति एक राज्य-मस्चिन के रूप में काम करती है जिसे पूर्णता के लिए अनुकूलित किया जाता है।

2

मैंने देखा है कि इतने सारे लोग तर्क देते हैं कि दिया गया रेगेक्स सही है या नहीं, मुझे लगता है कि मुझे लिखने का सबसे अच्छा तरीका यह है कि स्टैक ओवरफ्लो पर इसे कैसे करना है और फिर रेगेक्स गुरु लड़ाई यह बाहर।


मुझे लगता है कि वे जावास्क्रिप्ट में विशेष रूप से उपयोगी हैं। जावास्क्रिप्ट संचरित होता है (इसलिए छोटा होना चाहिए) और पाठ से व्याख्या की गई है (हालांकि यह वी 8 और जेआईटी संकलन के साथ नए ब्राउज़र में बदल रहा है), इसलिए एक अच्छा आंतरिक रेगेक्स इंजन को एल्गोरिदम से तेज़ होने का मौका मिला है।

मैं कहूंगा कि स्ट्रिंग ऑपरेशंस के साथ ऐसा करने का एक स्पष्ट और आसान तरीका है, स्ट्रिंग ऑपरेशंस का उपयोग करें। लेकिन अगर आप अपना खुद का राज्य मशीन दुभाषिया लिखने के बजाय एक अच्छा रेगेक्स कर सकते हैं, तो रेगेक्स का उपयोग करें।

+0

++, हालांकि कुछ तर्क भी अन्य व्याख्या की गई भाषाओं पर लागू होते हैं। – Shog9

1

मैं उनसे पूरी तरह से बचने के लिए कहूंगा, क्योंकि वे कभी-कभी कुशल काम करते हैं। हालांकि, नीचे मौलिक तंत्र का एहसास करना महत्वपूर्ण है। आपके कार्यान्वयन के आधार पर, आप खोज के लिए घातीय रन-टाइम तक पहुंच सकते हैं, लेकिन चूंकि खोज आमतौर पर बैकट्रैस की कुछ निरंतर संख्या से बंधी जाती हैं, इसलिए आप कभी भी देखे गए धीमे रैखिक रन-टाइम के साथ समाप्त हो सकते हैं।

यदि आप सबसे अच्छा जवाब चाहते हैं, तो आपको अपने विशेष कार्यान्वयन के साथ-साथ जिस डेटा को खोजना है, उसकी जांच करनी होगी।

स्मृति से, विकिपीडिया नियमित अभिव्यक्तियों और अंतर्निहित एल्गोरिदम पर एक सभ्य लेख है।

संबंधित मुद्दे