কেন ফাংশন নামগুলিতে যুক্তিগুলির নামগুলি এনকোডিং করা বেশি সাধারণ হয় না? [বন্ধ]

Question

ইন ক্লিন কোড লেখক একটি উদাহরণ দেয়

assertExpectedEqualsActual(expected, actual)

বনাম

assertEquals(expected, actual)

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

Comments

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

— ইউফোরিক

অনেক লোক প্রথম নামকরণের স্কিমের বিরুদ্ধে তর্ক করবে কারণ এটি অত্যধিক ভার্জোজ , এটি যেখানে স্পষ্টতা দেয় তাতে অনেক দূরে। বিশেষত assertEquals(), কোডটি বেসে এই পদ্ধতিটি কয়েকবার ব্যবহৃত হয় যাতে এটি আশা করা যায় যে পাঠকরা একবার কনভেনশনটির সাথে পরিচিত হন। বিভিন্ন ফ্রেমওয়ার্কগুলির বিভিন্ন কনভেনশন রয়েছে (যেমন (actual, expected) or an agnostic (বাম, ডান) `), তবে আমার অভিজ্ঞতায় এটি বেশিরভাগ বিভ্রান্তির একটি উত্স source

— সোমবার

কারণ লাভ এটির সামান্য, এর সুবিধার তুলনায়, যে কোনও বুদ্ধিমান সম্ভবত দূরে চলে যেতে পারে। আপনি যদি আরও সাবলীল পদ্ধতির চান তবে আপনার চেষ্টা করা উচিত assert(a).toEqual(b)(আইএমও এমনকি এটি অযথাই ভার্বোস হলেও) যেখানে আপনি কয়েকটি সম্পর্কিত বক্তব্যকে শৃঙ্খলাবদ্ধ করতে পারেন।

— অ্যাড্রিয়ানো রেপিটি

আমরা কীভাবে জানি যে প্রকৃত এবং প্রত্যাশিত মান হয়? নিশ্চয়ই তা হওয়া উচিত assertExpectedValueEqualsActualValue? তবে অপেক্ষা করুন, কিভাবে আমরা মনে কিনা এটি ব্যবহার করে না ==বা .equalsবা Object.equals? এটা করা উচিত assertExpectedValueEqualsMethodReturnsTrueWithActualValueParameter?

— ব্যবহারকারী 253751

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

— স্টিভেন র‌্যান্ডস

Answer 1

কারণ এটি টাইপ করা আরও বেশি এবং আরও পড়তে হয়

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

অনেক বিকাশকারী আইডিই ব্যবহার করেন

আইডিইগুলি প্রায়শই ঘোরাফেরা বা কীবোর্ড শর্টকাটের মাধ্যমে একটি প্রদত্ত পদ্ধতির জন্য ডকুমেন্টেশন দেখার ব্যবস্থা দেয়। এ কারণে, পরামিতিগুলির নাম সর্বদা হাতে থাকে।

যুক্তিগুলি এনকোডিং দ্বারা সদৃশ এবং সংযুক্তির পরিচয় দেওয়া হয়

প্যারামিটারগুলির নামগুলি ইতিমধ্যে সেগুলি নথিভুক্ত করা উচিত। পদ্ধতির নামে নামগুলি লিখে, আমরা সেই পদ্ধতিটিও পদ্ধতিটির স্বাক্ষরে নকল করছি। আমরা পদ্ধতির নাম এবং পরামিতিগুলির মধ্যে একটি সংযোগ তৈরি করি। আমাদের ব্যবহারকারীদের বলুন expectedএবং actualবিভ্রান্ত করছেন। থেকে যাওয়া assertEquals(expected, actual)থেকে assertEquals(planned, real)ফাংশন ব্যবহার করে ক্লায়েন্ট কোড পরিবর্তন প্রয়োজন হয় না। থেকে যাওয়া assertExpectedEqualsActual(expected, actual)থেকে assertPlannedEqualsReal(planned, real)মানে এপিআই করার জন্য একটি ভঙ্গ পরিবর্তন। অথবা আমরা পদ্ধতির নাম পরিবর্তন করি না, যা দ্রুত বিভ্রান্ত হয়ে যায়।

অস্পষ্ট যুক্তিগুলির পরিবর্তে প্রকারগুলি ব্যবহার করুন

আসল সমস্যাটি হ'ল আমাদের দ্ব্যর্থক যুক্তি রয়েছে যা সহজেই স্যুইচ করা হয় কারণ তারা একই ধরণের। পরিবর্তে সঠিক অর্ডার প্রয়োগের জন্য আমরা আমাদের প্রকারের সিস্টেম এবং আমাদের সংকলকটি ব্যবহার করতে পারি:

class Expected<T> {
    private T value;
    Expected(T value) { this.value = value; }
    static Expected<T> is(T value) { return new Expected<T>(value); }
}

class Actual<T> {
    private T value;
    Actual(T value) { this.value = value; }
    static Actual<T> is(T value) { return new Actual<T>(value); }
}

static assertEquals(Expected<T> expected, Actual<T> actual) { /* ... */ }

// How it is used
assertEquals(Expected.is(10), Actual.is(x));

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

Comments

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

— পিটার - মনিকা

যদি আপনি assertExpectedEqualsActual" আপত্তি জানায় যে এটি টাইপ করা বেশি এবং আরও পড়তে হয়" তবে আপনি কীভাবে উকিল করতে পারেন assertEquals(Expected.is(10), Actual.is(x))?

— রুখ

@ruakh এটি তুলনামূলক নয়। assertExpectedEqualsActualতবুও প্রোগ্রামারকে সঠিক ক্রমে যুক্তিগুলি নির্দিষ্ট করার জন্য যত্ন নেওয়া প্রয়োজন। assertEquals(Expected<T> expected, Actual<T> actual)স্বাক্ষর সঠিক ব্যবহার, যা একটি সম্পূর্ণরূপে পৃথক পন্থা জোরদার করা কম্পাইলার ব্যবহার করে। আপনি সংক্ষিপ্তসার জন্য এই পদ্ধতির অনুকূল করতে পারেন, উদাহরণস্বরূপ expect(10).equalsActual(x), কিন্তু এটি প্রশ্ন ছিল না ...

— হোলার

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

— ক্রিস্টিয়ান এইচ

বিশেষত সদৃশ ও সংযুক্তকরণের অংশটি নিয়ে আরও একমত হতে পারে না ... প্রতিবার যদি কোনও ফাংশন প্যারামিটারটির নাম পরিবর্তন করে তবে ফাংশনের নামটিও পরিবর্তন করতে হবে, আপনাকে সেই ফাংশনের সমস্ত ব্যবহার ট্র্যাক করতে হবে এবং তাদেরও পরিবর্তন করুন ... এটি আমার, আমার দল এবং অন্যদের জন্য আমাদের

— কোডকে

Answer 2

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

ভার্বোসিটি সবসময় আরও স্পষ্টতা বোঝায় না। বিবেচনা

copyFromSourceStreamToDestinationStreamWithoutBlocking(fileStreamFromChoosePreferredOutputDialog, heuristicallyDecidedSourceFileHandle)

বনাম

copy(output, source)

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

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

আপনি অ্যাপল দ্বারা জনপ্রিয় কয়েকটি ভাষায় আগ্রহী হতে পারেন। উদ্দেশ্য সি-তে ফাংশনের স্বাক্ষরের অংশ হিসাবে যুক্তির নামগুলি অন্তর্ভুক্ত করা হয় (ফাংশনটি [atm withdrawFundsFrom: account usingPin: userProvidedPin]ডকুমেন্টেশনে লিখিত হয় is withdrawFundsFrom:usingPin:এটি ফাংশনের নাম)। সুইফট অনুরূপ সিদ্ধান্ত নিয়েছে, আপনাকে ফাংশন কলগুলিতে যুক্তির নামগুলি রাখার প্রয়োজন হয় ( greet(person: "Bob", day: "Tuesday"))।

Comments

অন্য সমস্ত বিষয় একদিকে রেখে, লেখা থাকলে এটি পড়া আরও সহজ হবে । দেখুন কত সহজ ?! কারণ হুনুঙ্গসুনব্রোকেরওয়ার্ডসালাদের মাঝামাঝি সময়ে ছোট ছোট পরিবর্তনগুলি মিস করা খুব সহজ এবং শব্দটির সীমানা কোথায় তা নির্ধারণ করতে বেশি সময় লাগে। বিস্ফোরণ বিভ্রান্ত। copyFromSourceStreamToDestinationStreamWithoutBlocking(fileStreamFromChoosePreferredOutputDialog, heuristicallyDecidedSourceFileHandle)copy_from_source_stream_to_destination_stream_without_blocking(file_stream_from_choose_preferred_output_dialog, heuristically_decided_source_file_handle)

— tchrist

withdrawFundsFrom: account usingPin: userProvidedPinআপত্তি -সি সিনট্যাক্সটি আসলে ছোট্ট টালকের কাছ থেকে নেওয়া হয়েছে।

— joH1

@ ক্রিশ্চর পবিত্র যুদ্ধের সাথে জড়িত বিষয়গুলিতে আপনি সঠিক কিনা তা নিশ্চিত হওয়ার বিষয়ে সতর্ক হন। অন্য দিকটি সবসময় ভুল হয় না।

— কর্ট অ্যাম্মন

@ ক্রিশ্চর Addingunderscoresnakesthingseasiertoreadnotharderasyouseeযুক্তিটি পরিচালনা করছে। এখানে উত্তরটি মূলধন ব্যবহার করেছে, যা আপনি বাদ দিচ্ছেন। AddingCapitalizationMakesThingsEasyEnoughToReadAsYouCanSeeHere। দ্বিতীয়ত, 10 টির মধ্যে 9 বার কোনও নাম কখনই বাড়বে না [verb][adjective][noun](যেখানে প্রতিটি ব্লকটি block ReadSimpleName

— চ্ছিক

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

— জুলে

Answer 3

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

তিনি ঠিক বলেছেন assertEquals(এক্স ইউনাইট স্টাইল ইউনিট পরীক্ষার পাঠাগারগুলি থেকে) এটি পরিষ্কার করে না যে কোন যুক্তিটি প্রত্যাশিত এবং কোনটি আসল। এও আমাকে বিট দিয়েছে! অনেক ইউনিট পরীক্ষা গ্রন্থাগারগুলি বিষয়টি নোট করেছে এবং বিকল্প সিনট্যাক্সগুলি চালু করেছে, যেমন:

actual.Should().Be(expected);

অথবা সাদৃশ্যপূর্ণ. যা অবশ্যই অনেক বেশি পরিষ্কার assertEqualsতবে এটির চেয়েও অনেক ভাল assertExpectedEqualsActual। এবং এটি আরও অনেক বেশি কম্পোজেবল।

Comments

আমি মলদ্বার এবং আমি প্রস্তাবিত আদেশটি অনুসরণ করি তবে আমার কাছে মনে হয় যে যদি আমি ফলাফলটি fun(x)5 হওয়ার আশা করি তবে আদেশটি বিপরীত হলে কী ভুল হতে পারে - assert(fun(x), 5)? কীভাবে তোমাকে কামড় দিয়েছে?

— এমোরি

@emory আমি জানি jUnit (অন্তত) এর মান থেকে একটি thourough ত্রুটি বার্তা তৈরী করে expectedএবং actual, তাই তাদের reversing একটি বার্তা সঠিক নয় স্থাপিত হতে পারে। তবে আমি একমত যে এটি আরও প্রাকৃতিক বলে মনে হচ্ছে :)

— joH1

@ joH1 এটি আমার কাছে দুর্বল বলে মনে হচ্ছে। ব্যর্থ কোড ব্যর্থ হবে এবং পাসিং কোড আপনি করবেন assert(expected, observed)বা না করে পাস করবে assert(observed, expected)। এর থেকে আরও ভাল উদাহরণ হ'ল কিছু locateLatitudeLongitude- যদি আপনি স্থানাঙ্কগুলি উল্টে দেন তবে এটি গুরুতরভাবে বিশৃঙ্খলা করবে।

— এমরি

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

— ভু

@ স্মৃতি: যুক্তিটি উল্টানো ত্রুটি বার্তাগুলিকে বিভ্রান্তিমূলক করে তুলবে এবং ডিবাগ করার সময় আপনাকে ভুল পথে নামিয়ে দেবে।

— জ্যাকবিবি

Answer 4

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

সুতরাং, আমাদের যে ইন্টারফেসটি আপনি মূল্যায়ন করতে চান তা আমাদের দেখতে হবে, ডিবাগ-অ্যাসেসরেন্স করার একটি উপায় যে দুটি বস্তু সমান।

1. এটিতে আরটি এবং নাম বিবেচনা করা যেতে পারে যে অন্য কোন ফাংশন আছে?
   না, তাই নামটি যথেষ্ট পরিমাণে পরিষ্কার।
2. কোন তাত্পর্য ধরনের?
   না, তাই তাদের এড়ানো যাক। আপনি কি ইতিমধ্যে এটি করেছেন? ভাল.
3. এটি কি তার যুক্তিতে প্রতিসাম্য?
   প্রায় ত্রুটিযুক্তভাবে, বার্তাটি প্রতিটি যুক্তি উপস্থাপনকে তাদের নিজস্ব জায়গায় ফেলে দেয়।

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

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

আর্গুমেন্ট অর্ডার কনভেনশন অনুসরণ করে?
কেস মনে হয়। যদিও এটি সেরাভাবে একটি দুর্বল সম্মেলন বলে মনে হচ্ছে।

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

Comments

ভাল অর্ডার jUnit, যার মান থেকে একটি নির্দিষ্ট ত্রুটি বার্তা তৈরী করে সঙ্গে বিষয়টি পারে expectedএবং actual(অন্তত স্ট্রিংস সঙ্গে)

— joH1

আমি মনে করি আমি সেই অংশটি covered

— েকে

আপনি এটি উল্লেখ করেছেন তবে বিবেচনা করুন: assertEquals("foo", "doo")ত্রুটি বার্তাটি দেয় ComparisonFailure: expected:<[f]oo> but was:<[d]oo>... মানগুলি অদলবদল করা বার্তার অর্থকে উল্টে দেয় যা আমার কাছে আরও বিরোধী প্রতিসাম্যযুক্ত বলে মনে হয়। যাইহোক আপনি যেমন বলেছেন যে কোনও দেবতার ত্রুটিটি সমাধান করার জন্য অন্যান্য সূচক রয়েছে তবে এটি আইএমএইচওকে বিভ্রান্ত করতে পারে এবং আরও ডিবাগিং সময় নিতে পারে।

— joH1

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

— ভু

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

— 13:30 এ এডিপুলিকেটর

Answer 5

প্রায়শই এটি কোনও যৌক্তিক স্পষ্টতা যোগ করে না।

"অ্যাড ফার্স্টআরগমেন্টমেন্টসোসেকেন্ডআরগমেন্ট" এর সাথে "যোগ করুন" এর তুলনা করুন।

যদি আপনার একটি ওভারলোডের প্রয়োজন হয় তবে বলুন, তিনটি মান যুক্ত করুন। কী আরও বোধগম্য হবে?

তিনটি যুক্তি সহ আরও একটি "যুক্ত"?

অথবা

"AddFirstAndSecondAndThirdArgument"?

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

Comments

Addএকটি ভ্রমণমূলক ক্রিয়াকলাপের পরামর্শ দেয়। অর্ডার যে পরিস্থিতিগুলি বিবেচনা করে সেখানে ওপি সম্পর্কিত।

— রোজি এফ

সুইফ্টে আপনি উদাহরণস্বরূপ কল (5, থেকে: x) বা যুক্ত করুন (5, আরও: 7, থেকে: x) বা যুক্ত করুন (5, আরও: 7, প্রদান: এক্স) আপনি যদি অ্যাড () ফাংশনটি সংজ্ঞায়িত করেন সেই অনুযায়ী।

— gnasher729

তৃতীয়

— ওভারলোডটির

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

— মার্টিন মাট

@ মার্টিন অপেক্ষা কি? sumপুরোপুরি ক্রমুল্যান্ট ক্রিয়া । "সমষ্টিটি" বাক্যাংশে এটি বিশেষত প্রচলিত।

— ভু

Answer 6

আমি অন্যান্য উত্তর দ্বারা ইঙ্গিতযুক্ত অন্য কিছু যুক্ত করতে চাই, তবে আমার মনে হয় না যে এটি স্পষ্টভাবে উল্লেখ করা হয়েছে:

@ পাক বলেন, "ফাংশন নামে প্রথম উল্লিখিত যুক্তিটি সত্যই প্রথম প্যারামিটারের নিশ্চয়তা নেই।"

@cbojar বলেছেন "অস্পষ্ট যুক্তির পরিবর্তে প্রকারগুলি ব্যবহার করুন"

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

assertExpectedEqualsActual(foo, bar)কিছু বিকল্পের সাথে (এই পৃষ্ঠা থেকে এবং অন্য কোথাও) তুলনা করুন , যেমন:

# Putting the arguments in a labelled structure
assertEquals({expected: foo, actual: bar})

# Using a keyword arguments language feature
assertEquals(expected=foo, actual=bar)

# Giving the arguments different types, forcing us to wrap them
assertEquals(Expected(foo), Actual(bar))

# Breaking the symmetry and attaching the code to one of the arguments
bar.Should().Be(foo)

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

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

এই জাতীয় কলটি assertEqual(expected, actual)যতটা বোঝায় ততই assertEqual(actual, expected)সেগুলিকে মিশ্রিত করা এবং মেশিনটির সামনে লাঙল দেওয়া এবং ভুল কাজটি করা আমাদের পক্ষে সহজ। তাহলে আমরা ব্যবহৃত assertExpectedEqualsActualপরিবর্তে, এটা করা হতে পারে আমাদের ভুল করা সম্ভাবনা কম, কিন্তু এটা মেশিনে আর তথ্য (ইংরেজি বুঝতে পারছি না, ও নাম পছন্দমত শব্দার্থবিদ্যা প্রভাবিত হওয়া উচিত নয়) দেয়।

কী কী "কাঠামোগত" পদ্ধতির কাছে আরও বেশি পছন্দনীয় করে তোলে যেমন কীওয়ার্ড আর্গুমেন্ট, লেবেলযুক্ত ক্ষেত্র, স্বতন্ত্র প্রকার ইত্যাদি etc. অতিরিক্ত তথ্যও মেশিন পঠনযোগ্য , তাই আমাদের কাছে মেশিন স্পটটি ভুল ব্যবহার হতে পারে এবং আমাদের জিনিসগুলি সঠিকভাবে করতে সহায়তা করতে পারে। assertEqualকেস যেহেতু একমাত্র সমস্যা বেঠিক বার্তা হবে, খুব খারাপ নয়। আরও দুষ্টু উদাহরণ হতে পারে String replace(String old, String new, String content), যা বিভ্রান্ত করা সহজ যার সাথে String replace(String content, String old, String new)খুব আলাদা অর্থ রয়েছে। একটি সহজ প্রতিকার হ'ল একটি জোড়া নেওয়া [old, new], যা ভুলগুলি তত্ক্ষণাত ত্রুটি ঘটায় (এমনকি কোনও প্রকারভেদ ছাড়াই) without

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

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

Answer 7

কারণ এটি আর্গুমেন্টগুলি কোথায় যায় তা মনে রাখার প্রয়োজনীয়তা সরিয়ে দেয়

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

আপনি যদি কোডটি পড়ে থাকেন তবে আপনার সহজেই দেখা উচিত যে প্যারামিটারগুলির নাম অনুসারে যখন নামকরণ করা হয় তখন কী হয়। copy(source, destination)বোঝার মতো সোয়ামিংয়ের চেয়ে বোঝা অনেক সহজ copyFromTheFirstLocationToTheSecondLocation(placeA, placeB)।

কোডাররা পূর্বেরটিকে কেন গ্রহণ করবেন না, যেমনটি লেখক দৃser়ভাবে দাবি করেছেন, পরবর্তীকালের চেয়ে পরিষ্কার?

কারণ বিভিন্ন শৈলীতে বিভিন্ন দৃষ্টিকোণ রয়েছে এবং আপনি অন্য নিবন্ধের x লেখক খুঁজে পেতে পারেন যা বিপরীতভাবে উল্লেখ করে। আপনি যে কেউ লিখেছেন সবকিছু অনুসরণ করার চেষ্টা করে পাগল হয়ে যাবেন ;-)

Answer 8

আমি সম্মত যে ফাংশন নামের মধ্যে প্যারামিটার নামগুলি এনকোডিং ফাংশনগুলি আরও স্বজ্ঞাত করে তোলে।

copyFromSourceToDestination( // "...ahh yes, the source directory goes first"

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

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

copy(sourceDir, destinationDir); // "...makes sense"

এর প্রচ্ছন্নতা বেশিরভাগ প্রোগ্রামারদের উপর বিজয়ী হবে এবং আমি ব্যক্তিগতভাবে এটি পড়া সহজ করে পাই।

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

Comments

সুতরাং যদি আমি এক মিনিটের জন্য শয়তানের উকিল খেলতে পারি: আপনি কেবলমাত্র ফাংশনটির পুরো নামটি জানলেই এটি স্বজ্ঞাত। আপনি কি জানেন যদি একটি কপি ফাংশন এবং আপনি মনে করতে পারছি না কিনা এটা copyFromSourceToDestinationবা copyToDestinationFromSource, আপনার পছন্দ শুদ্ধাশুদ্ধি দ্বারা এটি খুঁজে পেতে হয় বা রেফারেন্স উপাদান পড়া চালিয়ে যান। আংশিক নামগুলি সম্পূর্ণ করতে পারে এমন আইডিই হ'ল পরবর্তীগুলির কেবল একটি স্বয়ংক্রিয় সংস্করণ।

— ব্লারফ্ল

@ ব্লাফ্লএল এটির কল করার copyFromSourceToDestinationমূল বিষয়টি হ'ল যদি আপনি এটি মনে করেন copyToDestinationFromSource, সংকলকটি আপনার বাগটি খুঁজে পাবে, কিন্তু যদি এটি ডাকা হয় copy, তা হবে না। একটি অনুলিপি-রুটিনের প্যারামগুলি ভুল উপায়ে পাওয়া সহজ, যেহেতু আরআরসিপিপি, আরআরসিকেট ইত্যাদি একটি নজির সেট করে। এবং বৃষ্টি পড়া কি আরও সহজ? মার্জলিস্টগুলি (listA, listB, listC) তালিকা বি এবং তালিকা সি থেকে তালিকা তৈরি করে, বা তালিকা পড়া ও তালিকাবি পড়া এবং তালিকা সি লিখবে?

— রোজি এফ

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

— blrfl

ওটিওএইচ, গন্তব্যডিরকোপি (উত্সডির); // "... আরও অর্থবোধ করে"

— ক্রিশ্চিয়ান এইচ

@ ক্রিশ্চিয়ানএইচ কোন দিকটি dir1.copy(dir2)কাজ করে? কোন ধারণা নেই. কি হবে dir1.copyTo(dir2)?

— মার্টিনাস