অপ্রয়োজনীয় শর্তটি কি সেরা অনুশীলনের বিরুদ্ধে চেক করা উচিত?


16

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

আমার একটি পাইথন প্রোগ্রাম রয়েছে যাতে আমি ...

  1. required=Trueদুটি আর্গুমেন্ট প্রয়োগ করতে আরগপার্স ব্যবহার করুন , যা উভয় ফাইলের নাম। প্রথমটি হ'ল ইনপুট ফাইলের নাম, দ্বিতীয়টি আউটপুট ফাইলের নাম
  2. একটি ফাংশন রয়েছে readFromInputFileযা প্রথমে পরীক্ষা করে দেখায় যে কোনও ইনপুট ফাইলের নাম প্রবেশ করা হয়েছে
  3. একটি ফাংশন রয়েছে writeToOutputFileযা প্রথমে পরীক্ষা করে দেখায় যে একটি আউটপুট ফাইলের নাম প্রবেশ করা হয়েছিল

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

(এছাড়াও, যদি পড়তে বা লিখতে ব্যর্থ হয় তবে try exceptযথাযথ ত্রুটি বার্তা উত্থাপনের জন্য প্রতিটি ফাংশনটিতে আমার একটি রয়েছে))

আমার প্রশ্ন হ'ল: সমস্ত অপ্রয়োজনীয় অবস্থা পরীক্ষা করা কি এড়ানো ভাল? কোনও প্রোগ্রামের যুক্তি কি এতই শক্ত হওয়া উচিত যে চেকগুলি একবারে তৈরি করা দরকার? এই বা কথোপকথন চিত্রিত কোন ভাল উদাহরণ আছে?

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


আপনার প্রশ্নের একটি ভারী সাধারণকরণ সংস্করণ এখানে রয়েছে: সফ্টওয়্যারেনজিনিয়ারিং.স্ট্যাকেকেক্সচেঞ্জ / প্রশ্নগুলি / ১৯৫৯/২ । আমি এটি বলব না যে এটি সদৃশ কারণ এটির বেশ বড় ফোকাস রয়েছে তবে এটি সাহায্য করবে।
ডক ব্রাউন

উত্তর:


15

আপনি যেটির জন্য জিজ্ঞাসা করছেন তাকে "দৃ .়তা" বলা হয় এবং এর সঠিক বা ভুল উত্তর নেই। এটি প্রোগ্রামের আকার এবং জটিলতা, এতে কাজ করা লোকের সংখ্যা এবং ব্যর্থতা সনাক্তকরণের গুরুত্বের উপর নির্ভর করে।

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

আপনার ক্ষেত্রে, আপনার নিজের জন্য সিদ্ধান্ত নিতে হবে, আপনি আপনার প্রোগ্রামের জন্য কোন ধরণের জীবনচক্র আশা করছেন। এটি কি এমন একটি প্রোগ্রাম যা আপনি বছরের পর বছর ধরে ব্যবহার এবং পরিচালনা করার প্রত্যাশা করছেন? তারপরে রিডান্ট্যান্ট চেক যুক্ত করা সম্ভবত আরও ভাল, যেহেতু আপনার কোডটি ভবিষ্যতে রিফ্যাক্টর হবে এবং আপনার readএবং writeফাংশনগুলি অন্য কোনও প্রসঙ্গে ব্যবহৃত হতে পারে এমন সম্ভাবনা কম ।

বা এটি কেবল শেখার বা মজাদার উদ্দেশ্যেই একটি ছোট প্রোগ্রাম? তারপরে এই ডাবল চেকগুলির প্রয়োজন হবে না।

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

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

  • প্রোগ্রামটি একটি যুক্তির সাথেও কাজ করবে, ইনপুট ফাইলের নাম, যদি কোনও আউটপুট ফাইলের নাম দেওয়া না থাকে, তবে এটি প্রত্যয়টি প্রতিস্থাপন করে ইনপুট ফাইলের নাম থেকে স্বয়ংক্রিয়ভাবে নির্মিত হয়।

এটি কি আপনাকে সম্ভবত দুটি জায়গায় আপনার দ্বিগুণ বৈধতা পরিবর্তন করার প্রয়োজন করে তোলে? সম্ভবত না, কল করার সময় এই জাতীয় প্রয়োজনের ফলে একটি পরিবর্তন ঘটে argparse, তবে কোনও পরিবর্তন হয় না writeToOutputFile: সেই ফাংশনটিতে এখনও একটি ফাইলের নাম প্রয়োজন হবে। সুতরাং আপনার ক্ষেত্রে, আমি ইনপুট যাচাইকরণের জন্য দুবার ভোট দেব, খুব কম চেকের কারণে মুখোশযুক্ত ত্রুটির কারণে রক্ষণাবেক্ষণের সমস্যা হওয়ার ঝুঁকির চেয়ে আইএমএইচও অনেক কম change


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

@ আদারবোব: আমি যা লিখেছি তা ক্লাসের আকারে ওওপি বা উপাদানগুলির মধ্যে সীমাবদ্ধ নয়। এটি কোনও পাবলিক এপিআই, অবজেক্ট ওরিয়েন্টেড বা না দিয়ে স্বেচ্ছাসেবী লাইব্রেরিতেও প্রযোজ্য।
ডক ব্রাউন

5

অতিরিক্ত কাজ পাপ নয়। অপ্রয়োজনীয় অপ্রয়োজনীয়তা।

  1. যদি readFromInputFile()এবংwriteToOutputFile() সর্বজনীন কার্যাবলী হয় (এবং পাইথন নামকরণের কনভেনশনগুলি সেগুলি যেহেতু তাদের নাম দুটি আন্ডারস্কোর দিয়ে শুরু হয়নি) তবে ফাংশনগুলি কোনও দিন পুরোপুরি অর্গপার্স এড়িয়ে যাওয়া এমন ব্যক্তির দ্বারা ব্যবহৃত হতে পারে। এর অর্থ যখন তারা যুক্তিগুলি ত্যাগ করেন তখন তারা আপনার কাস্টম আরগপার্স ত্রুটি বার্তাটি দেখতে পাবেন না।

  2. যদি readFromInputFile()এবংwriteToOutputFile() নিজেরাই প্যারামিটারগুলি পরীক্ষা করে থাকেন তবে আপনাকে আবার একটি কাস্টম ত্রুটি বার্তা প্রদর্শন করতে হবে যা ফাইলের প্রয়োজনের প্রয়োজনীয়তা ব্যাখ্যা করে।

  3. যদি readFromInputFile()এবং writeToOutputFile()তাদের নিজেরাই প্যারামিটারগুলি পরীক্ষা না করে তবে কোনও কাস্টম ত্রুটি বার্তা প্রদর্শিত হবে না। ব্যবহারকারীকে তাদের নিজস্ব ফলস্বরূপ ব্যতিক্রমটি বের করতে হবে।

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

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


4

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

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

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


1

ধরুন আপনার একটি ফাংশন রয়েছে (সি তে)

void readInputFile (const char* path);

এবং আপনি পাথ সম্পর্কে কোনও ডকুমেন্টেশন খুঁজে পাবেন না। এবং তারপরে আপনি বাস্তবায়নের দিকে তাকান এবং এটি বলে

void readInputFile (const char* path)
{
    assert (path != NULL && strlen (path) > 0);

এটি কেবল এই ফাংশনটিতে ইনপুট পরীক্ষা করে না, তবে এটি ফাংশনটির ব্যবহারকারীকেও বলে যে পাথটি NULL বা খালি স্ট্রিং হওয়ার অনুমতি নেই।


0

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

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

0

আপনার ডাবল-চেকগুলি এমন জায়গাগুলিতে মনে হয় যেখানে সেগুলি খুব কম ব্যবহার করা হয়। সুতরাং এই চেকগুলি কেবল আপনার প্রোগ্রামটিকে আরও শক্তিশালী করে তুলছে:

খুব বেশি একটি চেক ক্ষতিগ্রস্থ করবে না, এটি খুব কম হতে পারে।

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


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

0

সম্ভবত আপনি আপনার দৃষ্টিভঙ্গি পরিবর্তন করতে পারেন:

যদি কিছু ভুল হয়ে যায় তবে ফলাফল কী হবে? এটি আপনার অ্যাপ্লিকেশন / ব্যবহারকারীর ক্ষতি করবে?

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

আপনি যে প্রসঙ্গটি দিচ্ছেন তা থেকে:

  • একটি ইনপুট ফাইল
  • একটি আউটপুট ফাইল বি

আমি ধরে নিচ্ছি আপনি A থেকে B তে রূপান্তর করছেন । যদি A এবং B ছোট হয় এবং রূপান্তরটি ছোট হয় তবে এর পরিণতিগুলি কী হবে?

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

2) আপনি আউটপুট ফাইল নির্দিষ্ট করতে ভুলে গেছেন। এটি বিভিন্ন পরিস্থিতিতে ফলাফল:

ক) ইনপুট একবারে পড়া হয়। পরিবর্তনের পরিবর্তে শুরু হয় এবং ফলাফলটি লেখা উচিত, তবে পরিবর্তে আপনি একটি ত্রুটি পান। সময়ের উপর নির্ভর করে আপনার ব্যবহারকারীকে অপেক্ষা করতে হবে (প্রক্রিয়াজাতকরণের ডেটা ভরতে নির্ভর করে) এটি বিরক্তিকর হতে পারে।

খ) ইনপুটটি ধাপে ধাপে পড়া হয়। তারপরে লেখার প্রক্রিয়াটি তত্ক্ষণাত (1) এর মতো প্রস্থান করে এবং ব্যবহারকারী আবার শুরু হয়।

ঝাল চেকিং ঠিক আছে হিসাবে দেখা যেতে পারে করা কিছু পরিস্থিতিতে । এটি সম্পূর্ণরূপে আপনার ব্যবহারের ক্ষেত্র এবং আপনার উদ্দেশ্য কী তার উপর নির্ভর করে depends

অতিরিক্ত: আপনার প্যারাওয়েয়া এড়ানো উচিত এবং খুব বেশি ডাবল চেক না করা উচিত।


0

আমি তর্ক করব যে পরীক্ষাগুলি নিরর্থক নয়।

  • আপনার দুটি পাবলিক ফাংশন রয়েছে যার একটি ইনপুট প্যারামিটার হিসাবে একটি ফাইলের নাম প্রয়োজন। তাদের পরামিতিগুলি বৈধকরণ করা উপযুক্ত। ফাংশনগুলি তাদের কার্যকারিতা প্রয়োজন এমন কোনও প্রোগ্রামে সম্ভাব্যভাবে ব্যবহার করা যেতে পারে।
  • আপনার একটি প্রোগ্রাম রয়েছে যাতে দুটি যুক্তি প্রয়োজন যা ফাইলের নাম হতে হবে। এটি ফাংশন ব্যবহার করতে ঘটে। প্রোগ্রামটির পরামিতিগুলি পরীক্ষা করা উপযুক্ত।

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

আরও শক্তিশালী সমাধানে এক বা দুটি ফাইলের নাম বৈধকারক থাকবে।

  • একটি ইনপুট ফাইলের জন্য, আপনি পরামিতি একটি পঠনযোগ্য ফাইল নির্দিষ্ট করেছে তা যাচাই করতে চাইতে পারেন।
  • একটি আউটপুট ফাইলের জন্য, আপনি যাচাই করতে চাইতে পারেন যে প্যারামিটারটি একটি লিখনযোগ্য ফাইল বা একটি বৈধ ফাইলের নাম যা তৈরি এবং এতে লিখিত হতে পারে।

কখন ক্রিয়া সম্পাদন করতে হবে তার জন্য আমি দুটি নিয়ম ব্যবহার করি:

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

0

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

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

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

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