লোকেরা কেন পদ্ধতিগুলিতে #region ট্যাগের তীব্র বিরোধিতা করছেন?

27

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

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

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

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

থটস?

c# coding-style

— jjoelson
সূত্র

4

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

— রবার্ট হার্ভে

4

@ রবার্টহারভে, কোনও ক্লাসে এগুলি ব্যবহার করা কোনও পদ্ধতির ভিতরে ব্যবহারের চেয়ে আলাদা।

— ক্যাফগীক

18

@ চাদ: আহ, সেদিকে খেয়াল নেই। এগুলি কোনও পদ্ধতিতে ব্যবহার করা কিছুটা চরম বলে মনে হয়। যদি কোনও পদ্ধতি এত দীর্ঘ হয় যে এটির জন্য # অঞ্চল প্রয়োজন, আমি এটিকে পৃথক পদ্ধতিতে রিফ্যাক্টর করি।

— রবার্ট হার্ভে

8

আসলেই কোনও উত্তর নয়, তবে আমি কেবল সমস্ত ট্যাগকে ঘৃণা #regionকরি না, ভিজুয়াল স্টুডিওতে কোড ফোল্ডিং পুরোপুরি বন্ধ করে দিই। আমার কাছ থেকে লুকানোর চেষ্টা করা কোডটি আমি পছন্দ করি না।

— ড্যানিয়েল প্রাইডেন

2

"তদ্ব্যতীত, এই স্তরগুলির প্রতিটিই কেবল এই পদ্ধতির গণনার ক্ষেত্রে প্রাসঙ্গিক এবং তাই এগুলি নতুন পদ্ধতিতে বের করা আমাদের কোনও কোড পুনরায় ব্যবহারের সুযোগ পায় না"। ওটো, আমি দেখতে পেলাম যে আমি যদি কোনও ফাংশনটি 3-এ বিভক্ত করি তবে আমি প্রায়শই পরে দেখতে পাই যে পৃথক অংশগুলি <i> </i> পরে দরকারী, যেমন। কিছু ইনপুট ডেটা যদি কেবল একটি পর্যায়ে পরিবর্তন হয় তবে আপনি তা পৃথকীকরণ ইত্যাদিতে পরীক্ষা করতে পারেন

— জ্যাক ভি।

65

আপনার কোডটি ব্যবহারের যোগ্য হওয়ার জন্য, পুনরায় ব্যবহারযোগ্য না হওয়ার জন্য আপনাকে যা দেখানো উচিত সেগুলি। কোনও বান্দর ব্যবহারের যোগ্য কোডটিকে পুনরায় ব্যবহারযোগ্য কোডে রূপান্তর করতে পারে, যদি এখানে কোনও রূপান্তর হয় তবে।

এটিকে বিনয়ের সাথে বলতে গেলে "আমার কেবল এটি দরকার" যুক্তিটি দরিদ্র। আপনি যে কৌশলটি বর্ণনা করছেন তা প্রায়শই শিরোনামের কৌশল হিসাবে অভিহিত হয় এবং এটি সাধারণত নষ্ট হয়।

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

এছাড়াও প্রাসঙ্গিক: কোড ভাঁজ সম্পর্কে জেফ অ্যাটউডসের চিন্তাভাবনা

— back2dos
সূত্র

9

1. বেশিরভাগ প্রোগ্রামাররা সমস্ত ব্যক্তিগত পদ্ধতি পরীক্ষা করে না। ২. একটি পদ্ধতির নাম সেই পদ্ধতি সম্পর্কে জানার জন্য প্রতিটি জিনিস বোঝাতে পারে না; কি ব্যতিক্রম নিক্ষেপ করা যেতে পারে? নাল কি একটি বৈধ ইনপুট? কখনও কখনও আপনার কোডটি আরও বোধগম্য করতে অ-সিনট্যাকটিক কনস্ট্রাক্টস ব্যবহার করা ঠিক। অনেক ভাষায়, ফাইলগুলি একটি অ-সিনট্যাকটিক উপাদানটির একটি উদাহরণ যা কোড সংগঠিত করার উপায় হিসাবে মোটামুটিভাবে গ্রহণযোগ্য accepted ৩. কোনও কারণের অভ্যন্তরীণ কর্মে ডাইভিংয়ের জন্য আইডিইতে বিভিন্ন কারণে সর্বোত্তম চেষ্টা করা হয়; অঞ্চলগুলি যেখানে আপনার ভিসিএস বা মেল ক্লায়েন্টে আপনাকে কাটতে পারে তার চেয়ে বিরল।

— জাজোয়েলসন

3

৪. তবে আপনি আপনার ক্লাসের কিছু অংশে কিছু গুরুতর জটিলতা রফতানি করেছেন। এটা কি মূল্য? এছাড়াও, অঞ্চলগুলিকে কোনও পদ্ধতির কল হিসাবে সহজেই আশেপাশে সরানো যেতে পারে। ৫. এখন আপনি আপনার ক্লাসে নামমাত্র স্থান দূষিত করার বিষয়ে কথা বলছেন যা কেবলমাত্র এক জায়গায় ব্যবহার করা হচ্ছে single ক্লাস এবং পদ্ধতিগুলি কেন আপনি গ্রহণ করবেন এমন এনক্যাপসুলেশনগুলির একমাত্র একক? আপনি পরে সর্বদা নতুন ক্লাস তৈরি করতে পারেন যখন (বা যদি) এটি আলাদা করার প্রয়োজন হয়।

— jjoelson

7

@ জাজোয়েলসন: ১. তাহলে কী? ২. ঠিক আমার বক্তব্য: একা সিনট্যাক্স যথেষ্ট না হলে (এবং শুধুমাত্র যদি) অ-সিনট্যাকটিক কনস্ট্রাক্ট ব্যবহার করা ঠিক হবে ok ৩. "বিরল?" - আমি মনে করি এটি দেখানোর জন্য আপনার কাছে নম্বর আছে। আমি আপনাকে নিশ্চিত করে বলতে পারি যে টরটোইজএসভিএন দিয়ে বান্ডিলযুক্ত ডিফ (বা দোষ বা যাই হোক না কেন) সরঞ্জামটির ভাঁজ নেই। ৪. এটি যেভাবে আমি তৈরি পয়েন্টের সাথে সম্পর্কিত। ৫. এজন্য বেশিরভাগ আধুনিক ভাষায় নেস্টেবল নেমস্পেস রয়েছে। আপনি আপনার কোড গঠনের জন্য উপলব্ধ ভাষা উপাদানগুলির একটি বিস্তৃত প্যালেট ব্যবহার না করে ASCII আর্টের অবলম্বন করছেন।

— back2dos

4

@ জাজোয়েলসন: ১. এটি আপনার মতামত এবং এই প্রশ্নের ক্ষেত্রের বাইরে। 2. আমার যুক্তির প্রসারিত করে নেস্টেড ফাংশনগুলি অঞ্চলগুলির চেয়ে ভাল are ৩. কারণ সমস্যাটি ট্র্যাক করার জন্য আমার মাঝে মাঝে অনেকগুলি সংশোধনগুলি ব্রাউজ করতে হবে। যে কোনও উপায়ে, উত্স কোড আইডিই নয়, মানুষের জন্য লেখা। ৪. একটির জন্য যুক্তিটি আমার বক্তব্যের সাথে সম্পর্কিত নয়, দ্বিতীয়ত এটি আবার আপনার মতামত, তৃতীয়ত এটি এই প্রশ্নের ক্ষেত্রের বাইরে। ৫. সি # এর নেস্টিং ফাংশন ব্যতীত স্ট্রাকচারিং কোডের অন্যান্য উপায় রয়েছে। আপনার উচিত হয় সেগুলি, বা এমন একটি ভাষা ব্যবহার করা উচিত যা বাসা বাঁধতে পারে।

— back2dos

13

আপনারা ছেলেরা এটিকে আড্ডায় নেবেন যদি আপনি এখনও বিতর্ক করতে চান ... তবে ওপিকে বলার মতো আমার কাছে কিছুই নেই, তিনি তাঁর বিশ্বাসে আদর্শ মতামতযুক্ত জুনিয়র বিকাশকারী is কিছুই তাঁর মন পরিবর্তন করবে না বরং আরও অভিজ্ঞতা আইএমও করবে।

— ম্যাপেল_শ্যাফ্ট

15

সমস্যাগুলির মধ্যে থাকা অঞ্চলগুলির ক্ষেত্রে এটি সমস্যা নয়, তবে ক্ষেত্রে যখন অঞ্চলগুলিকে পদ্ধতিতে রাখার প্রয়োজন হয় (বা এমনকি ব্যবহারও হয়)।

প্রচুর পরিমাণে 200-300 লাইন পদ্ধতি ডিবাগ করার পরে, আমি আপনাকে বলতে পারি যে আমি কারও কাছে এটি কামনা করব না। যদি আপনি নিজের কোডটি লিখছেন এবং দেখছেন যে এটি দুর্দান্ত - আপনি যা চান তা করুন। তবে একবার অন্য কেউ এটি দেখার পরে, কোনও পদ্ধতি কী করছে তা অবিলম্বে পরিষ্কার হওয়া উচিত।

"প্রথমে এটি জিনিসগুলি পাওয়া যায় এবং তারপরে এটি তাদের চারপাশে টান দেয়, তারপরে যদি তাদের এটি গুঞ্জনের দরকার হয় তবে তা অন্যথায় এটি নীল কিনা এবং তাদের কোপার্নিকাসের মানটি উল্টে দেয় কিনা তা পরীক্ষা করে। রস বাক্সটি পাওয়া এবং এটি toোকানো দরকার ... "

না, এটি যথেষ্ট ভাল নয়। আপনি যা চান অঞ্চলগুলিতে এটি ভেঙে ফেলুন তবে আমি এখনও এটি সম্পর্কে চিন্তা করে মাথা নাড়ছি।

আপনি যদি পদ্ধতিগুলিতে বিভক্ত হন তবে আপনি অনেকগুলি সুবিধা পাবেন:

কী ঘটছে তার পরিষ্কার বোঝার উপায়, এমনকি কেবল নামটির মাধ্যমেই। আর তুমি ভুল করে একটি পদ্ধতি সম্পূর্ণরূপে নথিভুক্ত করা যাবে না - ডকুমেন্টেশন ব্লক (হিট যোগ ///) এবং বিবরণ, প্যারামিটার, রিটার্ন টাইপ লিখুন, এবং এছাড়াও exception, example, remarksবিস্তারিত ঐ পরিস্থিতিতে নোড। এটি যেখানে সেখানে যায়, এটাই তার জন্য!
কোনও পার্শ্ব প্রতিক্রিয়া বা স্কোপিংয়ের সমস্যা নেই। আপনি বলতে পারেন যে আপনি আপনার সমস্ত ভেরিয়েবলগুলি একটি সাব-স্কোপ দিয়ে ডিক্লেয়ার করেছেন {}তবে আপনি 'প্রতারণা' করেন নি তা নিশ্চিত করার জন্য আমাকে কি প্রতিটি পদ্ধতি পরীক্ষা করতে হবে? এটি কি dodgyObjectআমি এখানে কেবলমাত্র এই অঞ্চলে ব্যবহৃত হওয়ার কারণে ব্যবহার করছি, বা এটি অন্য কোথাও থেকে এসেছে? আমি যদি আমার নিজস্ব পদ্ধতিতে থাকতাম তবে আমি সহজেই দেখতে পেতাম যে এটি আমার কাছে পৌঁছেছে কিনা বা আমি নিজে এটি তৈরি করেছি কিনা (বা বরং আপনি এটি তৈরি করেছেন কিনা)।
আমার ইভেন্ট লগটি আমাকে জানিয়েছে যে কোন পদ্ধতিতে ব্যতিক্রম ঘটেছে Yes হ্যাঁ, আমি কোনও লাইন নম্বর সহ আপত্তিজনক কোডটি সন্ধান করতে সক্ষম হতে পারি, তবে পদ্ধতির নামটি জানার (বিশেষত যদি আমি তাদের সঠিকভাবে নাম রেখেছি) আমাকে খুব ভাল ইঙ্গিত দেয় gives কি হয়েছে এবং কি ভুল হয়েছে। "ওহ, TurnThingsUpsideDownপদ্ধতিটি ব্যর্থ হয়েছে - এটি সম্ভবত খারাপ জিনিস ঘুরিয়ে দেওয়ার সময় ব্যর্থ হচ্ছে" "ওহ, DoEverythingপদ্ধতিটি ব্যর্থ হয়েছিল - এটি 50 টি ভিন্ন জিনিস হতে পারে এবং এটি খুঁজে পেতে আমাকে এক ঘন্টা ধরে খনন করতে হবে" ।

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

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

— কर्क ব্রডহর্স্ট
সূত্র

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

— jjoelson

5

@ জোজেলসন আপনি এখনও ভিজ্যুয়াল স্টুডিও ছাড়াই এক্সএমএল মন্তব্যগুলি পড়তে পারেন, তবে অঞ্চল ট্যাগগুলি ভিএস এর বাইরে প্রায় সম্পূর্ণ অকেজো are আপনার যুক্তির যৌক্তিক বর্ধন হ'ল একটি বিশাল পদ্ধতি যা আপনার পুরো অ্যাপ্লিকেশনটি চালায় ঠিক আছে, যতক্ষণ আপনি এটি অঞ্চলগুলিতে বিভক্ত হয়ে থাকেন!

— কার্ক Broadhurst

2

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

— অলিভারস

@ অলিভারস, কির্কই তিনিই ছিলেন যিনি আমার অঞ্চলগুলিতে একটি পদ্ধতি প্রকল্পে সমস্যা হিসাবে ভাগ করে নেওয়ার অবস্থা নিয়ে এসেছিলেন। মূলত, আমি ঠিক পড়াটা ছিল কি আপনি ঠিক globals আইএসএন 'মাধ্যমে রাষ্ট্র পদ্ধতির মধ্যে ভাগ স্ক্রু আপ করার ক্ষমতা যেমন সত্য যে প্রোগ্রামার অঞ্চলে মধ্যে অনেকগুলি ভেরিয়েবল ভাগ করে রাষ্ট্র অপব্যবহার পারে নয় সমগ্র পরিকল্পনার একটি আর্জি: বলছে একাধিক-পদ্ধতি প্রকল্পের একটি অভিযুক্তি।

— জোজেলসন

7

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

"তবে আমার ক্লাসে কেবল একটি পাবলিক পদ্ধতি থাকবে!"

আপনি ঠিক বলেছেন, আর এতে কোনও ভুল নেই। একক দায়িত্ব নীতি সম্পর্কে ধারণাটি হল যে আপনার শ্রেণি একটি কাজ করে ।

আপনার শ্রেণি তিনটি পদ্ধতির পরিবর্তে প্রতিটি কল করতে পারে এবং ফলাফলটি ফিরে আসতে পারে। একটি জিনিস.

বোনাস হিসাবে, এখন আপনার পদ্ধতিটি পরীক্ষাযোগ্য কারণ এটি কোনও ব্যক্তিগত পদ্ধতি নয়।

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

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

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

সম্পাদনা :

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

সুতরাং আমি বলব একটি পদ্ধতির মাঝখানে ব্যবহার করা #regionউচিত নয় । আমি যদি কোনও পদ্ধতি খুলি, আমি কোডটি দেখতে চাই। #Region ব্যবহার করে আমাকে অন্য স্তরের আড়াল করতে দেয় যা আমার দরকার নেই, এবং এটি একটি বিরক্তিকর হয়ে ওঠে: আমি পদ্ধতিটি প্রকাশ করি ... এবং এখনও কোনও কোড দেখতে পাচ্ছি না।

যদি আপনি এই পদ্ধতির কাঠামোটি দেখে লোকেদের সম্পর্কে উদ্বিগ্ন হন (এবং আপনি এটি পুনরুদ্ধার করতে অস্বীকার করছেন), তবে ব্যানার মন্তব্যগুলি যুক্ত করুন:

//
// ---------- COMPUTE SOMETHING OR OTHER ----------
//

কোডগুলি ব্রাউজ করা কাউকে #regionট্যাগগুলি প্রসারণ এবং সংযোজন করার সাথে মোকাবেলা না করে আপনার পদ্ধতির স্বতন্ত্র অংশগুলি দেখতে সহায়তা করবে ।

— Kyralessa
সূত্র

2

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

— jjoelson

1

@ জোজোয়েলসন নতুন ক্লাস করা কি এত কঠিন? এটি কী, একটি লাইন, একটি খোলার বন্ধনী এবং একটি বন্ধনী বন্ধনী। ওহ, এবং আপনাকে টিপতে হবেctrl+n

— কर्क ব্রডহર્স্ট

2

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

— jjoelson

2

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

— কিরেলেসা

@ কাইরালেস, এটি এমন একটি পদ্ধতি যা কেবলমাত্র এক জায়গায় ব্যবহার করা হয়। এই জাতীয় পদ্ধতি পরিবর্তন করা আপনার অর্ধেক অ্যাপ্লিকেশনটি ছড়িয়ে দেবে না। যদি এ জাতীয় কোডটি ব্যবহার করে এমন পদ্ধতিতে অঞ্চল হিসাবে প্রয়োগ করা হয়, তবে আপনার নিখুঁত এনক্যাপসুলেশন রয়েছে; কেবলমাত্র সমন্বিত পদ্ধতিটিই কোডটি ব্যবহার করছে এবং সুতরাং সেই পদ্ধতি ব্যতীত আপনি এর প্রভাব সম্পর্কে চিন্তা না করে আপনি এটি যা চান তা পরিবর্তন করতে নির্দ্বিধায়।

— jjoelson

4

আমি মনে করি যে আপনি আপনার যুক্তিতে যে উদাহরণটি দিয়েছেন তা YAGNI সম্পর্কে কম নয় (আপনার এটি প্রয়োজন হবে না) এবং সহজেই বজায় রাখা যায় এমন উপযুক্ত মানের কোড লেখার বিষয়ে আরও বেশি।

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

দ্বিতীয়ত, আমি যদি পদ্ধতি A, B এবং C লিখি যা কেবলমাত্র D ডিডির মধ্যে ব্যবহৃত হয়, তবে আমি খুব সহজেই D এর স্বাধীনভাবে AB এবং C ইউনিট পরীক্ষা করতে পারি, যাতে সমস্ত 4 পদ্ধতিতে আরও দৃ rob় ইউনিট পরীক্ষার অনুমতি দেওয়া হয়।

— ম্যাপেল_শ্যাফট
সূত্র

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

— jjoelson

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

— ম্যাপেল_শ্যাফ্ট

2

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

— jjoelson

3

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

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

— ম্যাসন হুইলার
সূত্র

1

ctrl-f10- কার্সারে চলে যান

— স্টিভেন জিউরিস

2

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

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

এই সংজ্ঞা দ্বারা দীর্ঘ যে কার্যগুলি ভাঙ্গার কমপক্ষে দুটি সুবিধা রয়েছে:

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

আমার অভিজ্ঞতায়, এই বিধিগুলি এমন কোড তৈরি করে যা সাধারণ ভুল না করেই লেখার পক্ষে সহজ এবং সূক্ষ্ম আচরণগুলি না ভাঙিয়ে পরে বোঝা ও সংশোধন করা যায়। কোডটি বুঝতে বা সংশোধন করতে হবে এমন ব্যক্তি অন্য কেউ, বা আমি ঘুমিয়ে পড়ে সমস্ত কিছু ভুলে যাওয়ার পরে তা বিবেচ্য নয়।

সুতরাং আমি পদ্ধতিগুলিতে অঞ্চলগুলিকে একটি "কোড গন্ধ" হিসাবে বিবেচনা করব যা ইঙ্গিত করে যে অস্থিতিশীল অনুশীলনগুলি প্রয়োগ করা হচ্ছে। সর্বদা হিসাবে, ব্যতিক্রম হতে পারে, কিন্তু এগুলি এত কম ঘটে যে তারা প্রায় আলোচনা করার মতো নয়।

— PeterAllenWebb
সূত্র

2

এখানে আমরা আবার যাই ... প্রোগ্রামারগুলিতে এখানে প্রচুর অন্যান্য বিষয় রয়েছে যা একই আলোচনায় শেষ হয়েছে।

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

যাহোক ...

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

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

— স্টিভেন জিউরিস
সূত্র

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

— জোজেলসন

1

যদিও আমি সম্মত হই যে সাধারণত ব্যবহারের চেয়ে চুল্লী কোড ব্যবহার করা ভাল তবে #regionএটি সর্বদা সম্ভব হয় না।

এই বক্তব্যকে সমর্থন করার জন্য, আমি একটি উদাহরণ দিই।

class Foo : IComparable
{
  private String name;
  private int foo;
  private Bar bar;

  public int CompareTo(Foo other)
  {
#region Ascending on name
     if (this.name < other.name) return -1;
     if (this.name > other.name) return 1;
#endregion
#region Usual order on bar
     int compBar = bar.compareTo(other.bar);
     if (compBar != 0) return compBar;
#endregion
#region Descending on foo
     if (this.foo > other.foo) return -1;
     if (this.foo < other.foo) return 1;
#endregion
     return 0; // equal
  }

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

তবে সেই ব্যতিক্রমগুলি বিরল। অন্যান্য উত্তরগুলির মতো অনেকেই সাধারণত রিফ্যাক্টর করা সম্ভব।

— Sjoerd
সূত্র

0

আমি মনে করি না যে নির্দিষ্ট লোক বা দলগুলি কেন ব্যবহার না করার সিদ্ধান্ত নেয় তার একটি একক উত্তর আছে #regionতবে আমি যদি কয়েকটিকে তালিকাবদ্ধ করতে হত তবে এটিই আমি দেখলাম যে শীর্ষ কারণগুলি।

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

— jpierson
সূত্র