কলারে ইনপুট প্যারামিটারের বৈধতা: কোড নকল?

16

ফাংশনের ইনপুট পরামিতিগুলি যাচাই করার জন্য সেরা স্থানটি কোথায়: কলারে বা নিজেই ফাংশনে?

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

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

সুতরাং এর অর্থ হ'ল, ফাংশনটি কল করার আগে আমার ইনপুট পরামিতিগুলি বৈধ করা উচিত। যেখানেই ফাংশন বলা হয়। এবং এটি একটি প্রশ্ন উত্থাপন করে: এটি ফাংশনটি যেখানেই বলা হয় সেখানে যাচাই করার শর্তটির সদৃশ তৈরি করে না?

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

ইনপুট শর্তটি কোথায় পরীক্ষা করতে হবে সে সম্পর্কে কীভাবে কিছু বিধি আছে?

আমি কিছু যুক্তি সম্পর্কে চিন্তা করছি:

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

আমি আশা করি এই প্রশ্নটি অন্য কোনওটির সদৃশ নয়, আমি এই সমস্যাটি অনুসন্ধান করেছি এবং আমি একই রকম প্রশ্ন পেয়েছি তবে তারা ঠিক এই ক্ষেত্রে উল্লেখ করে না।

coding-standards validation dry

— srnka
সূত্র

15

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

আপনি একটি সর্বজনীন পদ্ধতি তৈরি করার সময় এটি একটি বিশেষ গুরুত্বপূর্ণ ধারণা , কারণ আপনি মূলত বিজ্ঞাপন দিচ্ছেন যে কোনও পদ্ধতি কোনও ক্রিয়াকলাপ সম্পাদন করে। এটি আপনি যা বলছেন তা আরও ভাল করে!

উদাহরণ হিসাবে নিচের পদ্ধতিটি ধরুন:

public void DeletePerson(Person p)
{            
    _database.Delete(p);
}

চুক্তি দ্বারা বোঝানো কী DeletePerson? প্রোগ্রামার কেবলমাত্র ধরে নিতে পারে যে যদি কোনও Personপাস করা হয় তবে তা মুছে ফেলা হবে। তবে, আমরা জানি যে এটি সর্বদা সত্য নয়। কি হবে যদি pএকটি হয় nullমূল্য কত? pডাটাবেসে উপস্থিত না থাকলে কী হবে ? ডাটাবেস সংযোগ বিচ্ছিন্ন হলে কী হবে? সুতরাং, ডিলিটপারসন এটির চুক্তিটি ভালভাবে দেখাতে উপস্থিত হবে না। কখনও কখনও এটি কোনও ব্যক্তিকে মুছে দেয় এবং কখনও কখনও এটি একটি নুলারফেরান এক্সসেপশন, বা একটি ডেটাবেসনোটকনেক্টেড এক্সেক্সশন ফেলে দেয় বা কখনও কখনও এটি কিছুই করে না (যেমন যদি ব্যক্তি ইতিমধ্যে মুছে ফেলা হয়)।

এর মতো এপিআইগুলি ব্যবহার করা কুখ্যাতভাবে কঠিন, কারণ আপনি যখন কোনও পদ্ধতির এই "ব্ল্যাক বক্স" কল করেন, তখন সমস্ত ধরণের ভয়ঙ্কর ঘটনা ঘটতে পারে।

আপনি চুক্তিটি উন্নত করতে পারেন এমন কয়েকটি উপায় এখানে রইল:

বৈধতা যুক্ত করুন এবং চুক্তিতে একটি ব্যতিক্রম যুক্ত করুন। এটি চুক্তিটিকে আরও দৃ stronger় করে তোলে , তবে কলার বৈধতা কার্যকর করার প্রয়োজন। পার্থক্যটি হ'ল এখন তারা তাদের প্রয়োজনীয়তাগুলি জানে। এই ক্ষেত্রে আমি এটি একটি সি # এক্সএমএল মন্তব্যে যোগাযোগ করি তবে আপনি পরিবর্তে একটি throws(জাভা) যুক্ত করতে পারেন Assert, কোড ব্যবহার করতে পারেন বা চুক্তি সরঞ্জাম কোড চুক্তিগুলির মতো ব্যবহার করতে পারেন।
```
///<exception>ArgumentNullException</exception>
///<exception>ArgumentException</exception>
public void DeletePerson(Person p)
{            
    if(p == null)
        throw new ArgumentNullException("p");
    if(!_database.Contains(p))
        throw new ArgumentException("The Person specified is not in the database.");

    _database.Delete(p);
}
```
_{পার্শ্ব দ্রষ্টব্য: এই শৈলীর বিপরীতে যুক্তিটি প্রায়শই যে এটি সমস্ত কলিং কোড দ্বারা অতিরিক্ত প্রাক-বৈধকরণের কারণ হয়ে থাকে, তবে আমার অভিজ্ঞতাতে এটি প্রায়শই হয় না। এমন কোনও দৃশ্যের কথা ভাবুন যেখানে আপনি কোনও নাল ব্যক্তিকে মুছতে চাইছেন। তা কীভাবে হল? নাল ব্যক্তিটি কোথা থেকে এল? এটি যদি কোনও ইউআই হয়, উদাহরণস্বরূপ, বর্তমান নির্বাচন না থাকলে মুছুন কী হ্যান্ডেল করা হয়েছিল? যদি এটি ইতিমধ্যে মুছে ফেলা হয় তবে এটি ইতিমধ্যে প্রদর্শন থেকে সরানো উচিত নয়? স্পষ্টতই এর ব্যতিক্রমগুলি রয়েছে, তবে একটি প্রকল্প বাড়ার সাথে সাথে আপনি প্রায়শই সিস্টেমে ডুবে থাকা বাগগুলি রোধ করার জন্য এই জাতীয় কোডটিকে প্রায়ই ধন্যবাদ জানাতে পারেন।}
আত্মরক্ষার সাথে বৈধতা এবং কোড যুক্ত করুন। এটি চুক্তিটি লুজার করে তোলে , কারণ এখন এই পদ্ধতিটি ব্যক্তিকে মোছার চেয়ে আরও বেশি কিছু করে। এটি প্রতিবিম্বিত করার জন্য আমি পদ্ধতির নামটি পরিবর্তন করেছি, তবে আপনি যদি আপনার এপিআইতে সামঞ্জস্য হন তবে প্রয়োজন হতে পারে না। এই পদ্ধতির তার পক্ষে মতামত রয়েছে। প্রো যে আপনি এখন TryDeletePersonঅবৈধ ইনপুট সব ধরণের পাসিং কল করতে পারেন এবং ব্যতিক্রম সম্পর্কে চিন্তা করবেন না। অবশ্যই, কন, আপনার কোড ব্যবহারকারীরা সম্ভবত এই পদ্ধতিটি খুব বেশি কল করবেন বা p নালার ক্ষেত্রে এটি ডিবাগিংকে জটিল করে তুলবে। এটি একক দায়িত্বের নীতিমালার হালকা লঙ্ঘন হিসাবে বিবেচিত হতে পারে , সুতরাং শিখা যুদ্ধের সূত্রপাত হলে সেই বিষয়টি মনে রাখুন।
```
public void TryDeletePerson(Person p)
{            
    if(p == null || !_database.Contains(p))
        return;

    _database.Delete(p);
}
```
পন্থা একত্রিত কখনও কখনও আপনি উভয়ই একটু চান, যেখানে আপনি বহিরাগত কলাররা নিয়মগুলি নিবিড়ভাবে অনুসরণ করতে চান (তাদের দায়বদ্ধ কোডে বাধ্য করতে) তবে আপনি চান যে আপনার ব্যক্তিগত কোডটি নমনীয় হোক।
```
///<exception>ArgumentNullException</exception>
///<exception>ArgumentException</exception>
public void DeletePerson(Person p)
{            
    if(p == null)
        throw new ArgumentNullException("p");
    if(!_database.Contains(p))
        throw new ArgumentException("The Person specified is not in the database.");

    TryDeletePerson(p);
}

internal void TryDeletePerson(Person p)
{            
    if(p == null || !_database.Contains(p))
        return;

    _database.Delete(p);
}
```

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

— কেভিন ম্যাককর্মিক
সূত্র

উদাহরণ সহ খুব সুন্দর উত্তরের জন্য ধন্যবাদ। আমি "প্রতিরক্ষামূলক" এবং "কঠোর চুক্তি" পদ্ধতির বিন্দু পছন্দ করি।

— srnka

7

এটি কনভেনশন, ডকুমেন্টেশন এবং ইউজ কেসের বিষয়।

সমস্ত ফাংশন সমান নয়। সমস্ত প্রয়োজনীয়তা সমান নয়। সমস্ত বৈধতা সমান নয়।

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

যদি প্রকল্পটি সি ++ এ থাকে? সি ++ তে কনভেনশন / traditionতিহ্য হ'ল পূর্ববর্তী শর্তাদি নথিভুক্ত করা, তবে কেবলমাত্র ডিবাগ বিল্ডগুলিতে সেগুলি যাচাই করুন all

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

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

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

— সেবাস্তিয়ান রেডল
সূত্র

আপনার উত্তরের জন্য ধন্যবাদ. আপনি, দয়া করে, পেয়ারা শৈলী সুপারিশ লিঙ্ক দিতে পারেন? আমি গুগল করতে পারি না এবং এর দ্বারা আপনি কী বোঝাতে চেয়েছেন তা খুঁজে বের করতে পারি না। সীমানা বৈধতা জন্য +1।

— srnka

যোগ করা লিঙ্ক। এটি আসলে কোনও পূর্ণ শৈলীর গাইড নয়, নন-নাল ইউটিলিটিগুলির ডকুমেন্টেশনের একটি অংশ।

— সেবাস্তিয়ান রেডল

6

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

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

— বার্নার্ড
সূত্র

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

— srnka

1

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

— বার্নার্ড

4

ফাংশন নিজেই মধ্যে। যদি ফাংশনটি একাধিকবার ব্যবহৃত হয় তবে আপনি প্রতিটি ফাংশন কলের জন্য প্যারামিটারটি যাচাই করতে চাইবেন না।

তদুপরি, যদি ফাংশনটি এমনভাবে আপডেট করা হয় যা প্যারামিটারের বৈধতা প্রভাবিত করে, তাদের আপডেট করার জন্য আপনাকে কলারের বৈধতার প্রতিটি ঘটনা সন্ধান করতে হবে। এটি সুন্দর নয় :-)।

আপনি গার্ড ক্লজ উল্লেখ করতে পারেন

হালনাগাদ

আপনার দেওয়া প্রতিটি দৃশ্যের জন্য আমার জবাবটি দেখুন।

যখন অবৈধ ভেরিয়েবলের চিকিত্সা পৃথক হতে পারে, কলার পক্ষে এটি যাচাই করা ভাল (উদাহরণস্বরূপ sqrt()ফাংশন - কোনও ক্ষেত্রে আমি জটিল সংখ্যার সাথে কাজ করতে চাইতে পারি, তাই আমি শর্তটিকে কলারে চিকিত্সা করি)

উত্তর

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

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

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

উত্তর

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

উত্তর

কলারটি যদি একটি ফাংশন হয় তবে এটি দুর্দান্ত হবে, আপনি কি ভাবেন না?

যদি কলারের মধ্যে থাকা ফাংশনগুলি অন্য কলার দ্বারা ব্যবহৃত হয়, তবে কলার কলকারী ফাংশনগুলির মধ্যে প্যারামিটারটি যাচাই করতে আপনাকে কী বাধা দেয়?
সঠিক সমাধানটি নির্দিষ্ট ক্ষেত্রে নির্ভর করে

উত্তর

রক্ষণাবেক্ষণযোগ্য কোডের জন্য লক্ষ্য। আপনার প্যারামিটারের বৈধতা সরিয়ে ফাংশনটি কী গ্রহণ করতে পারে বা না সে সম্পর্কে সত্যতার একটি উত্স নিশ্চিত করে।

— OnesimusUnbound
সূত্র

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

— srnka

2

একটি ফাংশন এর প্রাক- এবং পোস্ট-শর্তাবলীর কথা বলা উচিত।
প্রাক-শর্তগুলি হ'ল শর্তগুলি যা কলকারী সঠিকভাবে ফাংশনটি ব্যবহার করতে পারে তার আগে এবং অবশ্যই ইনপুট পরামিতিগুলির বৈধতা অন্তর্ভুক্ত করতে পারে (
শর্ত পরবর্তী পোস্টগুলি প্রতিশ্রুতি দেয় যা ফাংশনটি তার কলকারীদের কাছে করে।

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

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

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

— বার্ট ভ্যান ইনজেন শেহানাউ
সূত্র

+1 উত্তরের জন্য ধন্যবাদ। চমৎকার প্রতিচ্ছবি: "কলি চেকের ফলে কোডের সদৃশতা ঘটে এবং প্রচুর শিবিরহীন কাজ করা হয়"। এবং এই বাক্যে: "বেশিরভাগ ক্ষেত্রে, কোনও স্পষ্ট পরীক্ষার প্রয়োজন হয় না কারণ অভ্যন্তরীণ যুক্তি এবং কলারের প্রাক-শর্তগুলি ইতিমধ্যে নিশ্চিত করে" - "অভ্যন্তরীণ যুক্তি" বলতে আপনাকে কী বোঝাতে চেয়েছি? ডিবিসি কার্যকারিতা?

— srnka

@ এসআরএনকা: "অভ্যন্তরীণ যুক্তি" দিয়ে আমি বোঝাচ্ছি কোনও কার্যের গণনা এবং সিদ্ধান্ত। এটি মূলত ফাংশনটির বাস্তবায়ন।

— বার্ট ভ্যান ইনজেন শেেনা

0

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

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

— superM
সূত্র

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

— জন আর স্ট্রোহম