क्यों नियमित रूप से अभिव्यक्ति इतनी रुचिकर है?


23

एक्ज़िबिट 1 , एग्ज़िबिट 2 , मुझे लगता है कि आपको अन्य उदाहरण याद करने में मुश्किल नहीं होगी।

बात यह है: यदि किसी समस्या को हल करने के लिए एक से अधिक तरीके हैं, तो PHP प्रोग्रामर (मैं आमतौर पर PHP टैग को StackOverflow पर ब्राउज़ करता हूं) नियमित अभिव्यक्तियों से जुड़े समाधान पर मदद मांगेगा।

यहां तक ​​कि जब यह कम आर्थिक होगा, तब भी जब कोई मैन्युअल प्रतिस्थापन नियमों की आवश्यकता नहीं होने पर php मैनुअल किसी भी या फ़ंक्शन के बजाय उपयोग करने के लिए ( लिंक ) का सुझाव देता है।str_replacepreg_*ereg_*

क्या किसी को इस बारे में कोई सुराग है कि ऐसा क्यों होता है?

मुझे गलत मत समझो, मेरे कुछ सबसे अच्छे दोस्त नियमित अभिव्यक्ति हैं और मैं पर्ल से घृणा नहीं करता। मुझे जो नहीं मिलता है वह यह है कि विकल्प की तलाश क्यों नहीं होती है, तब भी जब ओवरकिल स्पष्ट है (स्ट्रिंग स्विच करने के लिए regex) या कोड जटिलता तेजी से बढ़ जाती है ( PHP में html से डेटा प्राप्त करने के लिए regex )


2
आप शायद यह कहना चाहते हैं कि php मैनुअल वास्तव में क्या कहता है।
ChrisF

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

आपने उस अंतिम वाक्य के गलत हिस्से पर जोर दिया: इसका अपमानजनक हिस्सा "html से" है, न कि "PHP में"।
इज़्काता

जवाबों:


20

क्यों नियमित रूप से अभिव्यक्ति इतनी रुचिकर है?

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

यही कारण है कि लोगों का मानना ​​है कि नियमित अभिव्यक्तियाँ उनके किसी भी पाठ-आधारित कार्य को हल कर देंगी, किसी तरह यह नहीं सोचना चाहिए कि यह ओवरकिल हो सकता है और यह महसूस नहीं कर सकता है कि यह मुझे कम आंका जा सकता है (इसके साथ भाषाओं को पार्स करना)।

जादू की शक्ति वाली एक छोटी चीज। आप नहीं कह सकते, क्या आप नहीं कर सकते?


5
+1 - एक छोटी सी गुप्त चीज, कम नहीं।
एजे जॉनसन

हॉबिटेस चालबाज हैं
बेन

49

जब आपके पास एकमात्र उपकरण regex होता है, तो हर समस्या दिखती है ^((?>[a-zA-Z\d!#$%&'*+\-/=?^_{|}~]+\x20*|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*"\x20*)*(?<angle><))?((?!\.)(?>\.?[a-zA-Z\d!#$%&'*+\-/=?^_{|}~]+)+|"((?=[\x01-\x7f])[^"\\]|\\[\x01-\x7f])*")@(((?!-)[a-zA-Z\d\-]+(?<!-)\.)+[a-zA-Z]{2,}|\[(((?(?<!\[)\.)(25[0-5]|2[0-4]\d|[01]?\d?\d)){4}|[a-zA-Z\d\-]*[a-zA-Z\d]:((?=[\x01-\x7f])[^\\\[\]]|\\[\x01-\x7f])+)\])(?(angle)>)$


16
इस उत्तर को चुनने का प्रलोभन इतना प्रबल है, लेकिन मुझे लगता है कि मुझे इसका विरोध करना चाहिए क्योंकि यह मेरा पहला प्रश्न है, जो मुझे यहाँ खुला है और मुझे थोड़ी देर के लिए गंभीरता का सामना करना होगा।
cbrandolino 12

1
@ क्या, यह बहुत समझ में आता है। मेरी टिप्पणी जवाब के लिए मेरी प्रशंसा व्यक्त करने के लिए सिर्फ एक मजेदार तरीका था।
cbrandolino

17
क्या पृथ्वी पर इस मैच करता है?
टॉम ओ'कॉनर

4
मुझे पता नहीं ... मुझे लगता है कि यह बहुत अधिक इसे पूरा करता है। यदि आप रेगेक्स जानते हैं, और अन्य तरीकों के बारे में नहीं जानते हैं, तो आप क्यों देखेंगे? आपको पहले ही एक टूल मिल गया है, जो अगर सही तरीके से किया जाता है, तो काम को संभाल लेगा। जब तक वे सरल विधि में ठोकर खाते हैं या इसके बारे में नहीं बताया जाता है, तब तक रेगेक्स कैच-ऑल विधि होगी, भले ही यह जरूरत से ज्यादा जटिल हो।
अन्नू

4
@Tom O'Connor मुझे लगता है कि यह एक RFC 2822 ईमेल पते के मिलान के लिए Regex के करीब है, लेकिन मुझे कुछ पात्रों को निकालना पड़ा क्योंकि वे मार्कडाउन के साथ कहर बरपा रहे थे।
Glenatron

23

मुझे लगता है कि यह है क्योंकि:

  1. समतुल्य कोड की तुलना में वे काल्पनिक रूप से संक्षिप्त (जब ठीक से उपयोग किए जाते हैं), और
  2. वे प्रोग्रामिंग भाषाओं में व्यापक रूप से समर्थित हैं, इसलिए अधिकांश डेवलपर्स उनसे परिचित हैं।

3
# 2 समझ में आता है।
cbrandolino 13

23

अपने करियर के पहले चरणों में (यानी पूर्व-पीएचपी), मैं एक पर्ल गुरु था, और पर्ल गुरुदोम का एक प्रमुख पहलू नियमित अभिव्यक्ति की महारत है।

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

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


2
मैं इसे पर्याप्त नहीं बढ़ा सकता।
कैफ़ीक्यू

8
मैं जिज्ञासु हूं: क्या आप regexp के रूप में धाराप्रवाह पढ़ते हैं जैसा कि आप उन्हें लिखते हैं?
पेटेरचेन

7
मुझे आशा है कि आप नियमित रेगेक्स प्रशिक्षण सत्र आयोजित कर रहे हैं और / या अपने कोड से नरक का दस्तावेजीकरण कर रहे हैं; अन्यथा आप अपने सहकर्मियों के लिए एक बुरा सपना बना रहे हैं। जिस समय आपने लिखा है कि रेगेक्स को सौ बार खो दिया जा सकता है, लोग यह समझने की कोशिश कर रहे हैं कि "एलिगेंट रेक्स" क्या कर रहा है।
जेफ क्नेख्त

3
इतना महान। आप इन टिप्पणियों में यहीं प्यार और नफरत करने वाले रागों के बीच रस्साकशी सुन सकते हैं।
डेन रे

1
@बेन ली: मुझे ऐसा लगता है - ओटीओएच, मैंने कभी भी जंगली में टिप्पणी नहीं की। रेगेक्स के साथ कुछ समस्याएं शीतलता के दृष्टिकोण पर आधारित हो सकती हैं।
पेटेरचेन

16

इसके विपरीत। लोग regex parrotting कर रहे हैं बुराई मेम रास्ता भी अक्सर IMO हैं। यह स्पष्ट है कि preg_match में अति प्रयोग किया जाता है php, लेकिन यह कम स्पष्ट है कि ऐसा करना (PHP में) समझदारी है।

मैं इतना आगे जाऊंगा और अनुमान लगाऊंगा कि यह स्ट्रिंग कार्यों का उपयोग करने के लिए php भूमि में अभी तक एक और microoptimization है। कई और कई उपयोगी हैं, और वे आमतौर पर बेहतर विकल्प हैं। लेकिन आपको preg_matchकई strposऔर ifजंजीरों के पक्ष में नहीं भागना चाहिए । क्योंकि व्यवहार में यह पता चला है, लिबस्प्रे अक्सर पीएचपी की तुलना में तेज होता है, स्ट्रिंग विकल्प की तलाश में लूप निष्पादित कर सकता है

हाल ही के उदाहरण के रूप में मुझे एहसास हुआ, अगर एक स्ट्रिंग सभी-लोअरकेस का परीक्षण करती है:

 if ($string == strtolower($string))

से अधिक पठनीय है:

 if (!preg_match("/[A-Z]/", $string))

और आप मान लेंगे कि यह पहले से तेज है, क्योंकि यह ऑल-PHP है। लेकिन वास्तव में रेगेक्स केवल एक बार स्ट्रिंग पर दिखता है, और एक अपरकेस लेटर मिलते ही नकारात्मक स्थिति को समाप्त कर सकता है। स्ट्रेटोलॉवर () दृष्टिकोण हालांकि दो बार स्ट्रिंग पर दिखता है। पहले स्ट्रेटोलोवर () प्रत्येक अक्षर पर पुनरावृत्ति करके, इसकी तुलना करके और इसे अपरकेस करके एक स्ट्रिंग डुप्लिकेट बनाता है। फिर ==एक बार फिर उनकी तुलना करते हुए मूल और प्रतिलिपि पर पुनरावृत्तियाँ।

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

(मैं xhtml-regexes के बारे में @ बॉबिन के मज़ेदार जवाब के बारे में एक और शेख़ी जोड़ने के लिए लुभाया , और यह हाल ही में कैसे अक्सर एक बहुत ही अनपेक्षित तरीके से जुड़ा हुआ है। और नीचे दिए गए अधिक उद्देश्य उत्तर अनदेखा कर दिए जाते हैं।)


1
मैं आपके उदाहरण से सहमत हूं; फिर भी, इस विशेष मामले में, मैं olstrtolower () in को वैसे भी पसंद करूंगा: गैर-महत्वपूर्ण कोड में, यहां तक ​​कि इतना बड़ा (अन्य कार्यान्वयन के लिए अपेक्षाकृत) निष्पादन समय अनुकूलन महत्वहीन है - जब तक आप निचले मामले का मूल्यांकन नहीं करना चाहते हैं एक विशाल पाठ फ़ाइल का नेस, लेकिन मैं ऐसे मामले की कल्पना नहीं कर सकता जिसमें यह उपयोगी होगा।
cbrandolino 12

1
@cbrandolino: वहाँ कोई चर्चा नहीं। यह सामान केवल प्रासंगिक होना चाहिए और नेस्टेड छोरों के लिए मूल्यांकन किया जाना चाहिए, जहां यह एक तथ्यात्मक अंतर ला सकता है
mario

4
+1 इस तथ्य के लिए कि लोग हमेशा उन्हें कोसते हैं, जितना वे समर्थित हैं उससे कहीं अधिक।
परिक्रमा

1
"रेगेक्सपी बैशर्स" में से एक के रूप में: यह एक-लाइनर को कम या ज्यादा व्यक्त करने के लिए मजेदार है जो "मैनुअल" स्ट्रिंग पार्सिंग नीड्स 30 लाइनों के लिए है। हालांकि, रखरखाव सबसे यथार्थवादी उदाहरणों में ग्रस्त है। इसके अलावा, जब उन्हें अनवैलिड इनपुट पर लागू करने की कोशिश की जाती है, तो अस्वीकृत इनपुट के लिए उपयुक्त डायग्नोस्टिक्स बनाने के लिए अतिरिक्त कलाबाजी की आवश्यकता होती है। मेरे लिए, यह प्रोटोटाइप "केवल लेखन" कोड है - त्वरित स्क्रिप्ट के लिए अच्छा है, लंबे समय से रहने वाले ऐप्स को चूसता है।
पेट्रीचेन

1
कोई भी व्यक्ति जो /xसंज्ञानात्मक मंथन की कोहनी के लिए व्हाट्सएप के लिए अनुमति देने के लिए मोड में अपने सभी regexes नहीं लिख रहा है , और टिप्पणियों के लिए यह समझाने के लिए कि चीजें क्यों की जा रही हैं, निश्चित रूप से उसके कानों को बॉक्सिंग करना चाहिए। लेकिन उचित जटिलता के वास्तविक अवशेषों के लिए, आपको व्याकरणिक regexes के माध्यम से टॉप-डाउन डिज़ाइन को लागू करने पर विचार करने की आवश्यकता है । एक बार प्रकाश को देखने के बाद, आप कभी वापस नहीं जाएंगे /@#$^^@#$^&&*)@#/
23

8

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

उनके निम्नलिखित फायदे हैं:

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

यह उन्हें उन परिस्थितियों के लिए आकर्षक बनाता है जिनके लिए वे अनुकूल हैं, लेकिन लोग उन्हें संदर्भों में उपयोग कर सकते हैं जहां वे सबसे अच्छा उपकरण नहीं हैं, क्योंकि:

  • यह न समझें कि वे जो मिलान कर रहे हैं, उसे regexp (जैसे। HTML) का उपयोग करके व्यक्त नहीं किया जा सकता है।
  • आलसी (बुरे तरीके से) हैं - वे एक उपकरण को जानते हैं और पहचानते हैं कि यह जो वे कर रहे हैं उसके लिए सबसे अच्छा उपकरण नहीं है लेकिन यह समस्याओं का 95% समय के बिना काम करेगा और एक विशेष सीखने के प्रयास का 95% लेता है पार्सर या स्क्रैच से एक लिखना।
  • वे इस बात से अनजान हैं कि बेहतर उपकरण मौजूद हैं।

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

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

ऐसा क्यों है कि हर कोई HTML के छोटे-छोटे बिट्स को पूरी तरह से पार्स ट्री में एक पूर्ण विकसित वेब पेज को पार्स करने के साथ भ्रमित करता है? यह वास्तव में बेवकूफ है। मेरा विश्वास करो, जब मैं HTML पृष्ठों को संपादित करता हूं vi, तो आप शर्त लगाते हैं कि मैं इसका उपयोग :%s/foo/bar/gcकरता हूं । यदि यह एक संपादक के लिए पर्याप्त है, तो यह एक स्क्रिप्ट के लिए पर्याप्त है।
23

6

हम्म, मैं केवल अनुमान लगा सकता हूं। हो सकता है कि कुछ लोगों ने अनुभव किया हो कि उनके कोड की 30 पंक्तियों को 20-वर्ण-लंबे रेगेक्स द्वारा प्रतिस्थापित किया गया था, इसलिए उनके लिए कुछ और उपयोग करना गलत लगता है जब रेगेक्स का उपयोग किया जा सकता है।


4

यह कुछ लोगों के विचार से फिट बैठता है। मैं उन्हें पसंद नहीं करता, लेकिन मेरे पास ऐसे दोस्त हैं जो regexps में सोचते हैं। मुझे लगता है कि उनके मस्तिष्क का मिलान वाला भाग औपचारिक तर्क की तुलना में अधिक उजागर है। :-)


6
हमारे विकासवादी इतिहास के संदर्भ में जो तर्क के लिए खड़ा है। व्याकरण को परिभाषित करने या नपुंसकता की खोज करने से पहले हम पैटर्न का मिलान कर रहे थे।
ग्लेनट्रॉन

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

@Orbling: सवाल यह नहीं है कि वे अच्छे या बुरे हैं, लेकिन क्यों कुछ लोग उन्हें अधिक उपयोग करते हैं और अन्य नहीं।
लेन्नर्ट रेग्रोब

सवाल हो सकता है, लेकिन आपका जवाब दोनों के बजाय एक या दूसरे प्रकार के दिमाग का खेल है।
परिक्रमा

मुझे नहीं लगता कि "सुझाव" सही शब्द है।
लेनार्ट रेगेब्रुक

3

मुझे लगता है कि रेगेक्स की सर्वव्यापकता तार की सर्वव्यापकता के कारण है। स्ट्रिंग सबसे सरल डेटा संरचना है, पहला जो हम में से अधिकांश सीखते हैं। चूंकि हमारे सभी कोड प्रतीकात्मक रूप में लिखे गए हैं, इसलिए प्रोग्रामर के लिए प्रतीकात्मक रूप में मॉडलिंग के बारे में कुछ विचार करना स्वाभाविक है। लेकिन अगर हमारी प्रोग्रामिंग भाषा किसी भी प्रतिरोध की पेशकश करती है जब हम अपने चालाक नए प्रतीकात्मक रूपों के लिए इसके सिंटैक्स का विस्तार करने की कोशिश करते हैं, तो वे सभी उद्धरणों के बीच समाप्त हो जाते हैं। रिलेशनल डेटा मॉडल में एसक्यूएल होता है। XML डेटा मॉडल में XQuery है। लेकिन विनम्र स्ट्रिंग डेटा मॉडल के बारे में क्या? Regex!

कल ही, मैं एक चमकदार नए जावास्क्रिप्ट फ्रेमवर्क के लिए एपीआई देख रहा था जो एचटीएमएल 5 गेम के विकास का समर्थन करता है। इसमें मुख्य उप-प्रणालियों का वर्णन करने के लिए एक घोषणात्मक तंत्र है जो आपके खेल की आवश्यकता होगी। कोई उन विशेषताओं को कैसे निर्दिष्ट करता है? JSON? धाराप्रवाह डॉट नोटेशन? एक सरणी? नहींं - एक स्ट्रिंग जिसमें अल्पविराम होता है और व्हाट्सएप-अलग-अलग फीचर नामों की सूची होती है। मुझे आश्चर्य है कि यह उस सूची को कैसे पार्स करता है ...?


2

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

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

रेगेक्स, किसी भी अन्य शक्तिशाली उपकरण की तरह, उचित मॉडरेशन में उपयोग किया जाना चाहिए - बहुत अधिक नहीं, बहुत कम नहीं। और जब तक प्रदर्शन एक बड़ी चिंता का विषय नहीं होता है, तब तक एक एकल रेक्सक्स कई बार लिखने के लिए और स्ट्रिंग ऑपरेशन की एक श्रृंखला से डिबग करने में आसान हो सकता है।


2

हम्म, वर्तमान जवाब तकनीकी पहलुओं पर बहुत ज्यादा केंद्र, और पठनीयता पेशेवरों / विपक्ष (जो है एक महत्वपूर्ण बिंदु)। तो मुझे PHP वातावरण / समुदाय पर इसे थोड़ा और स्थानांतरित करने का प्रयास करने दें:

  • PHP Perls छोटी सौतेली बहन है । और पर्ल का एक अभिन्न हिस्सा नियमित अभिव्यक्ति हैं (उन्होंने उस सामान का आविष्कार किया, वे नहीं थे?)। इसलिए यह एक कारण है कि regexps PHP में भी व्यापक हैं।
  • उपयोग के मामले PHP के संयोग से नियमित अभिव्यक्ति के लिए उपयोग के मामले के विपरीत ज्यादा नहीं है। PHP संरचनात्मक रूप से HTML पृष्ठों को एक साथ गोंद करने के लिए उपयोग किया जाता है। और regexps पाठ पर काम करते हैं। (क्या WReach ने कहा)
  • सूक्ष्म अनुकूलन । जैसा कि पहले उल्लेख किया गया है: लोग कथित गति के बाद अक्सर रेग्क्स और / या PHP स्ट्रिंग फ़ंक्शन का उपयोग करते हैं। PHP हलकों में एक मुख्य समस्या, regexps के लिए विशिष्ट नहीं है।
  • नियमित अभिव्यक्ति अंतर्निहित हैं । पाइथन में, जावा में, सी # में, रूबी में? उपलब्धता है, लेकिन एक अतिरिक्त मॉड्यूल को लोड करने में बाधा है। और देखें कि कैसे PHP या जावास्क्रिप्ट में जहां यह एक मुख्य विशेषता है, उपयोग पैटर्न अलग है। एक और प्रदर्शन: सीएसएस जहां यह अधिक बार उपयोग किया जा रहा है।
  • पीएचपी मैनुअल की गलती है। यह अक्सर होता है। नियमित अभिव्यक्तियाँ आसानी से खोजी जा सकती हैं, और मैंने इस मज़ेदार तथ्य को स्थगित कर दिया है क्योंकि यह अपनी स्पष्टता में उबाऊ है: सभी लानत ट्यूटोरियल और PHP परिचय पुस्तकें हमेशा नियमित अभिव्यक्तियों के बारे में सिखाती हैं, लेकिन उपयोग के मामलों पर शिक्षित करने में विफल रहती हैं।
  • स्ट्रिंग एपीआई PHP में वही लोग है कि आप मैजिक कोट और नाम स्थान \ विभाजक लाया द्वारा डिजाइन किया गया था। यह जावा की तुलना में बेहतर है, लेकिन इसकी संपूर्णता में ग्लैमरस नहीं है। विशेष रूप से अगर तार वस्तुओं (पायथन को देखें) के रूप में दोगुना हो सकते हैं, तो स्ट्रिंग फ़ंक्शन regexps से आगे निकल सकते हैं।

लेकिन वह सिर्फ साइड नोट्स के रूप में। मेरा मानना ​​है कि यह वैसे भी ज्यादातर अवधारणात्मक और तकनीकी कारण हैं जो सामान्य रूप से अति प्रयोग और / या नियमित अभिव्यक्ति को तेज करते हैं। फिर भी PHP और इसके यूज़रबेस में कुछ गुण हैं, जो इसे कंपाउंड करते हैं, और हम इसके बारे में SO पर अधिक प्रश्न क्यों देखते हैं [उद्धरण वांछित!] और वे "रुग्ण आकर्षक" हैं।


1

मुझे नियमित अभिव्यक्ति पसंद है सामान्य तौर पर मुझे कोड की 20 पंक्तियों की तुलना में उन्हें पढ़ना / समझना आसान लगता है, मुझे उन्हें बदलना होगा। लघु नियमित अभिव्यक्तियाँ जल्दी से पढ़ी और समझी जाती हैं और उन्हें बनाए रखना अपेक्षाकृत आसान होता है (यदि अभिव्यक्ति बदलती है तो आपके पास बदलने के लिए कोड की 20 पंक्तियों के माध्यम से बदलने के लिए केवल एक पंक्ति है)। ऐसे समय होते हैं जहां उनका दुरुपयोग किया जाता है लेकिन कई अन्य चीजें हैं।

कारण शायद आप उनमें से बहुत अधिक दुर्व्यवहार देखते हैं, क्योंकि आपके ब्राउज़िंग स्टैकऑवरफ्लो का PHP अनुभाग है क्योंकि मुझे यकीन है कि आप जानते हैं कि वहाँ बहुत सारे अपरिपक्व अपरिपक्व PHP प्रोग्रामर हैं।


1

क्यों नियमित रूप से अभिव्यक्ति इतनी रुचिकर है?

वे नहीं हैं। वे वास्तव में नरक के रूप में बदसूरत हैं। और समझ से बाहर। वे एक घृणा है जिसे जल्द से जल्द मार दिया जाना चाहिए।

अब, यह कहा जा रहा है, मैं थोड़ा पर्ल ऐप डीबग करने जा रहा हूं। यह मदद नहीं कर सकता; दुर्भाग्यपूर्ण, वे अभी भी कभी-कभी नौकरी के लिए सबसे अच्छा साधन हैं।


4
मुझे यह कहने का शौक है कि नियमित अभिव्यक्ति न तो "नियमित" है और न ही "अभिव्यंजक" है
एंड्रयू नाई 12

2
यदि आप उन्हें नहीं समझते हैं तो वे बदसूरत और समझ से बाहर हैं। एक बार जब आप रेगेक्स के ज़ेन को प्राप्त कर लेते हैं, तो वे वास्तव में काफी सुरुचिपूर्ण होते हैं।
डैन रे

1
-1 तय करने के लिए कि सभी प्रोग्रामर अस्पष्ट होना पसंद करते हैं, और फिर किसी अन्य संभावित स्पष्टीकरण पर विचार नहीं करते हैं। ... बताते हुए कि आपको क्यों लगता है कि वे बदसूरत हैं या समझ से बाहर हैं।
मैकनील

1
@Macneil - कृपया, (हालाँकि हाँ, मेरे विचार उस पंक्ति के साथ हैं), जब तक कि आप मुझे उद्धृत नहीं कर रहे हैं, यह नहीं बताता कि मैंने ऐसा कुछ कहा है, जो मैंने नहीं किया (आपकी टिप्पणी का पहला भाग)। जहाँ तक आपके सवाल, आप उन्हें सुंदर लगता है ?! ... मैं नही। और चूंकि यह एक व्यक्तिपरक साइट है, और यह एक व्यक्तिपरक राय है, मुझे इसके बारे में विस्तार से बताने की इच्छा नहीं है। न ही मैं कोशिश करूंगा, उस बात के लिए।
रुके

1
@ देखें - मुझे लगता है कि ज्यादातर लोग एक जटिल नियमित अभिव्यक्ति को देखते हैं, सभी नियमित अभिव्यक्ति बदसूरत हैं, और फिर सोचना बंद कर दें। तथ्य यह है, वे एक बहुत ही सुंदर और अभिव्यंजक उपकरण हैं यदि आप उनके बारे में अपने पूर्वाग्रह को स्थापित कर सकते हैं। BTW, अपने तर्क से, बहुत सारे प्रोग्रामर बीजगणित नहीं कर सकते हैं, इसलिए बीजगणित शायद स्वाभाविक रूप से बुराई है और इसे समाप्त कर दिया जाना चाहिए क्योंकि यह स्पष्ट रूप से बहुत समझ में नहीं आता है।
दान रे

0

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


0

नियमित अभिव्यक्तियाँ बहुत आकर्षक होती हैं क्योंकि वे शक्ति को बढ़ाती हैं। आप बहुत कम पात्रों में बहुत जटिल काम कर सकते हैं।

समस्या यह है कि मानक नियमित अभिव्यक्ति निर्माण किया जाता है नहीं ट्यूरिंग-पूर्ण जिसका अर्थ है वहाँ कार्यक्रमों आप बस एक नियमित अभिव्यक्ति के साथ लागू नहीं कर सकते हैं कि, और लोगों को नहीं है पता है जब वे नियमित अभिव्यक्ति के स्पष्ट शक्ति से आकर्षित कर रहे हैं।

यह - मुझे लगता है - "अब उन्हें दो समस्याएं हैं" के jwz- उद्धरण का कारण है ।

मुझे लगता है कि पर्ल नियमित अभिव्यक्तियाँ ट्यूरिंग-पूर्ण हैं, लेकिन स्पष्ट रूप से यह अभी तक निर्णायक साबित नहीं हुआ है या अभी तक अव्यवस्थित नहीं हुआ है।


0

क्योंकि यह एक परिमित राज्य मशीन को प्रोग्राम करने का एक प्रभावी तरीका है, जो एक शक्तिशाली उपकरण है जब यह लागू होता है। यह मूल रूप से FSMs की प्रोग्रामिंग के लिए स्वयं की भाषा है, जो यदि आप भाषा जानते हैं, तो उपयोगी है, यदि आप नहीं करते हैं।


0

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

यही बात पर्ल, ऑक, लिनक्स और सब कुछ के बारे में कही जा सकती है जिसमें चमकदार बटन या अच्छे रंग का सिंटैक्स नहीं है। तो, यह "तुच्छ कार्यों" में जोड़ा जटिलता की तरह है, बस कुछ छोरों, विभाजन, एक स्विच, कुछ जादू फेंकना और यही वह है, जो कुछ काम कर सकता है। लेकिन ठीक है, अगर आप सड़क के दूसरी तरफ हैं, तो रेगीज़ सुंदर कुकी कटर हैं जो बिना किसी खराब छोरों या डिबग के अधिक सामान के सिग्नल सिग्नल की तरह दिखते हैं। मुझे उनके द्वारा प्रदान किए जाने वाले लचीलेपन के लिए भी पसंद है। जब पैटर्न में परिवर्तन होता है, तो आप केवल रेगेक्स को बदलते हैं, एल्गोरिथ्म को नहीं, या टूल / जो भी हो, और यह अच्छा है और फिर से काम कर रहा है। और चूंकि वे एक जादुई स्ट्रिंग हैं, आप चाहें तो इसे सोर्सकोड के बाहर रख सकते हैं। और एक और बात जो मुझे हैरान कर देती है, अगर आप एक रेगेक्स लिखते हैं जो 20+ वर्ण लंबा है, तो ऐसा लगता है कि आपने बहुत कुछ पूरा किया है, कम से कम मेरे लिए, यह सिर्फ इतना साफ और कॉम्पैक्ट है। मैं एक आलसी प्रोग्रामर भी हूं, मुझे अच्छी पहचान और टिप्पणियों के साथ बहुत सारे कोड लिखना और मिश्रण में कुछ कीड़े जोड़ना पसंद नहीं है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.