`ব্রেক` এবং `চালিয়ে যাওয়া programming খারাপ প্রোগ্রামিং অনুশীলনগুলি কি?


191

আমার বস অযৌক্তিকভাবে উল্লেখ করতে থাকে যে খারাপ প্রোগ্রামাররা breakএবং continueলুপগুলিতে ব্যবহার করে ।

আমি তাদের সব সময় ব্যবহার করি কারণ তারা বোঝায়; আমাকে আপনাকে অনুপ্রেরণা দেখাতে দিন:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

এখানে বক্তব্যটি হ'ল প্রথমে ফাংশনটি শর্তগুলি সঠিক কিনা তা পরীক্ষা করে, তারপরে প্রকৃত কার্যকারিতা কার্যকর করে। আইএমও একইভাবে লুপগুলির সাথে প্রযোজ্য:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

আমি মনে করি এটি পড়া এবং ডিবাগ করা সহজ করে তোলে; তবে আমি কোনও খারাপ দিকও দেখছি না।


2
কোনটি কি করে তা ভুলে যেতে খুব বেশি লাগে না।

57
না। এগুলি কখন ব্যবহার করবেন তা জানা কী। এগুলি টুলবক্সে সরঞ্জাম। আপনি এগুলি ব্যবহার করুন যখন তারা স্পষ্ট এবং সাফল্যের কোড সরবরাহ করে।
orj

67
এই স্টাইলের কোডিংয়ের পক্ষে আমি যথেষ্ট সমর্থন করতে পারি না। একাধিক স্তরের নেস্টেড শর্তাদি এই পদ্ধতির চেয়ে অনেক খারাপ। আমি কোডিং স্টাইলটি সম্পর্কে সাধারণত জঙ্গি নই, তবে এটি আমার জন্য প্রায় চুক্তিভঙ্গকারী।
এমিল এইচ

9
অবশ্যই আপনার বস কোড (যথেষ্ট) কোড লিখেন না। যদি তিনি তা করেন তবে তিনি জানতেন যে সমস্ত কীওয়ার্ড (হ্যাঁ, এমনকি goto) কোনও কোনও ক্ষেত্রে কার্যকর।
সাকিস্ক

57
খারাপ প্রোগ্রামাররা বিরতি ব্যবহার করে এবং চালিয়ে যাওয়ার অর্থ এই নয় যে ভাল প্রোগ্রামাররা তা করে না। খারাপ প্রোগ্রামাররা পাশাপাশি এবং পাশাপাশি ব্যবহার করে।
mouviciel

উত্তর:


240

যখন প্রথম চেক তৈরি করা হয় কোনও ব্লকের শুরুতে, তারা পূর্বশর্ত হিসাবে কাজ করে, তাই এটি ভাল it's

আশেপাশে কিছু কোড সহ ব্লকের মাঝখানে ব্যবহার করা হলে তারা লুকানো ফাঁদের মতো কাজ করে, তাই এটি খারাপ।


6
@ ক্লেইম: এটি যুক্তিযুক্ত হতে পারে যে যে কোনও রুটিনের বেশ কয়েকটি প্রস্থান পয়েন্ট রয়েছে তা হ'ল একটি দুর্বল ঘটনা। সঠিকভাবে ফ্যাক্টরড রুটিনে কেবল একটি জিনিস এবং একটি জিনিস করা উচিত।
বিট-টুইডलर

79
@ বিট-টুইডলার: এটি খুব সি-ইশ মানসিকতা। একটি অস্থায়ী পরিবর্তনশীল পরে পরিবর্তন করা যেতে পারে, সুতরাং এখান থেকে নীচে একটি একক টাইপো 20 লাইন সতর্কতার সাথে তৈরি ফলাফল মুছে ফেলতে পারে। তাত্ক্ষণিকভাবে প্রত্যাবর্তন (বা বিরতি, বা চালিয়ে যাওয়া) তবে অত্যন্ত স্পষ্ট: আমি এখন পড়া বন্ধ করতে পারি কারণ আমি জানি এটি সম্ভবত আরও নিচে পরিবর্তন করা যায় না । এটি আমার ছোট মস্তিষ্কের পক্ষে ভাল, কোডের মাধ্যমে সত্যই ট্রডিং সহজ করে তোলে।
ম্যাথিউ এম।

15
@ ম্যাথিউ আমি সম্মত আপনি যখন কোনও ফলাফল পান যা ব্লকের উদ্দেশ্যকে সন্তুষ্ট করে এমন কোনও ব্লক থেকে প্রস্থান করুন।
ইভান প্লেইস

8
@ বিট-টুইডলার - একক-বহির্গমন-পয়েন্ট নীতিটি একক-দায়িত্ব-নীতি থেকে পৃথক। আমি একমত নই যে চেকিং সর্বদা একক দায়িত্ব ডাব্লুআরটি অভিনয় থেকে পৃথক। আসলে "একক দায়িত্ব" আমাকে সর্বদা সাবজেক্টিভ শব্দ হিসাবে আঘাত করে। উদাহরণস্বরূপ, চতুষ্কোণ-সমাধানকারীতে, বৈষম্যমূলক গণনা করা কি আলাদা দায়িত্ব হওয়া উচিত? বা পুরো চতুর্ভুজ সূত্র একক দায়িত্ব হতে পারে? আমি যুক্তি দিয়ে বলছি যে এটি বৈষম্যমূলকদের জন্য আপনার আলাদা ব্যবহার আছে কিনা তার উপর নির্ভর করে - অন্যথায়, এটি পৃথক দায়িত্ব হিসাবে বিবেচনা করা সম্ভবত অতিরিক্ত মাত্রা।
স্টিভ 314

10
এই উত্তরটি কঠোর নিয়মের নয়, একটি থাম্বের নিয়ম। এটি বেশিরভাগ ক্ষেত্রেই কাজ করে, যদি আপনার প্রসঙ্গে এটি বোধগম্য হয় তবে এটি নির্দ্বিধায় ভাবেন।
ক্লাইম

87

আপনি ডোনাল্ড নথের 1974-এর পেপার স্ট্রাকচার্ড প্রোগ্রামিং পড়তে যেতে যেতে বিবৃতিতে পড়তে পারেন , যেখানে তিনি go toকাঠামোগতভাবে আকাঙ্ক্ষিত এর বিভিন্ন ব্যবহারগুলি নিয়ে আলোচনা করেছেন । এগুলির মধ্যে সমতুল্য breakএবং continueবিবৃতি অন্তর্ভুক্ত রয়েছে ( go toসেখানে ব্যবহারের অনেকগুলি আরও সীমিত নির্মাণে রূপান্তরিত হয়েছে)। আপনার বস কি নূথকে খারাপ প্রোগ্রামার বলার মতো?

(উদাহরণ আমাকে সুদ দেওয়া। সাধারণত, breakএবং continueযারা কোডের কোন টুকরা থেকে একটি এন্ট্রি এবং এক প্রস্থান মত অপছন্দ করা হয়, এবং ব্যক্তি যে সাজানোর এছাড়াও একাধিক উপর frowns returnবিবৃতি।)


8
একক প্রবেশ এবং প্রস্থান পয়েন্টগুলি ফাংশন এবং পদ্ধতি পছন্দ করে এমন বেশিরভাগ লোক প্যাস্কেলে বড় হয়েছিল। পাস্কাল আমি প্রথম যে ভাষা শিখেছিলাম তা নয়, তবে আমি আজও কোডটি কীভাবে গঠন করি তার উপরে এর গভীর প্রভাব ছিল। লোকেরা সর্বদা আমার জাভা কোডটি পড়া কতটা সহজ তা নিয়ে মন্তব্য করে। কারণ আমি একাধিক বহির্গমন পয়েন্টগুলি পাশাপাশি কোডের সাথে আন্তঃব্যবস্থার ঘোষণাকে এড়িয়ে চলেছি। আমি পদ্ধতির শীর্ষে একটি পদ্ধতিতে ব্যবহৃত প্রতিটি স্থানীয় পরিবর্তনশীল ঘোষণা করার জন্য যথাসাধ্য চেষ্টা করি। এই অনুশীলনটি পদ্ধতিগুলিকে সংহত করতে বাধ্য করে কোড র‌্যাম্বল এড়িয়ে চলে।
বিট-টুইডলার

5
পাস্কলেরও নেস্টেড ফাংশন ছিল। কেবল বলুন '...
শোগ 9

6
আমি যা মনে করি তা থেকে, লোকেরা ফাংশনে একাধিক রিটার্নের স্টেটমেন্ট পছন্দ না করার মূল কারণ হ'ল ডিবাগারগুলি সেগুলি সঠিকভাবে পরিচালনা করতে পারেনি। কোনও ফাংশন শেষে ব্রেকপয়েন্ট নির্ধারণ করা সত্যিকারের ব্যথা ছিল তবে আগের রিটার্ন স্টেটমেন্টের কারণে আপনি কখনও এটিকে আঘাত করেননি। আমি আজকাল প্রতিটি সংকলক ব্যবহার করি এটি এখন আর সমস্যা নয়।
ডাঙ্ক

28
@ বিট-টুইডলার: আমি সে সম্পর্কে তেমন নিশ্চিত নই। আমি আজও পাস্কালটি ব্যবহার করছি এবং আমি সাধারণত "সিঙ্গল এন্ট্রি একক প্রস্থান" বা কার্গো কাল্ট প্রোগ্রামিং হিসাবে কমপক্ষে এর একক-প্রস্থান অংশকে বিবেচনা করি। আমি শুধু বিবেচনা Break, Continueএবং Exitআমার টুলবক্স সরঞ্জাম হিসেবে; আমি সেগুলি ব্যবহার করি যেখানে এটি কোড অনুসরণ করা আরও সহজ করে তোলে এবং যেখানে এটি পড়তে জিনিস আরও কঠিন হয় সেগুলি ব্যবহার করি না।
ম্যাসন হুইলার

2
@ বিট-টুইডলার: এতে আমেন। আমি আরও যোগ করব যে একবার আপনি অন-স্ক্রিনে সহজে ফিট হয়ে যাওয়া ব্লকের নীচে নেমে গেলে একাধিক প্রস্থান পয়েন্টগুলি খুব কম ঝামেলা হয়ে যায়।
শোগ 9

44

তারা খারাপ বলে আমি বিশ্বাস করি না। এগুলি খারাপ যে ধারণাটি কাঠামোগত প্রোগ্রামিংয়ের দিন থেকেই আসে। এটি এই ধারণার সাথে সম্পর্কিত যে কোনও ফাংশনের অবশ্যই একটি একক প্রবেশ পয়েন্ট এবং একটি একক প্রস্থান পয়েন্ট থাকতে হবে, অর্থাৎ returnপ্রতিটি ফাংশনটিতে কেবল একটি ।

আপনার ফাংশনটি দীর্ঘ এবং আপনার যদি একাধিক নেস্ট লুপ থাকে তবে এটি কিছুটা অর্থবোধ করে। তবে আপনার ফাংশনগুলি সংক্ষিপ্ত হওয়া উচিত এবং আপনার লুপগুলি এবং তাদের দেহগুলি তাদের নিজের ছোট্ট ফাংশনে আবৃত করা উচিত। সাধারণত, একটি ক্রিয়াকলাপকে একক বহির্গমন পয়েন্ট রাখতে বাধ্য করার ফলে খুব সংশ্লেষিত যুক্তি দেখা যায়।

যদি আপনার ফাংশনটি খুব ছোট হয়, আপনার যদি একটি একক লুপ থাকে বা সবচেয়ে খারাপ দুটি নেস্ট লুপ থাকে এবং যদি লুপটির শরীর খুব ছোট হয় তবে এটি কী breakবা কী করবে তা খুব স্পষ্ট continue। এটি একাধিক returnবিবৃতি কী তাও স্পষ্ট ।

এই সমস্যাগুলি রবার্ট সি মার্টিন "ক্লিন কোড" এবং মার্টিন ফওলারের "রিফ্যাক্টরিং" তে সম্বোধন করেছেন।


12
"আপনার ফাংশনগুলি ছোট করুন Then তারপরে এগুলি আরও ছোট করুন" -রোবার্ট সি মার্টিন। আমি দেখেছি এটি আশ্চর্যজনকভাবে ভাল কাজ করে। প্রতিবার আপনি কোনও ফাংশনে কোডের একটি ব্লক দেখতে পান যাতে এটি কী করে তা ব্যাখ্যা করার জন্য কোনও মন্তব্যের প্রয়োজন হয়, বর্ণনামূলক নামের সাথে একটি পৃথক ফাংশনে এটিকে মোড়ানো। এমনকি যদি এটি কেবল কয়েকটি লাইন হয় এবং এমনকি এটি একবারে ব্যবহৃত হয়। এই অনুশীলনটি ব্রেক / চালিয়ে যাওয়া বা একাধিক রিটার্ন সহ বেশিরভাগ সমস্যা সরিয়ে দেয়।
দিমা

2
@ মিখাইল: সাইক্লোমেটিক জটিলতা সাধারণত এসএলওসি-র সাথে খুব দৃ strongly়ভাবে সম্পর্কিত হয়, যার অর্থ এই যে পরামর্শটি "দীর্ঘ ফাংশনগুলি লিখবেন না" সরল করে তোলা যেতে পারে।
জন আর স্ট্রোহম

3
একক বহির্গমন পয়েন্টের ধারণাটি ব্যাপকভাবে ভুল ব্যাখ্যা করা হয়। একসময়, ফাংশনগুলিতে তাদের কলকারীকে ফেরত দিতে হয় নি। তারা অন্য কোনও জায়গায় ফিরে আসতে পারে। এটি সাধারণত সমাবেশ ভাষায় করা হত। ফোর্টরানের জন্য এটির একটি বিশেষ নির্মাণ ছিল; আপনি অ্যাম্পারস্যান্ডের পূর্ববর্তী একটি স্টেটমেন্ট নম্বরটিতে পাস করতে পারেন CALL P(X, Y, &10)এবং ত্রুটির ক্ষেত্রে ফাংশনটি কলটির বিন্দুতে ফিরে আসার পরিবর্তে সেই বিবৃতিতে নিয়ন্ত্রণ সরিয়ে দিতে পারে।
কেভিন cline

উদাহরণস্বরূপ, লুয়ার সাথে দেখা হিসাবে @ কেভিঙ্কলাইন।
কিউস

1
@ cjsimon আপনি পেয়েছেন শুধুমাত্র ফাংশনগুলি ছোট হওয়া উচিত। ক্লাসগুলিও ছোট হওয়া উচিত।
দিমা

39

খারাপ প্রোগ্রামাররা বিস্মৃত কথা বলে (ঠিক সিথের মতো)। ভাল প্রোগ্রামাররা সম্ভবত পরিষ্কার সমাধান ব্যবহার করে ( অন্যান্য সমস্ত জিনিস সমান হচ্ছে )।

বিরতি ব্যবহার এবং ঘন ঘন চালিয়ে যাওয়া কোড অনুসরণ করা শক্ত করে তোলে। তবে যদি তাদের প্রতিস্থাপন করা কোডটিকে অনুসরণ করা আরও শক্ত করে তোলে তবে এটি একটি খারাপ পরিবর্তন।

আপনি যে উদাহরণটি দিয়েছেন তা অবশ্যই একটি পরিস্থিতি যেখানে বিরতি এবং অবিরতকে আরও মার্জিত কিছু দিয়ে প্রতিস্থাপন করা উচিত।


হ্যাঁ, আমি বেরিয়ে আসার ক্ষেত্রে উদাহরণগুলির শর্তগুলির সংখ্যা বাড়িয়ে দেখিয়েছি।
মিখাইল

9
আপনার প্রস্তাবিত প্রতিস্থাপন কোডের উদাহরণ কী? আমি ভেবেছিলাম এটি গার্ডের বক্তব্যগুলির একটি যুক্তিসঙ্গত উদাহরণ example
সিমগিনিজার

আমার কাছে মনে হয় "পরিষ্কার সমাধান সম্ভবত" সর্বদা ... সম্ভব? কীভাবে সেখানে "ক্লিয়ারেস্ট" সমাধান হতে পারে না? তবে, আমি নিখোঁজ হওয়ার জন্য কেউ নই, তাই সম্ভবত আপনি ঠিক বলেছেন।

@ নোকমপেন্ডে আপনি কী পাচ্ছেন তা আমি নিশ্চিত নই। এখানে "সম্ভাব্য" ইঙ্গিত দেয় না যে সেরা সমাধানটির অস্তিত্ব নেই - কেবলমাত্র নিখুঁত, চূড়ান্ত স্পষ্টতা কোনও জিনিস নয়। এটা বিষয়বস্তু সব পরে।
ম্যাথু

22

বেশিরভাগ লোক মনে করেন এটি একটি খারাপ ধারণা কারণ আচরণটি সহজেই অনুমানযোগ্য নয়। আপনি যদি কোডটি পড়ছেন এবং আপনি দেখতে পান while(x < 1000){}যে এটি x> = 1000 অবধি চলবে ... তবে যদি মাঝখানে বিরতি থাকে তবে তা সত্য হয় না, তাই আপনি সত্যই বিশ্বাস করতে পারবেন না আপনার লুপিং ...

লোকেরা GOTO পছন্দ না করার একই কারণ: নিশ্চিতভাবেই, এটি ভালভাবে ব্যবহার করা যেতে পারে তবে এটি গডওয়ফুল স্প্যাগেটি কোডের দিকেও নিয়ে যেতে পারে, যেখানে কোডটি বিভাগ থেকে বিভাগে এলোমেলোভাবে লাফ দেয়।

নিজের জন্য, যদি আমি একটি লুপ করতে চলেছিলাম যা একের অধিক শর্ত ভঙ্গ করে, আমি while(x){}তখন এক্স টগল করতে হবে যখন আমার ব্রেক করার দরকার পড়ে। চূড়ান্ত ফলাফলটি একই হবে এবং কোডের মাধ্যমে যে কেউ পড়ছেন তারা এক্সের মানকে পরিবর্তন করে এমন জিনিসগুলিকে আরও ঘনিষ্ঠভাবে দেখতে শিখবেন।


2
+1 খুব ভাল বলেছে, এবং +1 (যদি আমি আরও কিছু করতে পারতাম) এর জন্য while(notDone){ }
হতাশিত

5
মিখাইল: বিরতি সহকারে সমস্যাটি হ'ল লুপের চূড়ান্ত শর্তটি কখনই এক জায়গায় সহজভাবে বলা হয় না। এটি লুপের পরে পোস্ট-কন্ডিশনের পূর্বাভাস দেওয়া কঠিন করে তোলে। এই তুচ্ছ মামলায় (> = 1000) এটি কঠিন নয়। অনেক if-ਸਟੇਟਮੈਂਟস এবং এটি নীড়ের বিভিন্ন স্তরের যুক্ত করুন এটি লুপের পোস্ট-শর্ত নির্ধারণ করা খুব, খুব কঠিন হয়ে উঠতে পারে।
এস .লট

এস.লোট মাথায় পেরেকটি আঘাত করলেন। অভিব্যক্তি যা পুনরাবৃত্তি নিয়ন্ত্রণ করে তা পুনরুক্তি চালিয়ে যাওয়ার জন্য অবশ্যই প্রতিটি শর্ত পূরণ করা উচিত।
বিট-টুইডলার

6
প্রতিস্থাপন করা হচ্ছে break;সঙ্গে x=false;আপনার কোড আরো স্পষ্ট দেখা যায় না। সেই বিবৃতিটির জন্য আপনাকে এখনও বডিটি অনুসন্ধান করতে হবে। এবং এর ক্ষেত্রে x=false;আপনাকে এটি পরীক্ষা করতে হবে যে এটি x=true;আরও নীচে নেমে আসে না ।
সোজর্ড

14
লোকেরা যখন বলে "আমি এক্স দেখছি এবং আমি y অনুমান করি, তবে আপনি যদি z করেন তবে অনুমানটি" ​​আমার মনে হয় "তাই বোকা অনুমান করবেন না"। অনেক লোক while (x < 1000)এটিকে "সরীকরণ করবে যখন দেখি আমি ধরে নিয়েছি এটি 1000 বার চলবে " to আচ্ছা, প্রাথমিকভাবে শূন্য হলেও, এটি মিথ্যা হওয়ার অনেক কারণ রয়েছে x। উদাহরণস্বরূপ, কে বলেছে xযে লুপ চলাকালীন একবারে নিখুঁতভাবে বর্ধিত হয়েছে এবং অন্য কোনও উপায়ে কখনও পরিবর্তন হয়নি? এমনকি আপনার নিজের অনুমানের জন্যও, কারণ x >= 1000কোনও কিছু সেট মানে লুপটি শেষ হবে না - এটি শর্তটি পরীক্ষা করার আগে এটি আবার পরিসরে সেট হয়ে যেতে পারে।
স্টিভ 314

14

হ্যাঁ আপনি বিরতি বিবৃতি ছাড়াই প্রোগ্রামগুলি [আবার] লিখতে পারেন (বা লুপগুলির মাঝামাঝি থেকে ফিরে আসে) যা একই কাজ করে। তবে আপনাকে অতিরিক্ত ভেরিয়েবল এবং / অথবা কোড ডুপ্লিকেশন উভয়ই প্রবর্তন করতে হতে পারে যা সাধারণত প্রোগ্রামটিকে বোঝা শক্ত করে তোলে। পাস্কাল (প্রোগ্রামিং ভাষা) বিশেষত শিক্ষাগত প্রোগ্রামারদের জন্য খুব খারাপ ছিল reason আপনার বস মূলত আপনি প্যাসকের নিয়ন্ত্রণ কাঠামোয় প্রোগ্রাম করতে চান। লিনাস টরভাল্ডস যদি আপনার জুতোতে থাকে তবে তিনি সম্ভবত আপনার বসকে মাঝের আঙুলটি দেখালেন!

কোসারাজুর নিয়ন্ত্রণ কাঠামো সম্পর্কিত শ্রেণিবিন্যাস নামে একটি কম্পিউটার বিজ্ঞানের ফলাফল রয়েছে, যা ১৯ 197৩ সাল থেকে আসে এবং যা নথের (আরও) বিখ্যাত গবেষণাপত্রে ১৯ got৪ সাল থেকে গোটোসের বিষয়ে উল্লেখ করা হয়েছিল। (নোথের এই কাগজটি উপরে ডেভিড থর্নলি আগেই সুপারিশ করেছিলেন, উপায় দ্বারা ।) এস। রাও কোসারাজু 1973 সালে যা প্রমাণ করেছিলেন তা হ'ল অতিরিক্ত ভেরিয়েবল প্রবর্তন না করে এন-এর চেয়ে কম বিরতির গভীরতা সম্পন্ন সমস্ত প্রোগ্রামগুলিতে পুনরায় লিখন সম্ভব নয় যা বহু-স্তরের গভীরতার এন'র প্রোগ্রামগুলিতে রয়েছে । তবে আসুন আমরা এটি খাঁটি তাত্ত্বিক ফলাফল বলি। (মাত্র কয়েকটি অতিরিক্ত ভেরিয়েবল যুক্ত করুন?! আপনার বসকে খুশি করার জন্য আপনি এটি করতে পারেন ...)

সফটওয়্যার ইঞ্জিনিয়ারিং দৃষ্টিকোণ থেকে যা আরও গুরুত্বপূর্ণ তা হল সাম্প্রতিক, ১৯৯৯ সালের এরিক এস রবার্টসের লেখা লুপ এক্সিটস এবং স্ট্রাকচার্ড প্রোগ্রামিং শিরোনামের কাগজ : বিতর্কটি পুনরায় খোলা ( http://cs.stanford.edu/people/eroberts/papers/SIGCSE- 1995 / লুপএক্সিটস.পিডিএফ )। রবার্টস তার আগে অন্যদের দ্বারা পরিচালিত বেশ কয়েকটি গবেষণামূলক গবেষণার সংক্ষিপ্তসার করে। উদাহরণস্বরূপ, যখন CS101-ধরণের শিক্ষার্থীদের একটি গ্রুপকে অ্যারেতে অনুক্রমিক অনুসন্ধান প্রয়োগের জন্য কোনও ফাংশনের জন্য কোড লিখতে বলা হয়েছিল, তখন গবেষণার লেখক যেসব শিক্ষার্থী বিরতি / প্রত্যাবর্তন / গোটো থেকে বেরিয়ে যাওয়ার জন্য ব্যবহার করেছিলেন তাদের সম্পর্কে নিম্নলিখিতটি লিখেছিলেন উপাদানটি পাওয়া গেলে অনুক্রমিক অনুসন্ধানের লুপ:

আমি এখনও কোনও একক ব্যক্তির সন্ধান করতে পারি নি যিনি [এই শৈলী] ব্যবহার করে একটি প্রোগ্রাম চেষ্টা করেছিলেন যিনি একটি ভুল সমাধান তৈরি করেছেন।

রবার্টস আরও বলেছেন:

লুপ থেকে সুস্পষ্ট রিটার্ন ব্যবহার না করেই সমস্যার সমাধানের চেষ্টা করা শিক্ষার্থীরা খুব কম ভাল ফল করেছে: এই কৌশলটি চেষ্টা করে 42 শিক্ষার্থীর মধ্যে মাত্র সাতটি সঠিক সমাধান উত্পন্ন করতে সক্ষম হয়েছিল। এই চিত্রটি 20% এরও কম সাফল্যের হার উপস্থাপন করে।

হ্যাঁ, আপনি সিএস 101 শিক্ষার্থীদের তুলনায় আরও অভিজ্ঞ হতে পারেন, তবে ব্রেক স্টেটমেন্টটি ব্যবহার না করে (বা সমানভাবে লুপগুলির মাঝামাঝি থেকে ফিরবেন / গোটো) শেষ পর্যন্ত আপনি কোডটি লিখবেন যে নামমাত্র সুন্দরভাবে কাঠামোযুক্ত হওয়াতে অতিরিক্ত যুক্তির দিক দিয়ে যথেষ্ট লোমশ ভেরিয়েবল এবং কোড ডুপ্লিকেশন যা আপনার নিজের বসের কোডিং স্টাইলটি অনুসরণ করার চেষ্টা করার সময় কেউ নিজেকে সম্ভবত যুক্তিযুক্ত বাগগুলি রাখবে।

আমি এখানে আরও বলতে চাই যে রবার্টসের কাগজটি গড় প্রোগ্রামারটির থেকে অনেক বেশি অ্যাক্সেসযোগ্য, তাই নূথের চেয়ে ভাল আগে পড়া। এটি সংক্ষিপ্ততর বিষয়কেও সংক্ষিপ্ত করে তোলে। আপনি সম্ভবত এটি সিএস টাইপের পরিবর্তে ম্যানেজমেন্ট হলেও আপনার বসকে এটি সুপারিশ করতে পারেন।


2
যদিও কাঠামোগত প্রোগ্রামিংটি বহু বছর ধরে আমার দৃষ্টিভঙ্গি ছিল, শেষ কয়েকটিতে প্রথম সম্ভাব্য সুযোগে সম্পূর্ণরূপে সুস্পষ্ট এক্সিট ব্যবহার করা সরিয়ে নেওয়া হয়েছে। এটি দ্রুত কার্যকর করে তোলে এবং প্রায় যুক্তি ত্রুটিগুলি অপসারণ করে যা পরিণতিহীন লুপগুলির (ঝুলন্ত) ফলাফল হিসাবে ব্যবহৃত হয়।
ডকসালভেজার

9

আমি এই খারাপ অভ্যাসগুলির কোনওটিই বিবেচনা করি না, তবে একই লুপের মধ্যে এগুলি অত্যধিক ব্যবহারের ফলে লুপটিতে ব্যবহৃত যুক্তিটি পুনর্বিবেচনার নিশ্চয়তা দেওয়া উচিত। এগুলি অল্প পরিমাণে ব্যবহার করুন।


:) হ্যাঁ, আমি যে উদাহরণ সরবরাহ করেছি তা ধারণামূলক ছিল
মিখাইল

7

আপনি যে উদাহরণটি দিয়েছেন তার বিরতি বা দরকার নেই:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

আপনার উদাহরণের 4 টি লাইনের সাথে আমার 'সমস্যা' হ'ল এগুলি সমস্ত একই স্তরে রয়েছে তবে তারা বিভিন্ন জিনিস করে: কিছু বিরতি, কিছু চালিয়ে যায় ... আপনাকে প্রতিটি লাইন পড়তে হবে।

আমার নেস্টেড পদ্ধতিতে, আপনি যত গভীর হবেন ততই কোড আরও 'দরকারী' হয়ে উঠবে।

তবে, গভীর অভ্যন্তরে যদি আপনি লুপটি থামানোর কোনও কারণ খুঁজে পান (প্রাথমিক শর্ত ব্যতীত), বিরতি বা প্রত্যাবর্তনের এটির ব্যবহার থাকতে পারে। আমি এটিকে পছন্দ করব যে একটি অতিরিক্ত পতাকা ব্যবহারের চেয়ে শীর্ষ স্তরের অবস্থায় পরীক্ষা করতে হবে। বিরতি / প্রত্যাবর্তন আরও সরাসরি; এটি আরও একটি ভেরিয়েবল সেট করার চেয়ে অভিপ্রায়টিকে আরও ভালভাবে জানিয়েছে।


+1 তবে আসলে আপনার <তুলনাগুলি <=
ওপিএস

3
বেশিরভাগ ক্ষেত্রে, যদি কেউ এত গভীর হয় যে প্রবাহ নিয়ন্ত্রণ পরিচালনার জন্য ব্রেক / রিটার্ন ব্যবহার করা প্রয়োজন তবে কারও কাজ / পদ্ধতি খুব জটিল।
বিট-টুইডলার

6

"খারাপ লাগা" আপনি কীভাবে এটি ব্যবহার করেন তার উপর নির্ভরশীল। আমি সাধারণত লুপিং কনস্ট্রাক্টসে বিরতি কেবল তখনই ব্যবহার করি যখন এটি আমাকে এমন চক্রগুলি বাঁচাতে পারে যা অ্যালগরিদমের রিফ্যাক্টরিংয়ের মাধ্যমে সংরক্ষণ করা যায় না। উদাহরণস্বরূপ, একটি নির্দিষ্ট সম্পত্তিতে মান হিসাবে একটি আইটেম সন্ধানের জন্য সংগ্রহের মাধ্যমে সাইকেল চালানো। আপনার যদি যা জানার দরকার তা হ'ল আইটেমগুলির মধ্যে একটিতে এই সম্পত্তিটি সত্য হয়ে যায়, একবার আপনি ফলাফলটি অর্জন করলে, ব্রেকটি যথাযথভাবে শেষ করা ভাল।

যদি বিরতি ব্যবহার করে কোডটি পড়ার পক্ষে বিশেষভাবে সহজ হয় না, প্রসেসিংয়ে চক্রটি চালানো বা সংরক্ষণ করতে ছোট করা একটি উল্লেখযোগ্য উপায়ে করা হয় তবে তাদের ব্যবহার না করাই ভাল। আমার অনুসরণকারী যে কেউ খুব সহজেই আমার কোডটি দেখতে পারে এবং কী চলছে তা নির্ধারণ করতে পারে তা নিশ্চিত করার জন্য আমি "সর্বনিম্ন সাধারণ ডিনোমিনেটর" এর কোডের দিকে ঝুঁকছি ((আমি এই ক্ষেত্রে সর্বদা সফল নই)। বিরতি এগুলি হ্রাস করে কারণ তারা বিজোড় প্রবেশ / প্রস্থান পয়েন্টগুলি চালু করে। অপব্যবহার করা হয়েছে তারা অনেকটা "অসন্তুষ্ট" বিবৃতি ছাড়ার মতো আচরণ করতে পারে।


আমি উভয় দফার সাথে একমত! আপনার দ্বিতীয় বিষয় হিসাবে - আমি আমার মূল পোস্টটি অনুসরণ করা আরও সহজ বলে মনে করি কারণ এটি ইংরেজের মতো পড়ে। যদি বিবৃতিটি যদি আপনার 1 এর শর্তের সংমিশ্রণ থাকে তবে সত্যটি কার্যকর করতে হলে তার কী হবে তা নির্ধারণ করা প্রায় সিদ্ধান্ত গ্রহণকারী।
মিখাইল

@ মিখাইল: আপনার প্রদত্ত নমুনাগুলি সুনির্দিষ্ট বাস্তবতার জন্য কিছুটা পরার্থপর। আমি এটি দেখতে হিসাবে, এই নমুনাগুলি পরিষ্কার, সংক্ষিপ্ত, পড়া সহজ। বেশিরভাগ লুপগুলি এর মতো নয়। বেশিরভাগ লুপের মধ্যে এমন কিছু যুক্তি রয়েছে যা তারা সম্পাদন করছে এবং সম্ভবত আরও জটিল শর্ত রয়েছে। এটি এই ক্ষেত্রে বিরতি / চালিয়ে যাওয়া সর্বোত্তম ব্যবহার নাও হতে পারে কারণ এটি পড়ার সময় যুক্তিটিকে গ্লানি করে তোলে।
জোয়েল ইথারটন

4

একদম ঠিক নয় ... হ্যাঁ এর ব্যবহার gotoখারাপ কারণ এটি আপনার প্রোগ্রামের কাঠামোর অবনতি ঘটায় এবং নিয়ন্ত্রণ প্রবাহটি বোঝাও খুব কঠিন।

তবে এই দিনগুলির মতো breakএবং continueএর মতো বিবৃতিগুলির ব্যবহার একেবারে প্রয়োজনীয় এবং খারাপ প্রোগ্রামিং অনুশীলনটিকে মোটেই বিবেচনা করা হয় না।

এবং এছাড়াও যে কঠিন না ব্যবহারে নিয়ন্ত্রণ প্রবাহ বুঝতে breakএবং continue। মত নির্মান ইন বিবৃতি অত্যাবশ্যক।switchbreak


2
1981 সালে আমি প্রথম C শিখার পর থেকে আমি "চালিয়ে" ব্যবহার করি নি It এটি একটি অপ্রয়োজনীয় ভাষার বৈশিষ্ট্য, কারণ চালিয়ে যাওয়া বিবৃতিটি বাইপাস করা কোডটি শর্তাধীন নিয়ন্ত্রণ বিবৃতি দিয়ে মোড়ানো যেতে পারে।
বিট-টুইডলার

12
আমি সেই ক্ষেত্রে চালিয়ে যাওয়া ব্যবহার পছন্দ করি কারণ এটি নিশ্চিত করে যে আমার কোডটি তীর কোড না হয়ে। আমি গোটো টাইপের স্টেটমেন্টের চেয়ে তীর কোডকে বেশি ঘৃণা করি। আমি এটিকেও এই হিসাবে পড়েছি, "যদি এই বিবৃতিটি সত্য হয় তবে এই লুপের বাকি অংশটি এড়িয়ে যান এবং পরবর্তী পুনরাবৃত্তির সাথে চালিয়ে যান।" লুপের জন্য যখন এটি একেবারে শুরুতে হয় তখন খুব দরকারী (যখন লুপগুলিতে কম দরকারী)।
jsternberg

জেস্টার্নবার্গ জয়ের জন্য! :-)
12-28 এ নোটলিস্ট

3

অপরিহার্য ধারণাটি আপনার প্রোগ্রামটি শব্দার্থত বিশ্লেষণ করতে সক্ষম হওয়া থেকে আসে। আপনার যদি একক প্রবেশ এবং একক প্রস্থান থাকে, সম্ভাব্য রাজ্যগুলি বোঝাতে যে গণিতের প্রয়োজন ছিল তা যদি আপনার কাঁটাচামচ পথ পরিচালনা করতে হয় তার চেয়ে যথেষ্ট সহজ।

অংশ হিসাবে, এই অসুবিধাটি আপনার কোড সম্পর্কে ধারণাগতভাবে যুক্ত করতে সক্ষম হওয়ার প্রতিফলন ঘটায়।

সত্যি বলতে কী, আপনার দ্বিতীয় কোডটি সুস্পষ্ট নয়। এটা কি করছে? 'চালিয়ে' চালিয়ে যায়, বা লুপটি 'পরবর্তী' করে? আমার কোন ধারণা নাই. কমপক্ষে আপনার প্রথম উদাহরণটি পরিষ্কার।


আমি যখন এমন একটি প্রকল্পে কাজ করি যে ম্যানেজার তাদের ব্যবহারের বাধ্যবাধকতা রাখে, তখন এর ব্যবহারের কথা মনে রাখার জন্য আমাকে একটি ফ্লোচার্ট ব্যবহার করতে হয়েছিল, এবং বেশ কয়েকটি প্রস্থান পথগুলি, আরও বিভ্রান্তিকর কোড তৈরি করেছিল ...
ইউএমএলকাট

আপনার "স্পষ্টতই" মন্তব্যটি সিনট্যাকটিক - "পরবর্তী" একটি পার্ল জিনিস; সাধারণ ভাষাগুলি "এই লুপটি এড়িয়ে যান" এর অর্থ "চালিয়ে যান" ব্যবহার করেন
মিখাইল

@ মিক, সম্ভবত "এই পুনরাবৃত্তিটি এড়িয়ে যান" আরও ভাল বিবরণ হবে। ইতিমধ্যে, ড। আইএম পেডেন্টিক
পিট উইলসন

@ মিখাইল: অবশ্যই কিন্তু যখন কেউ প্রচুর ভাষায় কাজ করে, তখন ভাষাগুলির মধ্যে সিনট্যাক্সটি সাধারণ না হলে এটি ত্রুটি ঘটতে পারে।
পল নাথান

তবে গণিতে প্রোগ্রামিং হচ্ছে না । গণিতের চেয়ে কোডটি আরও প্রকাশিত। আমি পেতে একক এন্ট্রি / একক- প্রস্থান ফ্লোচার্ট সুন্দর কিন্তু কি খরচে বানাতে পারে যে (অর্থাৎ। যেখানে বিরতি / রিটার্ন কোড ভাল কার্য সম্পাদন করে তুলতে পারে)?
ইভান প্লেইস

3

আমি আপনার দ্বিতীয় কোড স্নিপেট এর সাথে প্রতিস্থাপন করব

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

নিষ্ঠুরতার কোনও কারণে নয় - আমি আসলে মনে করি এটি পড়া সহজ এবং কারও পক্ষে কী চলছে তা বোঝা। সাধারণত আপনার লুপগুলির শর্তাবলী পুরো শরীর জুড়ে লিটারের লুপের মধ্যে সম্পূর্ণরূপে থাকা উচিত। তবে এমন কিছু পরিস্থিতি রয়েছে যেখানে পাঠযোগ্যতা breakcontinueসহায়তা করতে পারে। আমি যোগ করতে পারে তার breakচেয়েও বেশি continue: ডি


আমি যেহেতু একমত নই, "আমি আসলে এটি পড়তে সহজ মনে করি" এটি উপরের কোডের মতো ঠিক একই উদ্দেশ্যটি সম্পাদন করে। আমি এখনও অবধি শর্ট সার্কিট অপারেটর হিসাবে 'ব্রেক' সম্পর্কে ভাবি নি তবে এটি সঠিক ধারণা দেয়। যেমন, "সাধারণত আপনার লুপগুলির জন্য শর্তগুলি অবশ্যই সেই লুপের মধ্যে থাকা উচিত", আপনি যখন লঞ্চের সংজ্ঞায় শর্তাধীন যুক্তি সন্নিবেশ করার সত্যিই উপায় নেই, আপনি যখন একটি ফোরচ লুপ প্রক্রিয়া করছেন তখন আপনি কী করবেন?
ইভান প্লেইস

@ ইভান শর্তটি কোনও foreachলুপের জন্য প্রযোজ্য নয় কারণ এটি কেবলমাত্র সংগ্রহে প্রতিটি আইটেম পুনরাবৃত্তি করবে। একটি forলুপ একই হয় যে এটিতে শর্তসাপেক্ষ শেষ বিন্দু হওয়া উচিত নয়। আপনার যদি শর্তসাপেক্ষে শেষ পয়েন্ট দরকার হয় তবে আপনাকে একটি whileলুপ ব্যবহার করতে হবে ।
এল রোনোকো

1
@ ইভান আমি আপনার পয়েন্টটি দেখতে পাচ্ছি - যদিও 'যদি আপনার আগেভাগের লুপটি ভেঙে ফেলার দরকার হয় তবে?' - ঠিক আছে, breakলুপ থেকে আমার মতে একটি মাত্র সর্বোচ্চ হওয়া উচিত ।
এল রোনোকো

2

আমি আপনার বসের সাথে একমত নই। সঠিক স্থান আছে breakএবং continueব্যবহৃত হবে। প্রকৃতপক্ষে যে কারণেই আধুনিক প্রোগ্রামিং ভাষার ক্ষেত্রে ব্যতিক্রম ও ব্যতিক্রম হ্যান্ডলিংয়ের প্রচলন হয়েছিল তা হ'ল আপনি কেবলমাত্র ব্যবহার করে প্রতিটি সমস্যা সমাধান করতে পারবেন না structured techniques

একদিকে নোটে আমি এখানে কোনও ধর্মীয় আলোচনা শুরু করতে চাই না তবে আপনি নিজের কোডটিকে আরও বেশি পাঠযোগ্য হতে পুনর্গঠন করতে পারেন:

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

অন্য দিকে নোট

আমি ব্যক্তিগতভাবে ( flag == true )শর্তসাপেক্ষে ব্যবহারটি অপছন্দ করি কারণ ভেরিয়েবলটি ইতিমধ্যে যদি একটি বুলিয়ান হয় তবে আপনি বুলিয়ানটির মানটির উত্তরটি যখন চান তখন একটি অতিরিক্ত তুলনা প্রবর্তন করছেন - অবশ্যই আপনি যদি নিশ্চিত হন যে আপনার সংকলকটি যে অতিরিক্ত তুলনা দূরে অপ্টিমাইজ।


আমি বছরের পর বছর ধরে এই প্রশ্নটি আটকে রেখেছি। আপনার উপায় ('যদি (পতাকা) {...}') অনেক বেশি সংবেদনশীল এবং সম্ভবত এটি আরও 'পেশাদার' বা 'বিশেষজ্ঞ' দেখাচ্ছে looks তবে, আপনি জানেন, এর অর্থ প্রায়শই বোঝা যায় যে কোনও পাঠক / রক্ষণাবেক্ষণকারীকে নির্মাণের অর্থ কী তা মনে করার জন্য সংক্ষেপে নিজেকে বাধা দিতে হবে; এবং পরীক্ষার ধারণাটি নিশ্চিত হওয়া। বর্তমানে, আমি 'যদি (পতাকা == সত্য) {...}' ব্যবহার করছি কেবল এটি ভাল ডকুমেন্টেশন বলে মনে হচ্ছে। পরের মাসে? কুইয়ান সাবে?
পিট উইলসন

2
@Pete - শব্দটি নয় বাহুল্যবর্জিত কিন্তু মার্জিত । আপনি যা চান, তা আপনি আটকাতে পারেন তবে আপনি যদি উদ্বিগ্ন থাকেন যে পাঠক / রক্ষণাবেক্ষণকারী কী booleanতা বা টার্স / মার্জিত পরিভাষার অর্থ কী তা বুঝতে না পারে তবে আপনি আরও কিছু বুদ্ধিমান রক্ষণাবেক্ষণকারীকে ভাড়া নিতে পারেন ;-)
জেকে হ্যানসেল

@ পিট, আমি উত্পন্ন কোড সম্পর্কে আমার বিবৃতি দ্বারা দাঁড়িয়ে আছি। আপনি অভিব্যক্তিটির বুলিয়ান মানের মূল্যায়ন করার আগে একটি ধ্রুবককে একটি ধ্রুবক মানের সাথে তুলনা করে আরও একটি তুলনা করছেন। এটিকে যত শক্তিশালী করা উচিত তার চেয়ে কেন শক্ত করে তুলুন, পতাকা ভেরিয়েবলের ইতিমধ্যে আপনার পছন্দের মানটি রয়েছে!
জেক হ্যানসেল

+1 ভাল কাজ। অবশ্যই পূর্বের উদাহরণের তুলনায় অনেক বেশি মার্জিত।
ইভান প্লেইস

2

আমি আপনার বসের সাথে একমত। এগুলি খারাপ কারণ তারা উচ্চ চক্রযুক্ত জটিলতা সহ পদ্ধতি উত্পাদন করে। এই জাতীয় পদ্ধতিগুলি পড়া কঠিন এবং পরীক্ষা করা কঠিন। ভাগ্যক্রমে একটি সহজ সমাধান আছে। লুপের বডিটি একটি পৃথক পদ্ধতিতে সরান, যেখানে "চালিয়ে যান" "রিটার্ন" হয়ে যায়। "রিটার্ন" ভাল কারণ "রিটার্ন" শেষ হওয়ার পরে - স্থানীয় রাষ্ট্র সম্পর্কে কোনও উদ্বেগ নেই।

"বিরতি" এর জন্য লুপ নিজেই আলাদা পদ্ধতিতে এক্সট্রাক্ট করুন, "ব্রেক" এর পরিবর্তে "রিটার্ন" করুন।

যদি নিষ্কাশিত পদ্ধতিগুলির জন্য প্রচুর পরিমাণে যুক্তিগুলির প্রয়োজন হয়, তবে এটি কোনও শ্রেণি নিষ্কাশনের ইঙ্গিত দেয় - হয় সেগুলি প্রসঙ্গ বস্তুতে সংগ্রহ করুন।


0

আমি মনে করি এটি একমাত্র সমস্যা যখন একাধিক লুপের অভ্যন্তরে গভীরভাবে বাস করে। আপনি কোন লুপটি ভাঙ্গছেন তা জানা শক্ত। এটি চালিয়ে যাওয়াও অনুসরণ করা কঠিন হতে পারে তবে আমি মনে করি আসল ব্যথা বিরতি থেকেই আসে - যুক্তি অনুসরণ করা কঠিন হতে পারে।


2
প্রকৃতপক্ষে, আপনি সঠিকভাবে ইনডেন্ট করেছেন কিনা, সহজেই দেখতে পাওয়া সহজ those এই বিবৃতিগুলির শব্দার্থকে অভ্যন্তরীণ করে তোলা হয়েছে এবং খুব নিদ্রাহীন নয়।

@ ডেলান - এটি অনেক অনুমান;)
ডেভিডাসকিন্স

2
হ্যাঁ, বিশেষত শেষ
মাইকেল কে

ঠিক আছে, যাইহোক যাইহোক গুরুতর প্রোগ্রামিংয়ের জন্য # 1 প্রয়োজন, প্রোগ্রামার নামক প্রত্যেকের কাছ থেকে # 2 আশা করা উচিত এবং # 3 সাধারণভাবে বেশ কার্যকর;)

কিছু ভাষা (কেবলমাত্র স্ক্রিপ্টিং যা আমি জানি) সমর্থন করে break 2; অন্যদের জন্য, আমি অনুমান করি যে অস্থায়ী বুল পতাকা ব্যবহার করা হয়েছে
মিখাইল

0

যতক্ষণ না নিচের উদাহরণে এগুলি ছদ্মবেশী গোটো হিসাবে ব্যবহার করা হয় না:

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

আমি তাদের সাথে ভাল আছি। (উদাহরণস্বরূপ উত্পাদন কোড, মেহ দেখা যায়)


আপনি কি এই জাতীয় ক্ষেত্রে ফাংশন তৈরির জন্য সুপারিশ করবেন?
মিখাইল

হ্যাঁ এবং যদি সম্ভব না হয় তবে একটি সরল গোটো। যখন আমি কোন করণীয় দেখি, তখন আমি পুনরাবৃত্তি মনে করি, লাফের অনুকরণের প্রসঙ্গ নয়।
সুপারব্লুপ

ওহ আমি সম্মতি জানাই, আপনি কেবল এটি কীভাবে করবেন তা আমি জিজ্ঞাসা করছিলাম: কম্পিউটার বিজ্ঞানীরা বারবার এটি করেন
মিখাইল

0

আমি এই স্টাইলগুলির কোনও পছন্দ করি না। আমি যা পছন্দ করব তা এখানে:

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

আমি returnকোনও ফাংশন বাতিল করতে সত্যিই পছন্দ করি না । এটি একটি অপব্যবহার মত অনুভূত return

breakএছাড়াও ব্যবহার করা সবসময় পড়ার জন্য পরিষ্কার নয়।

আরও ভাল হতে পারে:

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

কম বাসা বাঁধে এবং জটিল অবস্থাগুলি ভেরিয়েবলগুলিতে রিফ্যাক্টর হয় (একটি বাস্তব প্রোগ্রামে আপনার আরও ভাল নাম থাকতে হবে, অবশ্যই ...)

(উপরের সমস্ত কোড সিউডো কোড)


11
আমি কি উপরে উপরে টাইপ করেছি তার উপরে বাসা বাঁধার মাত্রা 3 টি পছন্দ করবেন?
মিখাইল

@ মিখাইল: হ্যাঁ, বা আমি শর্তের ফলাফলটি একটি ভেরিয়েবলকে অর্পণ করব। আমি এর যুক্তি breakএবং এর চেয়ে বোঝা আরও সহজ মনে করি continue। একটি লুপটি অস্বাভাবিকভাবে শেষ করা কেবল অদ্ভুত মনে হয় এবং আমি এটি পছন্দ করি না।
হতাশিত

1
হাস্যকরভাবে, আপনি আমার শর্তগুলি ভুলভাবে লিখেছেন। continueএর অর্থ কার্যকারিতা এড়িয়ে যাওয়া পরবর্তী লুপে যান; "ফাঁসি দিয়ে চালিয়ে যান" না
মিখাইল

@ মিখাইল: আহ। আমি এটি প্রায়শই ব্যবহার করি না এবং আমি যখন এটি পড়ি, আমি অর্থ দ্বারা বিভ্রান্ত হয়ে যাই। আমি আর পছন্দ করি না কারণ। : পি আমাকে আপডেট করার জন্য এক মিনিট সময় দিন ...
হতাশাগ্রস্থ

7
খুব বেশি বাসা বাঁধার পাঠযোগ্যতা নষ্ট করে। এবং কখনও কখনও বিরতি এড়ানো / চালিয়ে যাওয়া আপনার শর্তযুক্ত পরীক্ষাগুলিতে আপনার যুক্তিটি উল্টানোর প্রয়োজনীয়তার পরিচয় দেয়, যা আপনার কোডটি কী করছে তা ভুল ব্যাখ্যা করতে পারে - I just sayin '
জেক হ্যানসেল

0

না এটি সমস্যা সমাধানের একটি উপায়, এবং এটি সমাধানের অন্যান্য উপায়ও রয়েছে।

মূলধারার অনেকগুলি ভাষা (জাভা,। নেট (সি # + ভিবি), পিএইচপি, নিজের লেখা) লুপগুলি এড়াতে "বিরতি" এবং "চালিয়ে যান" ব্যবহার করে। তারা উভয়ই "কাঠামোগত গোটো (গুলি)" বাক্য।

তাদের ছাড়া:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

তাদের সাথে:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

মনে রাখবেন যে, "বিরতি" এবং "চালিয়ে যান" কোডটি ছোট হয় এবং সাধারণত "বাক্যগুলিকে" জন্য "বা" পূর্বাভাস "বাক্যে পরিণত হয় turns

উভয় ক্ষেত্রে কোডিং শৈলীর বিষয়। আমি এগুলি ব্যবহার না করা পছন্দ করি , কারণ ভার্বোজ শৈলী আমাকে কোডের আরও নিয়ন্ত্রণ রাখতে দেয়।

আমি আসলে কিছু প্রকল্পে কাজ করি, যেখানে এই বাক্যগুলি ব্যবহার করা বাধ্যতামূলক ছিল।

কিছু বিকাশকারী ভাবতে পারে তারা নেসারিলি নয়, তবে অনুমানমূলক, যদি আমাদের সেগুলি সরিয়ে ফেলতে হয় তবে আমাদের "যখন" এবং "করার সময়" ("ততক্ষণ পুনরাবৃত্তি করুন", আপনি প্যাস্কাল ছেলেরা )ও সরিয়ে ফেলতে হবে ;-)

উপসংহার, এমনকি যদি আমি সেগুলি ব্যবহার না করা পছন্দ করি তবে আমি এটি একটি বিকল্প হিসাবে মনে করি, খারাপ প্রোগ্রামিং অনুশীলন নয়।


বাছাইয়ের জন্য দুঃখিত, তবে আপনার দ্বিতীয় উদাহরণটি কীটি পাওয়া যায় না এর জন্য আউটপুটটি অনুপস্থিত ((অবশ্যই এটি দেখতে এটিকে আরও খাটো মনে হয়)।
হতাশ

2
প্রথম উদাহরণটি কেবলমাত্র যদি তালিকার শেষটি থাকে তবে কাজ করে তা উল্লেখ করার দরকার নেই।
মিখাইল

নিখুঁতভাবে নিখুঁত আমি সেই পদ্ধতিটি কেন অধিকতর তা বোঝানোর জন্য
পার্পাসরুমটি রেখেছি

তবে, আপনার বিভিন্ন শব্দার্থবিজ্ঞানের সাথে দুটি রুটিন রয়েছে; সুতরাং, তারা যুক্তিযুক্তভাবে সমতুল্য নয়।
বিট-টুইডলার

2
আপনার দ্বিতীয় উদাহরণে দুটি বাগ রয়েছে, একটি সিনট্যাকটিক এবং একটি যৌক্তিক। 1. এটি সংকলন করবে না কারণ আয়রেটরটি লুপের স্কোপের বাইরে ঘোষণা করা হয়নি (সুতরাং স্ট্রিং আউটপুটটিতে উপলব্ধ নয়)। ২. এমনকি যদি পুনরুক্তিটি লুপের বাইরে ঘোষণা করা হয়, কীটি সংগ্রহের মধ্যে খুঁজে পাওয়া যায় না, তবে স্ট্রিং আউটপুট তালিকার শেষ আইটেমের কীটি মুদ্রণ করবে।
ইভান প্লেইস

0

আমি বিরোধী continueএবং breakনীতিগতভাবেই নই , তবে আমি মনে করি তারা খুব নিম্ন-স্তরের কাঠামো যা প্রায়শই আরও ভাল কিছু দ্বারা প্রতিস্থাপন করা যায়।

আমি এখানে উদাহরণ হিসাবে সি # ব্যবহার করছি, সংগ্রহের মাধ্যমে পুনরাবৃত্তি করতে চাওয়ার ক্ষেত্রে বিবেচনা করুন, তবে আমরা কেবল এমন উপাদানগুলি চাই যা কিছু পূর্বাভাসকে পূর্ণ করে দেয় এবং আমরা সর্বোচ্চ 100 টি পুনরাবৃত্তির চেয়ে বেশি কিছু করতে চাই না।

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

এটি দেখতে সাধারণভাবে পরিষ্কার। এটি বোঝা খুব কঠিন নয়। আমি মনে করি যদিও এটি আরও ঘোষিত হওয়ার থেকে অনেক কিছু অর্জন করতে পারে। এটি নিম্নলিখিত সাথে তুলনা করুন:

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

সম্ভবত কোথায় এবং গ্রহণ কলগুলিও এই পদ্ধতিতে হওয়া উচিত নয়। সংগ্রহটি এই পদ্ধতিতে পাস করার আগে এই ফিল্টারিংটি করা উচিত। যাইহোক, নিম্ন-স্তরের স্টাফগুলি থেকে সরে গিয়ে এবং প্রকৃত ব্যবসায়িক যুক্তিতে আরও মনোনিবেশ করার মাধ্যমে এটি আরও স্পষ্ট হয়ে উঠেছে যে আমরা আসলে কী আগ্রহী। উপর.

নিম্নের স্তরের স্টাফগুলি কোডের কিছু অংশে এখনও বিদ্যমান থাকবে তবে আমরা এটি যথাসম্ভব আড়াল করতে চাই, কারণ এটি মানসিক শক্তি গ্রহণ করে যা আমরা পরিবর্তে ব্যবসায়ের সমস্যাগুলি নিয়ে যুক্তিযুক্ত হতে পারি।


-1

কোড কমপ্লিটের ব্যবহার gotoএবং রুটিন বা লুপ থেকে একাধিক রিটার্ন সম্পর্কে একটি দুর্দান্ত বিভাগ রয়েছে ।

সাধারণভাবে এটি খারাপ অভ্যাস নয়। breakঅথবা continueঠিক কি ঘটবে তা বলুন। এবং আমি এটির সাথে একমত

স্টিভ ম্যাককনেল (কোড কমপ্লিটের লেখক) বিভিন্ন gotoবিবৃতি ব্যবহারের সুবিধা দেখানোর জন্য প্রায় একই উদাহরণ ব্যবহার করেন ।

তবে অতিরিক্ত ব্যবহার breakবা continueজটিল এবং অনিবার্য সফ্টওয়্যার হতে পারে।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.