আমি কি আমার পিএইচপি কোডটিতে জোড় ব্যবহার করব?

Question

একজন সহকর্মী আমাদের লাইব্রেরিগুলিতে এমন জায়গাগুলিতে কয়েকবার অ্যাসিস্ট কমান্ড যুক্ত করেছেন যেখানে আমি যদি একটি বিবৃতি ব্যবহার করেছি এবং একটি ব্যতিক্রম ছুঁড়েছি। (আমি এর আগে কখনও দৃsert়তার কথাও শুনিনি)) তিনি কীভাবে এটি ব্যবহার করেছিলেন তার একটি উদাহরণ এখানে দেওয়া হয়েছে:

assert('isset($this->records); /* Records must be set before this is called. */');

আমি পারবই:

if (!isset($this->records)) {
    throw new Exception('Records must be set before this is called');
}

দৃ on়তার সাথে পিএইচপি ডকস পড়ার থেকে দেখে মনে হচ্ছে এটি দৃ active়ভাবে সক্রিয় রয়েছে এবং নিশ্চিত করা ব্যবহারের আগে হ্যান্ডলার যুক্ত করার পরামর্শ দেওয়া হচ্ছে। তিনি এমন কাজ করেছেন এমন কোনও জায়গা আমি খুঁজে পাচ্ছি না।

সুতরাং, আমার প্রশ্নটি হ'ল উপরের বর্ণিত ভাল ধারণাটি ব্যবহার করা কি আমি এবং এর ব্যতিক্রমগুলির পরিবর্তে আরও বেশি বার ব্যবহার করা উচিত?

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

Comments

এটি কি সত্যিই 'isset(সহ কোড লাইন assert)? শুধু isset(একক উদ্ধৃতি ব্যতীত ') নয়?

— পিটার মর্টেনসেন

Answer 1

বেশিরভাগ ভাষায় প্রযোজ্য থাম্বের নিয়মটি (যা আমি অস্পষ্টভাবে জানি) assertএটি একটি শর্তটি সর্বদা সত্য বলে দাবি করার জন্য ব্যবহৃত হয় তবে ifএটি যদি কখনও কখনও অনুমেয় হয় যে এটি কখনও কখনও ব্যর্থ হয়।

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

এর assertবিপরীতে ব্যবহার করার সুবিধাটি ifহ'ল assertসাধারনত প্রোডাক্ট কোডে এইভাবে ওভারহেড হ্রাস করা যায়। যে ধরণের পরিস্থিতি সর্বোত্তমভাবে পরিচালিত হয় সেগুলি ifউত্পাদন পদ্ধতিতে রানটাইম চলাকালীন ঘটতে পারে এবং তাই সেগুলি বন্ধ না করে কিছুই হারিয়ে যায় না।

Comments

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

— derekerdmann

@ ডিয়ারেকারডম্যান: সত্য। কিছু দৃ For়তার জন্য এটি লগ ইন (উত্পাদনে) বা সতর্কতা (বিকাশের পরিবেশে) মুদ্রণ করার পক্ষে যথেষ্ট। তবে যেহেতু প্রায়শই জোর দেওয়া সুরক্ষা সম্পর্কিত প্রাসঙ্গিক কোডও সুরক্ষিত করে, আপনি পাশাপাশি সক্ষম করতে পারেন assert_options(ASSERT_BAIL)। যদি / যাইহোক workaround নিক্ষেপ করা ম্যানুয়াল থেকে এটি দ্রুত।

— মারিও

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

— ভিটিলিয় লেবেদেভ

@ ভিটিলিয়ালবেদেভ যদি আপনি ইঞ্জেকশনের সংবেদনশীল হতে না চান তবে দৃsert়তার সাথে স্ট্রিংগুলি পাস করবেন না।

— দামন স্নাইডার

পার্টিতে দেরিতে হলেও পিএইচপি.এন.টি জানিয়েছে: "দাবিগুলি কেবল একটি ডিবাগিং বৈশিষ্ট্য হিসাবে ব্যবহার করা উচিত" "

— কোয়েন

Answer 2

"পাওয়ার মন্তব্য" হিসাবে দাবীগুলি ভাবেন। পরিবর্তে মত মতামত:

// Note to developers: the parameter "a" should always be a number!!!

ব্যবহার:

assert('is_numeric(a) /* The parameter "a" should always be a number. */');

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

এইভাবে দেখা যায়, দাবিগুলি (ত্রুটি) ... এবং ব্যতিক্রমগুলির চেয়ে সম্পূর্ণ আলাদা ধারণা এবং সেগুলি সহ-বিদ্যমান থাকতে পারে।

হ্যাঁ, আপনার কোডটি মন্তব্য করা উচিত, এবং হ্যাঁ, যখনই সম্ভব আপনার "পাওয়ার মন্তব্য" (জোর দেওয়া) ব্যবহার করা উচিত।

Comments

বিকাশের ক্ষেত্রে যদি আপনি যখন সর্বদা দৃ to়স্বরে উত্তম শর্তটি পাঠান তবে উত্পাদনে যদি দাবি বন্ধ থাকে - কিছু ব্যবহারকারী অন্য শর্তটি পাস করেন যা আপনি পরীক্ষার সময় ভাবেননি? অথবা অন্যথায় আপনার সর্বদা দৃ as়তা রাখা দরকার, তবে তা কি আপনার নিজের চেক লেখার মতো নয়?

— দারিয়াক

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

— ডেভওয়ালি

নোট করুন যে পিএইচপি 7.2 হিসাবে মূল্যায়নের জন্য দৃ a়তার মধ্যে একটি স্ট্রিং পাস করা হ্রাস হয়েছে। দুঃখিত, কারণ এটি বেশ সহজ লাগছিল looked

— জেনি থিউনিসন 11:56

Answer 3

এটি সম্পূর্ণরূপে আপনার উন্নয়ন কৌশলের উপর নির্ভর করে। বেশিরভাগ বিকাশকারী অজানা assert()এবং ডাউন স্ট্রিম ইউনিট টেস্টিং ব্যবহার করেন। তবে সক্রিয় এবং বিল্ট-ইন টেস্টিং স্কিমগুলি কখনও কখনও সুবিধাজনক হতে পারে।

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

 function xyz($a, $b) {
     assert(is_string($a));
     assert(is_array($b));

উদাহরণস্বরূপ যা টাইপ স্পেসিফায়ারের অভাবের জন্য ক্ষতিপূরণ দেয় string $a, array $b। PHP5.4 তাদের সমর্থন করবে, তবে চেক করবে না।

Comments

"পিএইচপি 5.4 এগুলি কি তবে চেক নয়" এর অর্থ কী?

— কেজকাই

পিএইচপি 5.4 রয়েছে, সমর্থন এবং চেক হিসাবে।

— ডেভওয়ালি

Answer 4

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

Answer 5

পিএইচপি-র পূর্ববর্তী 7. এর চেয়ে বেশি গুরুত্বপূর্ণ একটি নোট 7. টির তুলনায় অন্য ভাষাগুলির মতো, পিএইচপি সম্পূর্ণরূপে বিবৃতি পুরোপুরি ফেলে দেয় না - এটি এটিকে একটি ফাংশন হিসাবে বিবেচনা করে (একটি ডিবেগ_ব্যাকট্র্যাস () একটি দৃ an়তা হিসাবে ডাকা হয়)। দৃser়তা বন্ধ করা কেবল ইঞ্জিনে কিছুই না করে ফাংশনটিকে হটওয়্যার করে বলে মনে হচ্ছে। দ্রষ্টব্য যে পিএইচপি 7 এ 1 (চালু) বা -1 (অফ) এর আরও সাধারণ মানের পরিবর্তে zend.assertions 0 এ সেট করে এই আচরণটি অনুকরণ করা যায়।

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

<?php
  function foo($a) { 
    echo $a . "\n"; 
    return TRUE;
  }
  assert_options(ASSERT_ACTIVE, FALSE);

  assert( foo('You will see me.'));
  assert('foo(\'You will not see me.\')');

  assert_options(ASSERT_ACTIVE, TRUE);

  assert( foo('Now you will see'));
  assert('foo(\'both of us.\')');

দৃsert়তার উদ্দেশ্যটি দেওয়া হ'ল এটি একটি বাগ এবং দীর্ঘকাল স্থায়ী এটি যেহেতু এটি ভাষায় রয়েছে সেহেতু পিএইচপি 4-এ ফিরে আসার সূচনা হয়েছিল।

স্ট্রিংগুলি দৃ as়ভাবে জানানো হয়েছে যে সমস্ত পারফরম্যান্সের প্রভাব এবং বিপত্তিগুলি এর সাথে আসে তবে এটি পিএইচপি-তে যেভাবে করা উচিত সেভাবে কাজ করার জন্য দৃsert় বিবৃতি পাওয়ার একমাত্র উপায় (এই আচরণটি পিএইচপি 7.২ এ হ্রাস পেয়েছে)।

সম্পাদনা: পিএইচপি 7 এবং 7.2 এ পরিবর্তনগুলি লক্ষ্য করার জন্য উপরে পরিবর্তিত হয়েছে

Comments

পিএইচপি zend.assertionsIn-তে সম্পূর্ণভাবে অফ করার জন্য ইনি সেটিং থাকবে / থাকবে assert()।

— কনট্রোলফ্রেইক

এটি দুর্দান্ত খবর - তবে ডকুমেন্টেশনের উপর ভিত্তি করে দেখে মনে হচ্ছে পিএইচপিউইনাইটের কাছে কোনও প্যাচ অর্ডার হচ্ছে, পিএইচপি 5.x এর অধীন দাবীগুলি ব্যর্থ হলে AssertionException নিক্ষেপ করার জন্য একটি দৃsert় কলব্যাক হ্যান্ডলার যুক্ত করুন এইভাবে ইউনিট পরীক্ষাগুলি পিএইচপি 5.x বা 7

— মাইকেল মরিস

Answer 6

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

Comments

তবে একটিতে কোডটিতে দৃser়পদ থাকবে। তারা কেবলমাত্র উত্পাদন পরিবেশে সক্রিয় হবে না।

— অ্যারোনস্টার্লিং

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

— ড্যানিয়েল ডাব্লু।

Answer 7

না, আপনার সহকর্মীকে এটিকে সাধারণ উদ্দেশ্যে ত্রুটি হ্যান্ডলার হিসাবে ব্যবহার করা উচিত নয়। ম্যানুয়াল অনুসারে:

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

ইনপুট প্যারামিটার চেকের মতো সাধারণ রানটাইম ক্রিয়াকলাপের জন্য জোর ব্যবহার করা উচিত নয় should থাম্বের নিয়ম হিসাবে আপনার কোডটি সর্বদা সঠিকভাবে কাজ করতে সক্ষম হওয়া উচিত যদি দৃ checking়তা পরীক্ষা করা সক্রিয় হয় না।

আপনি যদি স্বয়ংক্রিয় পরীক্ষার স্যুটগুলির সাথে পরিচিত হন তবে "দাবী" ক্রিয়াটি সাধারণত কোনও পদ্ধতি বা ফাংশনের আউটপুট যাচাই করতে ব্যবহৃত হয়। উদাহরণ স্বরূপ:

function add($a, $b) {
    return $a + $b;
}

assert(add(2,2) == 5, 'Two and two is four, dummy!');
assert(is_numeric(add(2,2)), 'Output of this function to only return numeric values.');

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

Answer 8

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

উক্তিটি তিনি যেমন ব্যবহার করেছিলেন, তেমনটি হ্যারে লজিক বা হোয়ার ট্রিপল-এর ​​{পি}-অংশ হবে: {পি} সি {কিউ}, যেখানে {পি} পূর্ব শর্তের দাবী (আয়ন) এর এবং {কিউ} শর্ত-পরবর্তী দাবী (আয়ন) গুলি।

আমি পিএইচপি-তে বাগ থাকা বাছাই বৈশিষ্ট্য সম্পর্কে দেওয়া পরামর্শের সমালোচনামূলক নোট নেব। আপনি বগী কোডটি ব্যবহার করতে চান না। আপনি যা চান তা হ'ল পিএইচপি নির্মাতারা হ'ল বাগটি ঠিক করার জন্য। যতক্ষণ না তারা না করে ততক্ষণ আপনি দৃsert়তাটি ব্যবহার করতে পারেন তবে এটি বর্তমান বগী অবস্থার প্রতি মনোযোগ দিয়ে ব্যবহার করতে পারেন।

তদুপরি, যদি দৃ feature় বৈশিষ্ট্যটি বগি হয় তবে আমি আপনাকে পরামর্শ দিচ্ছি যে আপনি এটি উত্পাদন কোডে ব্যবহার করবেন না। তবুও, আমি আপনাকে প্রস্তাব দিচ্ছি যে আপনি এটি উপযুক্ত এবং বিকাশকারী কোডের ক্ষেত্রে উপযুক্ত যেখানে ব্যবহার করুন।

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

তদুপরি — আমি দৃ highly়ভাবে পরামর্শ দিচ্ছি যে পিএইচপি নির্মাতারা চুক্তি করে নকশার একটি বিস্তৃত অধ্যয়ন করুন এবং পিএইচপি এটি ASAP এ রাখার চেষ্টা করুন! তারপরে আমরা সকলেই একটি ডিবিসি-সচেতন সংকলক / দোভাষা থাকা থেকে উপকৃত হতে পারি, যা উত্তরের (উপরে) বর্ণিত সমস্যাগুলি পরিচালনা করবে:

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

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

সুখী পড়াশোনা এবং শেখা।