🌨️ 🚌 👨🏿‍🎓 Erlang। कोड डिजाइन दिशानिर्देश 🔙 🖖 🐕

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

1. उद्देश्य

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

2. एरलांग संरचना और शब्दावली

सभी एरलंग सबसिस्टम को मॉड्यूल में विभाजित किया गया है। बदले में मॉड्यूल कार्यों और विशेषताओं से मिलकर बनता है।
कार्य या तो आंतरिक हो सकते हैं या तीसरे पक्ष के मॉड्यूल में उपयोग के लिए निर्यात किए जा सकते हैं।
विशेषताएँ '-' से शुरू होती हैं और मॉड्यूल की शुरुआत में रखी जाती हैं।

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

धाराएँ लिंकिंग ( लिंक कमांड) के माध्यम से एक दूसरे के काम की निगरानी कर सकती हैं। जब कोई थ्रेड निष्पादित या ड्रॉप करता है, तो एक संकेत स्वचालित रूप से सभी संबंधित थ्रेड्स के लिए भेजा जाता है।
थ्रेड के लिए इस सिग्नल की डिफ़ॉल्ट प्रतिक्रिया तुरंत ऑपरेशन को समाप्त करने के लिए है।
लेकिन इस व्यवहार को trap_exit ध्वज सेट करके बदला जा सकता है, जिसमें संकेतों को संदेशों में परिवर्तित किया जाता है और कार्यक्रम द्वारा संसाधित किया जा सकता है।

शुद्ध कार्य ऐसे कार्य हैं जिनका मूल्य केवल इनपुट डेटा पर निर्भर करता है और कॉल के संदर्भ पर निर्भर नहीं करता है। इस व्यवहार से, वे सामान्य गणितीय लोगों के समान हैं। जो शुद्ध नहीं हैं उन्हें साइड इफेक्ट्स वाले कार्य कहा जाता है।

एक दुष्प्रभाव आमतौर पर तब होता है जब फ़ंक्शन:

संदेश भेजता है
संदेश स्वीकार करता है
बाहर निकलने का आह्वान किया
एक बीआईएफ को कॉल करता है जो स्ट्रीम के वातावरण को बदलता है (जैसे कि / 1 , पुट / 2 , इरेज़ / 1 , प्रोसेस_फ्लैग 2 )

3 डिजाइन सिद्धांत

3.1 मॉड्यूल से संभव के रूप में कुछ कार्यों का निर्यात करें

Erlang में मॉड्यूल मूल संरचनात्मक इकाई हैं। इनमें बड़ी संख्या में फ़ंक्शंस हो सकते हैं, लेकिन केवल निर्यात सूची में शामिल लोग ही तृतीय-पक्ष मॉड्यूल के लिए उपलब्ध होंगे।

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

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

3.2 मॉड्यूल के बीच निर्भरता कम करने की कोशिश करें

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

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

परिणामस्वरूप, कॉल कोड को कुछ इस तरह प्रस्तुत किया जाना चाहिए:

और नहीं:

3.3 पुस्तकालयों में आमतौर पर इस्तेमाल किए जाने वाले कोड को ही रखें।

पुस्तकालय में (मॉड्यूल) केवल संबंधित कार्यों का एक सेट होना चाहिए।

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

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

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

3.4 अलग मॉड्यूल में "हैक्स" और "गंदा कोड" अलग

अक्सर, किसी समस्या को हल करने के लिए "साफ" और "गंदे" कोड के उपयोग की आवश्यकता होती है।
ऐसे वर्गों को अलग-अलग मॉड्यूल में अलग करें।

उदाहरण के लिए, "गंदा कोड":

प्रक्रिया शब्दकोश का उपयोग करता है
erlang का उपयोग करता है : काफी पर्याप्त उद्देश्यों के लिए process_info / 1 :)
कुछ ऐसा करता है जो आप मूल रूप से करने की उम्मीद नहीं करते थे, लेकिन आपको करना था

जितना संभव हो उतना साफ कोड लिखने की कोशिश करें, और "गंदा", पहले जितना संभव हो उतना कम उपयोग करें, और दूसरे सभी संभावित दुष्प्रभावों और उपयोग की समस्याओं का दस्तावेज।

3.5 यह मत सोचो कि कॉलिंग फ़ंक्शन परिणाम का उपयोग कैसे करेगा

यह मत सोचो कि कॉलिंग फ़ंक्शन आपके परिणाम का उपयोग कैसे करेगा।

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

do_something(Args) -> case check_args(Args) of ok -> {ok, do_it(Args)}; {error, What} -> String = format_the_error(What), io:format("* error:~s\n", [String]), %% Don't do this error end.

ऐसा करना बेहतर है:

 do_something(Args) -> case check_args(Args) of ok -> {ok, do_it(Args)}; {error, What} -> {error, What} end. error_report({error, What}) -> format_the_error(What).

पहले मामले में, त्रुटि हमेशा कंसोल पर प्रदर्शित होती है, दूसरे में, त्रुटि विवरण बस वापस आ जाता है। एप्लिकेशन डेवलपर खुद तय कर सकता है कि इसके साथ क्या करना है - इसे अनदेखा करें या इसे error_report / 1 के साथ प्रिंट करें। किसी भी मामले में, वह यह चुनने का अधिकार रखता है कि त्रुटि होने पर क्या करना है।

3.6 कोड लॉजिक से सामान्य पैटर्न और व्यवहार निकालें

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

3.7 टॉप-डाउन डिज़ाइन

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

3.8 कोड को अनुकूलित करने की आवश्यकता नहीं है

विकास के प्रारंभिक चरण में कोड का अनुकूलन न करें। सबसे पहले, इसे सही ढंग से काम करें, और केवल तभी, यदि आवश्यक हो, तो अनुकूलन करें।

३.९ एक पूर्वानुमान कोड लिखें

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

3.10 दुष्प्रभावों से बचने की कोशिश करें

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

3.11 आंतरिक डेटा को मॉड्यूल छोड़ने की अनुमति न दें

एक उदाहरण के साथ प्रदर्शित करना सबसे आसान है। मान लीजिए कि एक कतार प्रबंधन कार्य है:

 -module(queue). -export([add/2, fetch/1]). add(Item, Q) -> lists:append(Q, [Item]). fetch([H|T]) -> {ok, H, T}; fetch([]) -> empty.

वह एक सूची के रूप में कतार का वर्णन करती है। और कुछ इस तरह इस्तेमाल किया:

 NewQ = [], %    Queue1 = queue:add(joe, NewQ), Queue2 = queue:add(mike, Queue1), ....

इससे कई मुद्दे सामने आते हैं:

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

इस तरह लिखना बेहतर है:

 -module(queue). -export([new/0, add/2, fetch/1]). new() -> []. add(Item, Q) -> lists:append(Q, [Item]). fetch([H|T]) -> {ok, H, T}; fetch([]) -> empty.

अब उपयोग इस तरह दिखेगा:

 NewQ = queue:new(), Queue1 = queue:add(joe, NewQ), Queue2 = queue:add(mike, Queue1), …

यह कोड ऊपर वर्णित कमियों से मुक्त है।

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

 Len = length(Queue) %

फिर से, समस्याएं, चूंकि उपयोगकर्ता फिर से दृश्य के साथ कार्यान्वयन को कठोरता से जोड़ता है, ऐसे कोड को बनाए रखना और पढ़ना मुश्किल है। इस मामले के लिए, एक अलग फ़ंक्शन प्रदान करना और मॉड्यूल में जोड़ना बेहतर है:

 -module(queue). -export([new/0, add/2, fetch/1, len/1]). new() -> []. add(Item, Q) -> lists:append(Q, [Item]). fetch([H|T]) -> {ok, H, T}; fetch([]) -> empty. len(Q) -> length(Q).

अब उपयोगकर्ता अपने कोड के बजाय कतार: len (कतार) को कॉल कर सकेगा।
इस कोड में, हम डेटा प्रकार कतार के कार्यान्वयन के विवरण से "सार" करते हैं। यानी दूसरे शब्दों में, कतार अब एक "सार डेटा प्रकार" है।
यह सब झंझट क्यों? व्यवहार में, यह आंतरिक प्रतिनिधित्व को बदलने के लिए एक आसान तंत्र बन गया, और अब आप उपयोगकर्ता कोड के साथ पिछड़े संगतता को तोड़ने के डर के बिना अपने मॉड्यूल के कार्यान्वयन को बदल सकते हैं। उदाहरण के लिए, एक बेहतर कार्यान्वयन के लिए, कोड को इस प्रकार फिर से लिखा गया है:

 -module(queue). -export([new/0, add/2, fetch/1, len/1]). new() -> {[],[]}. add(Item, {X,Y}) -> %   {[Item|X], Y}. fetch({X, [H|T]}) -> {ok, H, {X,T}}; fetch({[], []) -> empty; fetch({X, []) -> %       fetch({[],lists:reverse(X)}). len({X,Y}) -> length(X) + length(Y).

3.12 कोड को निर्धारक के रूप में संभव बनाएं

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

3.13 इनपुट डेटा की शुद्धता की लगातार जांच करने की आवश्यकता नहीं है

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

 %% Args: Option is all|normal get_server_usage_info(Option, AsciiPid) -> Pid = list_to_pid(AsciiPid), case Option of all -> get_all_info(Pid); normal -> get_normal_info(Pid) end.

यदि विकल्प आदर्श नहीं है या सभी हैं तो फ़ंक्शन विफल हो जाएगा। ऐसा होना चाहिए! जो कोई भी इस फ़ंक्शन को कहता है उसे नियंत्रित करना चाहिए कि इसे क्या पारित किया गया है।

3.14 चालक में हार्डवेयर तर्क को अलग करें

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

3.15 आप जो भी कार्य करते हैं उसी फ़ंक्शन में पूर्ववत करें

मान लीजिए कि एक कोड है जो एक फ़ाइल खोलता है, इसके साथ कुछ करता है और फिर इसे बंद कर देता है।

 do_something_with(File) -> case file:open(File, read) of, {ok, Stream} -> doit(Stream), file:close(Stream) %   Error -> Error end.

कृपया ध्यान दें कि किसी फ़ाइल को खोलना और बंद करना एक ही फ़ंक्शन में होता है। कोड को पढ़ना और समझना आसान है। लेकिन, उदाहरण के लिए, इस तरह के एक कोड को समझना मुश्किल है और फ़ाइल बंद होने पर यह तुरंत स्पष्ट नहीं है:

 do_something_with(File) -> case file:open(File, read) of, {ok, Stream} -> doit(Stream) Error -> Error end. doit(Stream) -> ...., func234(...,Stream,...). ... func234(..., Stream, ...) -> ..., file:close(Stream) %%

4 त्रुटि से निपटने

4.1 सामान्य कोड से अलग प्रसंस्करण

त्रुटि कोड के साथ सामान्य कोड को न मिलाएं। आपको सामान्य व्यवहार प्रोग्राम करना चाहिए। यदि कुछ गलत हो जाता है, तो प्रक्रिया तुरंत एक त्रुटि के साथ समाप्त होनी चाहिए। त्रुटि को ठीक करने और जारी रखने का प्रयास न करें। त्रुटि से निपटने के लिए एक और प्रक्रिया लेनी चाहिए।

4.2 "मुख्य त्रुटि" हाइलाइट करें

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

5 स्ट्रीम, सर्वर और संदेश

5.1 एक मॉड्यूल में सभी स्ट्रीम कोड लागू करें

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

5.2 एक सिस्टम बनाने के लिए थ्रेड्स का उपयोग करें

धाराएँ एक प्रणाली के मूल संरचनात्मक तत्व हैं। लेकिन उनका उपयोग न करें और संदेश भेजना जब केवल एक फ़ंक्शन को कॉल करना संभव हो।

5.3 पंजीकृत धाराएँ

धाराओं को उसी नाम के तहत पंजीकृत किया जाना चाहिए, जिस मॉड्यूल में उनका कोड है। इससे समर्थन में काफी सुविधा होगी। केवल उन धाराओं को पंजीकृत करें जिन्हें आप लंबे समय तक उपयोग करने की योजना बनाते हैं।

5.4 प्रत्येक शारीरिक रूप से समानांतर कार्रवाई के लिए सिस्टम में केवल एक धागा बनाएं

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

5.5 प्रत्येक धागे में केवल एक "भूमिका" होनी चाहिए

सिस्टम में धाराएँ विभिन्न भूमिकाएँ निभा सकती हैं। उदाहरण के लिए, क्लाइंट-सर्वर आर्किटेक्चर में, एक थ्रेड क्लाइंट और सर्वर दोनों हो सकता है, लेकिन दो भूमिकाओं को दो थ्रेड में अलग करना बेहतर होता है।
अन्य भूमिकाएँ:

पर्यवेक्षक ( पर्यवेक्षक ) - प्रवाह की निगरानी करता है और गिरावट के बाद उन्हें फिर से शुरू करता है;
कार्यकर्ता ( कार्यकर्ता ) - एक नियमित निष्पादन धारा, जिसमें त्रुटियां हो सकती हैं;
विश्वसनीय धागा (या सिस्टम, विश्वसनीय कार्यकर्ता ) - एक ऐसा धागा जिसमें त्रुटियां नहीं होनी चाहिए।

5.6 जब भी संभव हो सर्वर बनाने और प्रोटोकॉल के साथ काम करने के लिए सामान्य कार्यों का उपयोग करें

ज्यादातर मामलों में, सर्वर बनाने के लिए gen_server का उपयोग करना सबसे अच्छा समाधान है, क्योंकि यह सिस्टम की संरचना को बहुत आसान करेगा। डेटा ट्रांसफर प्रोटोकॉल को संसाधित करने के लिए भी यह सही है।

5.7 संदेशों में टैग जोड़ें

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

 loop(State) -> receive ... {Mod, Funcs, Args} -> %    apply(Mod, Funcs, Args}, loop(State); ... end.

यदि संदेश प्रसंस्करण {get_status_info, From, Option} को जोड़ना और उसके प्रसंस्करण को पहले ब्लॉक के तहत रखना आवश्यक हो जाता है, तो एक संघर्ष पैदा होगा और नया कोड कभी भी निष्पादित नहीं होगा।
यदि संदेश समकालिक हैं, तो परिणाम को भी टैग किया जाना चाहिए, लेकिन अनुरोध से अलग। उदाहरण के लिए: जब get_status_info टैग के साथ अनुरोध किया जाता है , तो प्रतिक्रिया स्थिति_info आना चाहिए। इस नियम का अनुपालन डिबगिंग की सुविधा प्रदान करता है।
यहाँ सही कोड का एक उदाहरण है:

 loop(State) -> receive ... {execute, Mod, Funcs, Args} -> %    apply(Mod, Funcs, Args}, loop(State); {get_status_info, From, Option} -> From ! {status_info, get_status_info(Option, State)}, %   loop(State); ... end.

5.8 अपने कोड से अज्ञात संदेशों की कतार साफ़ करें

कतार अतिप्रवाह से बचने के लिए प्रत्येक सर्वर को आने वाले सभी संदेशों को संसाधित करना चाहिए, उदाहरण के लिए इस तरह:

 main_loop() -> receive {msg1, Msg1} -> ..., main_loop(); {msg2, Msg2} -> ..., main_loop(); Other -> %   error_logger:error_msg( "Error: Process ~w got unknown msg ~w~n.",[self(), Other]), main_loop() end.

५.। सर्वर लिखते समय पूंछ पुनरावृत्ति का उपयोग करें

मेमोरी ओवरफ्लो से बचने के लिए टेल रिकर्सन का उपयोग करके सभी सर्वरों को लागू किया जाना चाहिए।
इस तरह न लिखें:

 loop() -> receive {msg1, Msg1} -> ..., loop(); stop -> true; Other -> error_logger:log({error, {process_got_other, self(), Other}}), loop() end, io:format("Server going down"). %    %    !

इस तरह बेहतर:

 loop() -> receive {msg1, Msg1} -> ..., loop(); stop -> io:format("Server going down"); Other -> error_logger:log({error, {process_got_other, self(), Other}}), loop() end. %

5.10 अपने सर्वर पर एक एक्सेस इंटरफेस बनाएं

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

 -module(fileserver). -export([start/0, stop/0, open_file/1, ...]). open_file(FileName) -> fileserver ! {open_file_request, FileName}, receive {open_file_response, Result} -> Result end. ...<code>...

5.11 टाइमआउट

संदेश प्राप्त करने के बाद उपयोग करते समय अत्यधिक सावधानी बरतें। सुनिश्चित करें कि आपके पास एक स्थिति है जब संदेश एक टाइमआउट के बाद आता है। (क्लॉज 5.8 देखें)।

5.12 आउटपुट सिग्नल का अवरोधन

संभव के रूप में कुछ धागे trap_exit ध्वज सेट करना चाहिए। लेकिन इसका उपयोग करना है या नहीं, यह अभी भी मॉड्यूल के उद्देश्य पर निर्भर करता है।

6 Erlang कोड सिफारिशें

6.1 संरचनाओं को संग्रहीत करने के लिए रिकॉर्ड का उपयोग करें

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

6.2 चयनकर्ताओं और निर्माणकर्ताओं का उपयोग करें

रिकॉर्ड को नियंत्रित करने के लिए चयनकर्ताओं और निर्माणकर्ताओं का उपयोग करें। रिकॉर्ड को कभी भी कॉर्टेज की तरह इस्तेमाल न करें।
एक उदाहरण:

 demo() -> P = #person{name = "Joe", age = 29}, #person{name = Name1} = P,% matching ... Name2 = P#person.name. %

इस तरह से रिकॉर्ड का उपयोग न करें:

 demo() -> P = #person{name = "Joe", age = 29}, {person, Name, _Age, _Phone, _Misc} = P. %

6.3 एक टैग किए गए फ़ंक्शन का परिणाम लौटाएं

इस तरह न लिखें:

 keysearch(Key, [{Key, Value}|_Tail]) -> Value; %%    ! keysearch(Key, [{_WrongKey, _WrongValue} | Tail]) -> keysearch(Key, Tail); keysearch(Key, []) -> false.

इस समाधान के साथ, {Key, Value} मान के रूप में गलत नहीं हो सकता। यहाँ सही कोड है:

 keysearch(Key, [{Key, Value}|_Tail]) -> {value, Value}; %%  . keysearch(Key, [{_WrongKey, _WrongValue} | Tail]) -> keysearch(Key, Tail); keysearch(Key, []) -> false.

6.4 सावधानी से पकड़ने और फेंकने के साथ प्रयोग करें

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

6.5 अत्यधिक सावधानी के साथ प्रक्रिया शब्दकोश का उपयोग करें

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

 tokenize([H|T]) -> ...; tokenize([]) -> case get_characters_from_device(get(device)) of %   get/1! eof -> []; {value, Chars} -> tokenize(Chars) end.

बेहतर फिर से लिखना:

 tokenize(_Device, [H|T]) -> ...; tokenize(Device, []) -> case get_characters_from_device(Device) of %   eof -> []; {value, Chars} -> tokenize(Device, Chars) end.

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

6.6 आयात का उपयोग न करें

आयात कोड को पढ़ना कठिन है। यह बेहतर है कि मॉड्यूल के कार्यों की सभी परिभाषाएं एक फ़ाइल में हों।

6.7 निर्यात कार्य

यह निर्दिष्ट करना आवश्यक है कि कार्यों का निर्यात क्यों किया जाता है:

उन्हें बाहरी पहुंच सक्षम करने के लिए
उपयोगकर्ता को एक इंटरफ़ेस प्रदान करने के लिए
स्पॉन के माध्यम से कॉल के लिए या मॉड्यूल के भीतर से ही आवेदन करें।

समूह-निर्यात और निर्यात के कारण पर टिप्पणी करें।

 %%   -export([help/0, start/0, stop/0, info/1]). %%    -export([make_pid/1, make_pid/3]). -export([process_abbrevs/0, print_info/5]). %%    -export([init/1, info_log_impl/1]).

7. कोड की शैलीगत और शाब्दिक डिजाइन के लिए सिफारिशें

7.1 भारी नेस्टेड कोड न लिखें

दृढ़ता से नेस्टेड कोड को संदर्भित करता है जिसमें कई मामले / अगर / ब्लॉक प्राप्त होते हैं तो अन्य मामले में नेस्टेड होते हैं / यदि ब्लॉक प्राप्त होते हैं। यह घोंसले के दो से अधिक स्तरों के लिए खराब रूप माना जाता है। ऐसे कोड को पढ़ना मुश्किल है। ऐसे कोड को छोटे कार्यों में तोड़ना बेहतर है।

7.2 ऐसे मॉड्यूल न लिखें जो बहुत बड़े हों

मॉड्यूल में 400 से अधिक लाइनों का कोड नहीं होना चाहिए। ऐसे मॉड्यूल को कई छोटे लोगों में तोड़ना बेहतर होता है।

7.3 ऐसे कार्य न लिखें जो बहुत लंबे हों

फ़ंक्शन 15-20 लाइनों से अधिक नहीं होना चाहिए। सिर्फ एक लाइन लिखकर समस्या को हल करने की कोशिश न करें।

7.4 एक पंक्ति में कई वर्ण न लिखें

एक पंक्ति में वर्णों की संख्या 80 से अधिक नहीं होनी चाहिए (A4 पर फिट होने के लिए)।
एर्लैंग में, लपेटने के बाद घोषित लाइनों को स्वचालित रूप से एक साथ चिपकाया जाता है।
उदाहरण के लिए:

 io:format("Name: ~s, Age: ~w, Phone: ~w ~n" "Dictionary: ~w.~n", [Name, Age, Phone, Dict])

7.5 नामकरण चर

एक चर के लिए सही (सार्थक) नाम चुनना काफी मुश्किल काम है।
यदि चर नाम में कई शब्द हैं, तो उन्हें '_' के माध्यम से अलग करना बेहतर है या CamelCase का उपयोग करें
किसी फ़ंक्शन में किसी वैरिएबल को अनदेखा करने के लिए '_' का उपयोग न करें, बेहतर है कि '_' के साथ वैरिएबल का नाम लिखें, उदाहरण के लिए _Name ।

7.6 समारोह का नामकरण

फ़ंक्शन का नाम उसके उद्देश्य को स्पष्ट रूप से प्रतिबिंबित करना चाहिए। परिणाम नाम के आधार पर अनुमानित होना चाहिए। मानक कार्यों के लिए मानक नामों का उपयोग करें (जैसे कि प्रारंभ , रोक , init , main_loop ...)।
विभिन्न मॉड्यूल से कार्य, लेकिन एक ही उद्देश्य के साथ, एक ही कहा जाना चाहिए (उदाहरण के लिए, मॉड्यूल: मॉड्यूल_इन्फो () )।
गलत फ़ंक्शन नाम चयन सबसे आम गलती है।
फंक्शन के नामों में कुछ रूढ़ियां इस विकल्प को बहुत आसान बनाती हैं। उदाहरण के लिए, उपसर्ग 'is_' का अर्थ है कि निष्पादन का परिणाम सही या गलत होगा ।

 is_...() -> true | false check_...() -> {ok, ...} | {error, ...}

7.7 नामकरण मॉड्यूल

एर्लैंग में एक फ्लैट मॉड्यूल नामकरण मॉडल है, अर्थात। उदाहरण के लिए, जावा में कोई पैकेज नहीं हैं (लेकिन, सटीक होने के लिए, वहाँ हैं, लेकिन व्यवहार में उनका अनुप्रयोग अभी तक लाभ की तुलना में अधिक समस्याएं लाता है)।
आमतौर पर, एक ही उपसर्ग का उपयोग यह इंगित करने के लिए किया जाता है कि मॉड्यूल किसी तरह जुड़े हुए हैं। उदाहरण के लिए, आईएसडीएन को निम्नानुसार लागू किया जाता है:
isdn_init
isdn_partb
isdn_ ...

7.8 कोड को सुसंगत रखें

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

 {12, 23, 45}

कोई बिना

 {12,23,45}

जैसे ही आप अपने लिए एक एकीकृत शैली विकसित करते हैं, उससे चिपके रहते हैं।

8 कोड प्रलेखन

8.1 कोड विशेषताएँ

आपको हेडर में मॉड्यूल विशेषताओं को हमेशा सही ढंग से सेट करना होगा। बताएं कि इस मॉड्यूल का विचार कहां से आया है, यदि कोड किसी अन्य मॉड्यूल पर काम करने के परिणामस्वरूप दिखाई देता है, तो इसका वर्णन करें।
कभी भी कोड चोरी न करें। स्रोत को निर्दिष्ट किए बिना चोरी कोड की नकल कर रहा है।
गुण उदाहरण:

-रिविजन ('रिविजन: 1.14')।
-प्रकाशित ('तिथि: 1995/01/01 11:21:11')।
-क्रिएट_बी ('एक्लस @ एरलंग')।
-मॉडिफाइड ('तारीख: 1995/01/05 13:04:07')।
-मोडिफाइ_बी ('mbj @ erlang')।

8.2 विनिर्देश के लिए लिंक छोड़ें

यदि कोड कुछ मानक लागू करता है, तो प्रलेखन के लिए एक लिंक छोड़ना सुनिश्चित करें (उदाहरण के लिए, RFC)।

8.3 सभी त्रुटियों का दस्तावेज

सभी त्रुटियों को एक अलग दस्तावेज़ में स्पष्ट रूप से वर्णित किया जाना चाहिए।
उन स्थानों के कोड में जहां तार्किक तार्किक संभव है, error_logger को कॉल करें:

error_logger : error_msg ( प्रारूप , {विवरणिका, Arg1 , Arg2 , ....})

और यह सुनिश्चित करें कि त्रुटि विवरण दस्तावेज़ में {Descriptor, Arg1, Arg2, ....} का वर्णन किया गया है।

8.4 सभी प्रकार के डेटा को संदेश में प्रेषित किया गया दस्तावेज़

धाराओं द्वारा प्रेषित संदेशों के रूप में टैग किए गए टुपल्स का उपयोग करें। संदेशों में रिकॉर्ड
का उपयोग विभिन्न मॉड्यूल के बीच संगतता सुनिश्चित करता है। संदेश विवरण दस्तावेज़ में इन सभी डेटा प्रकारों को दस्तावेज़ित करें।

8.5 टिप्पणी कोड

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

%% फ़ंक्शन के बारे में टिप्पणी
some_useful_functions ( उपयोगीअर्जुनमेंट ) -> एक
और_क्रियाएं ( उपयोगीअनुगमन ), %% पंक्ति के अंत में
टिप्पणी% टिप्पणी के बारे में
complex_stmnt के समान स्तर पर इंडेंटेशन complex_stmnt ,
...

8.6 प्रत्येक फ़ंक्शन पर टिप्पणी करें

यह दस्तावेज़ के लिए महत्वपूर्ण है:

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

एक उदाहरण:

%% ------------------------------------------------ ----------------------
%% समारोह: get_server_statistics / 2
%% उद्देश्य: एक प्रक्रिया से विभिन्न जानकारी प्राप्त करें।
%% आर्गन्स: विकल्प सामान्य है |
%% रिटर्न: {कुंजी, मान}
%% या {त्रुटि, कारण} (यदि प्रक्रिया मृत है) की एक सूची
%% --------------------- -------------------------------------------------
get_server_statistics ( विकल्प , Pid ) जब pid ( Pid ) ->
...

8.7 डेटा संरचनाएँ

विवरण के साथ रिकॉर्ड को परिभाषित किया जाना चाहिए। उदाहरण के लिए:

%% फ़ाइल: my_data_structures.h
%% ----------------------------------------- ----------------------------
%% डेटा प्रकार: व्यक्ति
%% कहाँ:
%% नाम: एक स्ट्रिंग (डिफ़ॉल्ट अपरिभाषित है)।
%% आयु: एक पूर्णांक (डिफ़ॉल्ट अपरिभाषित है)।
%% फोन: पूर्णांकों की एक सूची (डिफ़ॉल्ट [] है)।
%% तानाशाही: एक शब्दकोश जिसमें व्यक्ति के बारे में विभिन्न जानकारी होती है।
%% A {कुंजी, मान} सूची (डिफ़ॉल्ट खाली सूची है)।
%% ------------------------------------------------ ----------------------
- रिकॉर्ड ( व्यक्ति , {नाम, उम्र, फोन = [], तानाशाही = []})।

8.8 फ़ाइल हेडर, कॉपीराइट

प्रत्येक फ़ाइल को कॉपीराइट जानकारी से शुरू होना चाहिए। उदाहरण के लिए:

% %% ----------------------------------------------- ----------------------
%%% कॉपीराइट एरिक्सन टेलिकॉम AB 1996
%%%
%%% सभी अधिकार सुरक्षित। इस कंप्यूटर प्रोग्राम का कोई भी हिस्सा
%%% उपयोग नहीं किया जा सकता है , पुन: पेश किया जाता है, किसी भी पुनर्प्राप्ति प्रणाली में संग्रहीत किया जाता है, या प्रसारित किया जाता है,
%% किसी भी रूप में या किसी भी तरह से, इलेक्ट्रॉनिक, मैकेनिकल, फोटोकॉपी,
%% रिकॉर्डिंग, या अन्यथा
%% की पूर्व लिखित अनुमति के बिना एरिक्सन टेलीकॉम एबी।
% %% ----------------------------------------------- ----------------------

8.9 फ़ाइल हेडर, संस्करण इतिहास

प्रत्येक फ़ाइल का एक संस्करण इतिहास होना चाहिए जो दिखाता है कि किसने और किस उद्देश्य से बदलाव किया है।

%%%---------------------------------------------------------------------
%%% Revision History
%%%---------------------------------------------------------------------
%%% Rev PA1 Date 960230 Author Fred Bloggs (ETXXXXX)
%%% Intitial pre release. Functions for adding and deleting foobars
%%% are incomplete
%%%---------------------------------------------------------------------
%%% Rev A Date 960230 Author Johanna Johansson (ETXYYY)
%%% Added functions for adding and deleting foobars and changed
%%% data structures of foobars to allow for the needs of the Baz
%%% signalling system
%%%---------------------------------------------------------------------

8.10 ,

प्रत्येक फ़ाइल को मॉड्यूल के उद्देश्य के संक्षिप्त विवरण और निर्यात किए गए कार्यों की सूची के साथ शुरू करना चाहिए।

%%%---------------------------------------------------------------------
%%% Description module foobar_data_manipulation
%%%---------------------------------------------------------------------
%%% Foobars are the basic elements in the Baz signalling system. The
%%% functions below are for manipulating that data of foobars and for
%%% etc etc etc
%%%---------------------------------------------------------------------
%%% Exports
%%%---------------------------------------------------------------------
%%% create_foobar(Parent, Type)
%%% returns a new foobar object
%%% etc etc etc
%%%---------------------------------------------------------------------

यदि आप कोड का उपयोग करने के साथ किसी समस्या के बारे में जानते हैं या यदि कुछ अधूरा है, तो उनका वर्णन यहां करें। यह आपके कोड को आगे बढ़ाने में मदद करेगा।

8.11 पुराने कोड पर टिप्पणी न करें - इसे हटा दें

पुराना कोड हटाएं और संस्करण नियंत्रण प्रणाली में एक विवरण छोड़ दें। CSV आपकी मदद करेगा।

8.12 संस्करण नियंत्रण प्रणाली का उपयोग करें

अधिक या कम जटिल परियोजनाओं को संस्करण नियंत्रण (Git, SVN, आदि) का उपयोग करना चाहिए

9 आम गलतियाँ

case / if / receive

,
( )

put / get

10

10.1

प्रति मॉड्यूल एक अध्याय। इसमें प्रत्येक मॉड्यूल का विवरण और निर्यात किए जाने वाले सभी कार्यों का विवरण होना चाहिए:

नियुक्ति
इनपुट विवरण
आउटपुट विवरण
संभव उपयोग के मुद्दों और बाहर निकलें / 1 कॉल ।

10.2 संदेश का वर्णन

सिस्टम में उपयोग किए गए संदेशों का विवरण, केवल मॉड्यूल के अंदर उपयोग किए गए लोगों को छोड़कर

10.3 धागा विवरण

सभी पंजीकृत धाराओं और उनके लिए इंटरफेस का विवरण।
सभी गतिशील रूप से बनाई गई धाराओं और उनके लिए इंटरफेस का विवरण।

10.4 त्रुटियों का विवरण

सभी संभावित सिस्टम त्रुटियों का विवरण।

Erlang। कोड डिजाइन दिशानिर्देश