मैं फ़्लोचार्ट के बजाय स्यूडोकोड का उपयोग कब करूंगा?

Question

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

1. मैं बाहर योजना बनाने के लिए स्यूडोकोड का उपयोग कब करूंगा और फ्लोचार्ट का उपयोग कब करूंगा? या वास्तव में प्रोग्रामिंग करने से पहले दोनों करना बेहतर है। विशेष रूप से JAVA में एक छोटे से आर्केड खेल के लिए, क्योंकि यह मेरी अगली परियोजना है।
2. मैंने देखा है कि स्यूडोकोड वास्तविक फ्लोचार्ट के बजाय वास्तविक कोड के समान है। क्या यह स्यूडोकोडिंग को बेहतर बनाएगा क्योंकि आप अनिवार्य रूप से स्यूडोकोड को अपने प्रोग्राम में कॉपी / पेस्ट करते हैं (निश्चित रूप से, आपको भाषा को फिट करने के लिए इसे बदलना होगा। मैं उस हिस्से को समझता हूं)।
3. क्या प्रोग्रामिंग करते समय इन दोनों का उपयोग करना व्यावहारिक है? विशेष रूप से वही खेल जो पहले उल्लेख किया गया था। धन्यवाद।

Comments

जाहिर है, आप फ्लोचार्ट्स का उपयोग नहीं करेंगे जहां आपको कोई प्रवाह नहीं मिला है - यानी, लगभग सभी घोषणात्मक संस्थाओं के लिए।

— एसके-तर्क

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

— रॉबर्ट हार्वे

@RobertHarvey, FSM आरेख (जो अनिवार्य रूप से, फ़्लोचार्ट हैं) का उपयोग अक्सर हार्डवेयर डिज़ाइन में किया जाता है

— SK-Logic

Answer 1

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

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

आपके सवाल विस्तार से:

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

Comments

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

— HLGEM

Answer 2

छद्म कोड पर

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

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

फ़्लोचार्ट पर

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

Answer 3

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

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

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

Answer 4

छद्म कोड उन लोगों को एक विचार का प्रतिनिधित्व करने के लिए होता है जो कम से कम कोड की मूल बातें समझते हैं। फ़्लोचार्ट्स समान चीज़ को समझने के लिए बाकी सभी के लिए सुंदर चित्र खींच रहे हैं।

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

Answer 5

फ़्लोचार्ट्स उच्च स्तर के अमूर्त हैं जो आपको योजना बनाते हैं कि चीजों को कैसे आगे बढ़ना चाहिए, उदाहरण के लिए

अगर x मरता है y जीतता है

उन्हें यह निर्भर करने की आवश्यकता नहीं है कि आप कक्षाओं और विधियों के संदर्भ में कार्यक्रम को कैसे डिज़ाइन कर रहे हैं, दूसरी ओर छद्म कोड निम्न स्तर का अमूर्त प्रदान करता है (हालांकि यह वास्तव में निर्भर करता है)

अगर (isdead (s)) y.win ()

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

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

Answer 6

आप जिस कोड को लिख रहे हैं उसकी प्रकृति पर मैं विचार करूंगा। अगर यह होता है:

1. अत्यधिक पुनरावृत्ति / पुनरावर्ती
2. जटिल तरीकों से शाखाएँ
3. कई प्रणालियों में लागू किया गया है, जिसे आप प्रतिनिधित्व करना चाहते हैं

पहले दो मामलों में, स्यूडोकोड एक बड़ी तस्वीर आरेख की तुलना में उत्तरोत्तर कठिन हो जाता है। दूसरी ओर, कोड जो ज्यादातर रैखिक है, अविश्वसनीय रूप से उबाऊ आरेख बनाता है जो वास्तव में इस प्रक्रिया को समझने में कठिन बनाता है क्योंकि यह कितना ऊपर उड़ता है।

तीसरे मामले के लिए, फ़्लोचार्ट उन प्रक्रियाओं का प्रतिनिधित्व करने में बेहतर होते हैं जो सिस्टम की सीमाओं को पार करते हैं और पूरी प्रक्रिया का प्रतिनिधित्व करते हैं।

Answer 7

1. आपको जो भी सहज महसूस हो उसका उपयोग करना चाहिए। उस ने कहा, मेरी धारणा है कि इन दिनों प्रोग्राम नियंत्रण को स्केच करने के लिए फ्लोचार्ट का भारी उपयोग नहीं किया जाता है; एक चीज़ के लिए, वे आमतौर पर असंरचित होते हैं, छद्मकोश की तुलना में। UML जैसे वर्ग-निर्भरता आरेखों का उपयोग करना अधिक सामान्य है, ताकि आपकी वास्तुकला का उच्च स्तर पर वर्णन किया जा सके। इसके अलावा, यदि आपके आवेदन में एक राज्य मशीन है, तो एक (फ्लोचार्ट-जैसे) राज्य मशीन आरेख आवश्यक है।
2. मुझे लगता है कि आप यहाँ सही हैं। काम करने का एक तरीका यह है कि आप अपने स्रोत फ़ाइल में टिप्पणियों के रूप में अपने छद्मकोड को लिखना शुरू करें, और उनके बीच वास्तविक कार्यान्वयन लाइनें डालें।
3. फिर से, जो भी आपको सहज लगे, उसका उपयोग करें। यदि आप निश्चित नहीं हैं, तो उन दोनों को आज़माएं; मुझे उम्मीद है कि आपका अभ्यास आपके लिए सबसे उपयोगी होगा। जब तक मैं विशेष रूप से जटिल निष्पादन आदेश को अनलिंक करने की कोशिश कर रहा हूं, मुझे व्यक्तिगत रूप से फ्लोचार्ट उपयोगी नहीं लगता।

Answer 8

जब आप जावा लिख ​​सकते हैं तो छद्म कोड क्यों लिखें? मैंने जावा, एक अच्छा आईडीई पाया है, और जावदोक एक प्रोग्रामिंग समस्या को समझने का सबसे आसान तरीका है - कम से कम एक ऑब्जेक्ट ओरिएंटेड । (और एक आर्केड गेम ओओ होना चाहिए ।) इसके लिए भाषा को जमीन से डिजाइन किया गया था। इसका सरल और सीधा है। (कई उद्देश्यों के लिए बहुत सरल, शायद, लेकिन सबसे अच्छी चीज जो मैंने इसके लिए देखी है।) Javadoc में हाइपरटेक्स्ट और, एक IDE के माध्यम से, कोड में खुद को और अधिक समझने योग्य "आरेख" के लिए बना सकते हैं, जिससे आप भी आकर्षित कर सकते हैं। कागज की एक बड़ी शीट। जावा कोड किसी भी छद्म कोड के रूप में सरल है और एक अच्छा सौदा अधिक कठोर है। और एक बार जब आप इसे "आरेखित" और "छद्म" कोडित कर लेते हैं, तो कार्यक्रम वास्तव में चलेगा!

Comments

जावा और अन्य को लंबे समय तक हवा दी जा सकती है। "सार्वजनिक स्थैतिक शून्य मुख्य .." या "system.out.println" या कैमलबैक संकेतन के साथ लंबे पहचानकर्ता, लंबे समय तक घुमावदार हैं। फिर ऐसे अपवाद जिन्हें 2 बी ने पकड़ा है..और किसी भी पुस्तकालय से हो सकते हैं लंबे समय से घुमावदार। मुझे याद है 10 साल पहले एक फ़ाइल खोलना। नए बफ़रडर (new InputStreamReader (System.in)) जैसा कुछ; जाहिरा तौर पर अब आसान है mkyong.com/java/… लेकिन वास्तव में आप जिस भी लाइब्रेरी को कॉल करते हैं, वह लंबी घुमावदार हो सकती है, न कि स्यूडोकोड की तरह जो संक्षिप्त रूप में हो सकता है जैसा कि आप कल्पना कर सकते हैं

— barlop

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

— barlop

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

— राल्फचिनपिन

ऐसा कहते हैं कि आप एक फ़ाइल खोलना चाहते हैं, क्या आप देखते हैं कि ओपनफ़ाइल ("c: \ blah \ file") का छद्मकोड इसे करने के लिए जावा से छोटा है? या जो प्रिंट "dfdfd" यह करने के लिए जावा से छोटा है? मैंने स्यूडोकोड और कई कक्षाओं के पृष्ठ (अभी तक) नहीं किए हैं। आंशिक रूप से 'क्योंकि मैंने उम्र में बड़े कार्यक्रम नहीं लिखे हैं) आंशिक रूप से' क्योंकि मुझे नहीं लगता कि मैं ऐसा करूंगा, मुझे लगता है कि मैं कुछ छद्मकोड लिखूंगा और फिर इसे लागू करूंगा। कोई अन्य छद्म कोड यदि कोई है, तो उच्च स्तर होगा। मेरे पास निर्माणकर्ताओं सहित सभी वर्गों और विधियों की एक सूची हो सकती है। तो मुझे पता है कि कौन सी कक्षाएं हैं और मुझे इसका एक उदाहरण मिल सकता है ..

— बार्लोप

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

— बार्लोप

Answer 9

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

यह थोड़ा प्रतिबंधात्मक महसूस कर सकता है, क्योंकि आपको संक्षिप्त विवरण बॉक्स में रखना होगा। और यदि आपका प्रोग्राम बहुत रैखिक है और आपके छोरों और यदि तुच्छ हैं, तो मुझे इसका कोई फायदा नहीं दिखता है।

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

तो, अपने लिए उपयोगी है।

उनका उपयोग दूसरों से संवाद करने के लिए भी किया जा सकता है।