@mark-lazarides @Roald87 @philippleidig @jozefchmelar आइए यहां सम्मेलनों के बारे में चर्चा करते हैं ... त्वरित चैट के लिए सुस्त; गतिविधि पर नज़र रखने के लिए यहां चर्चा

• मेरी राय में गुणों को "IsEnabled" के रूप में परिभाषित किया जाना चाहिए। नाम ही पहले से ही इंगित करना चाहिए कि यह किस प्रकार का है।

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

• Inxton या tc.prober का उपयोग करने के लिए "fbComponent" के प्रत्येक आधार वर्ग की विरासत आवश्यक है?

• जब नामकरण टाइप करने की बात आती है, तो मैं व्यक्तिगत रूप से थोड़ा कट्टरपंथी हूं और आमतौर पर उपसर्ग छोड़ देता हूं। इंटरफेस, संदर्भ और पॉइंटर्स को छोड़कर।
  जैसे

  नामकरण टाइप करें

| ब्लॉक प्रकार | संकेतन | उपसर्ग | उदाहरण |
| :---------------- | :----------- | :----------- | :------------------------------------------------- -- |
| एफबी/कक्षा का नाम | पास्कलकेस |नहीं | Cyclinder |
| ENUM प्रकार का नाम | पास्कलकेस |नहीं | MachineState.Start |
| इंटरफ़ेस नाम | पास्कलकेस | I | ICyclinder |
| समारोह का नाम | पास्कलकेस |नहीं | Add() |
| संरचना का नाम | पास्कलकेस | नहीं | Data |
| संघ का नाम | पास्कलकेस | नहीं | Control |

@philippleidig

• मेरी राय में गुणों को "IsEnabled" के रूप में परिभाषित किया जाना चाहिए। नाम ही पहले से ही इंगित करना चाहिए कि यह किस प्रकार का है।

पूरी तरह से सहमत।

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

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

• Inxton या tc.prober का उपयोग करने के लिए "fbComponent" के प्रत्येक आधार वर्ग की विरासत आवश्यक है?

नहीं, इसके लिए न तो कोई विशिष्ट आवश्यकता है और न ही Inxton और न ही tc.prober। हम इसे इस तरह इस्तेमाल करते हैं। ComponentBase एक अमूर्त वर्ग है जिसमें कुछ सार्वजनिक अनुबंध (मैनुअल विधि, आदि) हैं, लेकिन यह घटकों के लिए कुछ सामान्य सुविधाओं को लागू कर सकता है। मैं विरासत का बहुत बड़ा प्रशंसक नहीं हूं (मुझे रचना पसंद है), लेकिन इस मामले में मैं भविष्य के लिए कुछ विकल्प खोलना चाहता हूं।

इनक्सटन में यदि आप एक संग्रह में सभी घटकों को एकत्र करना चाहते हैं तो आप ऐसा कर सकते हैं जब something is copmonent उसके लिए तंत्र है।

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

• जब नामकरण टाइप करने की बात आती है, तो मैं व्यक्तिगत रूप से थोड़ा कट्टरपंथी हूं और आमतौर पर उपसर्ग छोड़ देता हूं। इंटरफेस, संदर्भ और पॉइंटर्स को छोड़कर।
  जैसे

नामकरण टाइप करें

ब्लॉक प्रकार संकेतन उपसर्ग उदाहरण
एफबी/क्लास का नाम पास्कलकेस नंबर Cyclinder
ENUM प्रकार का नाम PascalCase No MachineState.Start
इंटरफ़ेस नाम पास्कलकेस I ICyclinder
समारोह का नाम पास्कलकेस नंबर Add()
संरचना का नाम पास्कलकेस नं Data
यूनियन का नाम पास्कलकेस नंबर Control

उपसर्गों का प्रशंसक भी नहीं है। तालिका हमारे द्वारा उपयोग किए जाने वाले उपसर्गों की प्रणाली से मिलती-जुलती है ... लेकिन क्या हमें फिर से इससे छुटकारा पाने का फैसला करना चाहिए, इससे मुझे खुशी होगी।

ज्यादातर मामलों में मुझे उपसर्गों का उपयोग करने में कोई लाभ नहीं दिखता है। मैं @philippleidig के प्रस्ताव से सहमत हूं।

मैं कहूंगा कि सूचक और संदर्भ यहां अपवाद हैं।

मैंने पीआर #5 . में अपने सम्मेलनों का प्रस्ताव रखा

सदस्य नामकरण और प्रकार नामकरण

मुझे उपसर्ग का उपयोग करने में कोई लाभ नहीं दिख रहा है। यह मेरी किसी भी तरह से मदद नहीं करता है।

सदस्य चर

कक्षा (एफबी) सदस्य चर छिपाए जाने चाहिए और छोटे नाम से शुरू होने चाहिए
~ पास्कलवीएआर{विशेषता 'छिपाएं'}ट्रिगर: बूल;{विशेषता 'छिपाएं'}काउंटर: आईएनटी;{विशेषता 'छिपाएं'}एनालॉगस्टैटस: एनालॉगस्टैटस;END_VAR~

@jozefchmelar

ज्यादातर मामलों में मुझे उपसर्गों का उपयोग करने में कोई लाभ नहीं दिखता है। मैं @philippleidig के प्रस्ताव से सहमत हूं।

मैं कहूंगा कि सूचक और संदर्भ यहां अपवाद हैं।
मैं
मैंने पीआर #5 . में अपने सम्मेलनों का प्रस्ताव रखा

सदस्य नामकरण और प्रकार नामकरण

मुझे उपसर्ग का उपयोग करने में कोई लाभ नहीं दिख रहा है। यह मेरी किसी भी तरह से मदद नहीं करता है।
मैं

सदस्य चर

कक्षा (एफबी) सदस्य चर छिपाए जाने चाहिए और छोटे नाम से शुरू होने चाहिए

    VAR
        {attribute 'hide'}
        trigger : BOOL;
        {attribute 'hide'}
        counter : INT;
        {attribute 'hide'}
        analogStatus : AnalogStatus;
    END_VAR

• छिपे हुए चर विज्ञापनों पर दिखाई नहीं देंगे, इसलिए यदि एचएमआई पर उनकी कोई आवश्यकता नहीं है तो उन्हें छिपाया जा सकता है। लेकिन अगर हमें उन्हें एचएमआई में देखने की जरूरत है तो हमें 'छुपाएं' विशेषता का उपयोग नहीं करना चाहिए।
• Tc3 केस असंवेदनशील है इसलिए trigger (चर नाम) और Trigger (संपत्ति का नाम) विरोध करेंगे। जैसा कि मेरा अनुमान है, हमें इसे _ के साथ उपसर्ग करना होगा

पूरी तरह सहमत

विशेषता "सशर्त शो" भी है। लेकिन इसका उपयोग केवल संकलित पुस्तकालय के संयोजन के साथ किया जा सकता है।
https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/8095402123.html &id=7685156034373049758
चूंकि मुझे लगता है कि हम एक खुला पुस्तकालय प्रदान करेंगे, इसका केवल सीमित अर्थ होगा।

_ सदस्य चर के लिए उपसर्ग के रूप में @PTKu ने कहा।

मैं आम तौर पर नामकरण सम्मेलनों और सी # के नाम चयन से चिपकना पसंद करता हूं।

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

@philippleidig वापसी मूल्यों के साथ आपका क्या मतलब है? इस मामले में उन्हें त्रुटि जांच के रूप में उपयोग किया जाता है? आमतौर पर वापसी मूल्य विधि पर निर्भर करता है। CalculcateArea एक REAL `LREAL` लौटाएगा।

सुझाए गए चर नामकरण पर पूरी तरह सहमत हैं!

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

@philippleidig वापसी मूल्यों के साथ आपका क्या मतलब है? इस मामले में उन्हें त्रुटि जांच के रूप में उपयोग किया जाता है? आमतौर पर वापसी मूल्य विधि पर निर्भर करता है। CalculcateArea एक REAL``LREAL लौटाएगा।

@ Roald87 विचार यह होगा कि एक क्रिया करने वाले घटक की विधि क्रिया पूर्ण होने पर 'सत्य' वापस आ जाएगी (MoveToHome() जब होम सेंसर/स्थिति पहुंच गई)। यह आवश्यक होने पर अन्य रिटर्न प्रकारों को नहीं रोकता है।

सुझाए गए चर नामकरण पर पूरी तरह सहमत हैं!

मेरे पास सरणी के बारे में एक सुझाव होगा। इनक्सटन कंपाइलर के लिए एक औपचारिक आवश्यकता है कि ट्रांस-पाइल्स केवल 0 आधारित सरणियाँ हैं। सी # में उपयोग किए जाने पर भ्रम को रोकने का कारण है।

_array : बूल की सरणी [0..10]; // ट्रांस-पाइल्स
जबकि
_array : बूल का ऐरे [1..10]; // ट्रांस-पाइल नहीं करता है

इस पर कोई टिप्पणी?

ट्विनकैट एचएमआई (TE2000) के लिए समान

ट्विनकैट एचएमआई (TE2000) के लिए समान

वास्तव में एचएमआई के साथ एरे को सिंक में रखना बहुत सुविधाजनक होगा!

@philippleidig || @ Roald87 क्या आप में से कोई भी सरणियों के बारे में पीआर सम्मेलन करेगा तो pls ... मुझे रेपो में अधिक योगदानकर्ता देखना पसंद है :)।

मेरे पास सरणी के बारे में एक सुझाव होगा। इनक्सटन कंपाइलर के लिए एक औपचारिक आवश्यकता है कि ट्रांस-पाइल्स केवल 0 आधारित सरणियाँ हैं। सी # में उपयोग किए जाने पर भ्रम को रोकने का कारण है।

_array : बूल की सरणी [0..10]; // ट्रांस-पाइल्स
जबकि
_array : बूल का ऐरे [1..10]; // ट्रांस-पाइल नहीं करता है

इस पर कोई टिप्पणी?

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

// Declaration
NUMBER_OF_DRIVES : INT := 10;
drives  : ARRAY[1..NUMBER_OF_DRIVES] OF I_Drive;

// now in the code
FOR i := 1 to NUMBER_OF_DRIVES DO
   drives[i].SomethingCool();
END_FOR

// Compared to

// Declaration
drives : ARRAY[0..(NUMBER_OF_DRIVES -1) ] OF I_Drive;
// Code
FOR i := 0 to (NUMBER_OF_DRIVES -1) DO
   drives[i].SomethingCool();
END_FOR

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

मुझे लगता है कि तरीकों को वापस करना चाहिए जो विधि के लिए उचित है। विधि का नाम आपको इसे समझने में मदद करेगा।

अर्थात

IF NOT piece.PassesValidation() THEN
 LogError('Piece does not pass validation');
END_IF

// OR

IF sequence.Finished THEN
  axis.Disable(); // No return type necessary.
  state := WaitForAxisDisabled;
END_IF

@ Roald87 विचार यह होगा कि एक क्रिया करने वाले घटक की विधि क्रिया पूर्ण होने पर 'सत्य' वापस आ जाएगी (MoveToHome() जब होम सेंसर/स्थिति पहुंच गई)। यह आवश्यक होने पर अन्य रिटर्न प्रकारों को नहीं रोकता है।

मुझे वास्तव में सार्वजनिक विधि को बार-बार कॉल करने का दृष्टिकोण पसंद नहीं है, जहां वह विधि बार-बार कार्यक्षमता निष्पादित कर रही है जब तक कि यह सही न हो जाए। एक ऐसा मामला है जो मुझे लगता है कि यह स्वीकार्य है (यदि इंटरफ़ेस पर "निष्पादित" प्रकार की विधि है, लेकिन इसके लिए काम करने के बेहतर तरीके भी हैं, मुझे विश्वास है)।

इसके साथ समस्याएं;

• आप उस वर्ग पर निष्पादन पथ बना सकते हैं जिसे समवर्ती रूप से बुलाया जा सकता है। अर्थात

atEnd :=  axis.GoToEnd();
atBeginning := axis.GoToBeginning();

• कक्षाओं को आंतरिक रूप से अपने राज्य का प्रबंधन करना चाहिए। विधियों का उपयोग उस राज्य के अनुरोध और संशोधन करने के लिए किया जा सकता है, और गुणों का उपयोग स्थिति तक पहुंचने या साधारण स्थिति को भी सेट करने के लिए किया जा सकता है।
• आप विधि का नाम कैसे देते हैं ताकि यह स्पष्ट हो कि इसका उपयोग कैसे और क्यों किया जा रहा है? अक्ष.GoToEndTrueWhenComplete ()?
• क्या होगा यदि कक्षा की अंतर्निहित स्थिति इस तरह से बदलती है जो उस कॉल को चलाने के तरीके को संशोधित करती है?
• दौड़ की स्थिति अधिक आसानी से उत्पन्न की जा सकती है। यदि हम बार-बार किसी चीज़ पर .Enable() को कॉल करते हैं, लेकिन हमें एक स्कैन के लिए एक गलती मिलती है, तो .Enable() वैसे भी "कैरी ऑन कॉलिंग जब तक यह हो गया" दृष्टिकोण का उपयोग करके सक्षम हो सकता है। इसके बजाय यह होना चाहिए। RequestEnable: BOOL, जो इंगित करता है कि अनुरोध के बिंदु पर अंतर्निहित स्थितियां सही हैं (कॉलिंग कोड को उस बिंदु पर वापस गिरने की इजाजत देता है)। यदि अनुरोध किया जा सकता है, तो कॉलिंग कोड .IsEnabled और .InError को पूरा करने के लिए निगरानी कर सकता है।

@philippleidig ट्विनकैट एचएमआई से परिचित नहीं है। गैर 0 आधारित सरणियों को वहां कैसे संभाला जाता है?

@mark-lazarides

मुझे लगता है कि तरीकों को वापस करना चाहिए जो विधि के लिए उचित है। विधि का नाम आपको इसे समझने में मदद करेगा।
मैं

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

घटक के उपभोक्ता कोड में कुछ इस तरह से रोका जाना चाहिए
~atEnd:=axis.GoToEnd ();शुरुआत में: = अक्ष। गोटोबीगिनिंग ();~

executing methods true $ लौटाने पर स्वच्छ घोषणात्मक उपयोग की अनुमति देता है।

मेरे मन में कुछ इस तरह है:

~~~
वीएआर
_राज्य: आईएनटी;

END_VAR

मामला _राज्य का
0:
IF (अक्ष। मूवएब्सोल्यूट (स्थिति: 100.0)) तब
_राज्य:= 1;
अगर अंत;
1:
IF(axis.MoveRelative(स्थिति: 100.0)) तब
_राज्य:= 2;
अगर अंत;
2:
IF (अक्ष। मूवएब्सोल्यूट (स्थिति: 300.0)) तब
_राज्य:= 3;
अगर अंत;
3:
_राज्य:= 0;
END_CASE
~~~

इसे कम किया जा सकता है

~~~
वीएआर
_राज्य: आईएनटी;

END_VAR

मामला _राज्य का
0:
प्रतीक्षा करें (अक्ष। मूवएब्सोल्यूट (स्थिति: 100.0), 1);
1:
प्रतीक्षा करें (अक्ष। मूव रिलेटिव (स्थिति: 100.0), 2);
2:
प्रतीक्षा करें (अक्ष। मूवएब्सोल्यूट (स्थिति: 300.0), 3);
3:
प्रतीक्षा करें (सच, 0);

END_CASE

=================================

विधि प्रतीक्षित
VAR_INPUT
किया: बूल
अगला राज्य: आईएनटी;
END_VAR
अगर (किया गया) तब
_राज्य: = अगला राज्य;

अगर अंत;

~~~
संपादित करें: मुझे लगता है कि घटक एकल पीएलसी कार्य में प्रयोग किया जाता है

यह कोड के उपभोग पर प्रतिबंध लगाता है। यदि उपभोक्ता गलत क्रम में उनका उपयोग करता है तो हमारे घटकों को त्रुटियों के लिए उत्तरदायी नहीं होना चाहिए। उन्हें सभी बातचीत के लिए अच्छी प्रतिक्रिया देनी चाहिए। वे अनिवार्य रूप से "काम" नहीं करेंगे (यानी res := axis.MoveTo(Position:=100); को axis.Enable() $ से पहले कॉल करना काम नहीं करेगा), लेकिन उपभोग कोड को सभी बिंदुओं पर पर्याप्त जानकारी दी जानी चाहिए ताकि यह समझ सके कि यह कहां समस्या है।

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

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

@ मार्क-लाज़राइड्स सही! मैं execute methods (चलिए उन्हें इस तरह कहते हैं) चक्रीय तर्क को लागू नहीं करना चाहिए। मैंने यह मान लिया था कि हम पहले क्या चर्चा कर रहे हैं कि हम यह सुनिश्चित करते हैं कि चक्रीय तरीके से निष्पादित करने की आवश्यकता को या तो एफबी के शरीर में या Cyclic पद्धति में रखा जाएगा; जिसे उपभोक्ता के कार्यक्रम में किसी उपयुक्त स्थान पर बुलाया जाना चाहिए।

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

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

कोई आपत्ति नहीं मार्क, हमें निष्पादन विधियों को चक्रीय रूप से कॉल करने की आवश्यकता नहीं है, लेकिन यदि हम करते हैं तो यह कोई समस्या नहीं होनी चाहिए।

मैं नहीं देखता कि एक विधि ऑपरेशन के परिणाम को वापस क्यों नहीं कर सका।

मुझे लगता है कि हमें कुछ और जटिल घटकों के साथ आना चाहिए और इन विचारों को प्रोटोटाइप करने के लिए (वायवीय पिस्टन इस चर्चा के लिए पर्याप्त जटिल नहीं है) मुझे लगता है कि हम ड्राइव/अक्ष से शुरू कर सकते हैं।

सहमत, पीटर।

धागे के नाम के कारण, मुझे लगा कि हम इसे एक सम्मेलन के रूप में लक्षित कर रहे हैं! क्षमा करें अगर मुझे गलत समझा है।

क्रिस के पास इस समय एक पीआर के रूप में एक मूल अक्ष ब्लॉक है - मैंने इस पर टिप्पणी की है, लेकिन इस पर और अधिक नजर रखने की जरूरत है।

@ मार्क-लाज़राइड्स को कोई माफी की जरूरत नहीं है मार्क, हम यहां स्वतंत्र रूप से चर्चा करने के लिए हैं, मैं कल पीआर पर एक नजर डालूंगा ...

@philippleidig @Roald87 @dhullett08 घटक डिजाइन के बारे में भी यहां चर्चा करें

PLCopen दस्तावेज़ों से लिए गए कुछ यादृच्छिक सुझाव।

plcopen_coding_guidelines_version_1.0.pdf

स्थिरांक
ALLCAPS में होना चाहिए ताकि वे आसानी से पहचाने जा सकें

स्वीकार्य नाम लंबाई
न्यूनतम 4 वर्ण अधिकतम 24 वर्ण?

PLCopen दस्तावेज़ों से लिए गए कुछ यादृच्छिक सुझाव।

plcopen_coding_guidelines_version_1.0.pdf

लिंक के लिए धन्यवाद

स्थिरांक
ALLCAPS में होना चाहिए ताकि वे आसानी से पहचाने जा सकें

मैं

स्वीकार्य नाम लंबाई
न्यूनतम 4 वर्ण अधिकतम 24 वर्ण?

लंबे नाम तब तक कोई समस्या नहीं होनी चाहिए जब तक कि वे इरादा व्यक्त न करें, 24 वर्ण पर्याप्त होने चाहिए, हालांकि मैं अधिकतम सीमा नहीं रखूंगा। पात्र। बहुत छोटे नाम वास्तव में संदिग्ध हैं, वे 4 वर्णों से अधिक होने चाहिए।

@Seversonic आपकी टिप्पणियों को दस्तावेज़ में जोड़ा गया ...

चर्चा जारी यहां #11

मैं वास्तव में आपके सम्मेलनों को पसंद नहीं करता लेकिन मुझे लगता है कि आपकी परियोजना काफी दिलचस्प है!
व्यक्तिगत रूप से मैं एक अधिक क्लासिक तरीका पसंद करता हूं
एफबी_ एफबी फ़ंक्शन ब्लॉक
M_Add () विधि
P_पैरामीटर प्रोप

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

चर्चाओं की शुरुआत से ही मतदान यहां दिया गया है:

TcOpen.Survey.Result.pdf

इसके अलावा, यहां चर्चा हुई और स्लैक चैनल में, @dhullett08 TcOpen रेपो में भी कुछ हो सकता है।

एक सामान्य भावना थी (या कम से कम मैं इसे इस तरह से व्याख्या करता हूं) कि हमें उपसर्गों को छोड़ देना चाहिए यदि वे उपयोगी जानकारी नहीं देते हैं या आधुनिक आईडीई वह जानकारी प्रदान करता है जो हमने अतीत में उपसर्गों के साथ व्यक्त किया था।

मैं समझता हूं कि यह व्यक्तिगत प्राथमिकताओं के बारे में है और वास्तव में इसे करने का कोई सही या गलत तरीका नहीं है। बस हमें किसी बात पर सहमत होना है।

यहां समापन पर चर्चा यहां जारी है: https://github.com/TcOpenGroup/TcOpen/discussions/11