"যদি সম্ভব হয় তবে ভেরিয়েবলগুলি ক্ষুদ্রতম স্কোপে বাস করা উচিত" ক্ষেত্রে "যদি সম্ভব হয় তবে ভেরিয়েবলের অস্তিত্ব থাকা উচিত নয়" এই ক্ষেত্রে অন্তর্ভুক্ত রয়েছে?

Question

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

public class Main {
    private A a;
    private B b;

    public ABResult getResult() {
        getA();
        getB();
        return ABFactory.mix(a, b);
    }

    private getA() {
      a = SomeFactory.getA();
    }

    private getB() {
      b = SomeFactory.getB();
    }
}

এরকম কিছুতে:

public class Main {
    public ABResult getResult() {
        A a = getA();
        B b = getB();
        return ABFactory.mix(a, b);
    }

    private getA() {
      return SomeFactory.getA();
    }

    private getB() {
      return SomeFactory.getB();
    }
}

তবে "স্পিরিটি" এর "ভেরিয়েবলগুলি যথাসম্ভব ক্ষুদ্রতর স্কোপে বাস করা উচিত" অনুসারে, "ভেরিয়েবলগুলি কখনই থাকে না" "ভেরিয়েবলগুলি থাকা" এর চেয়ে কম স্কোপ থাকে না? সুতরাং আমি মনে করি উপরের সংস্করণটি রিফ্যাক্ট করা উচিত:

public class Main {
    public ABResult getResult() {
        return ABFactory.mix(getA(), getB());
    }

    private getA() {
      return SomeFactory.getA();
    }

    private getB() {
      return SomeFactory.getB();
    }
}

যাতে এর getResult()কোনও স্থানীয় ভেরিয়েবল নেই। এটা কি সত্যি?

Comments

সুস্পষ্ট ভেরিয়েবল তৈরি করা তাদের নাম রাখার সুবিধা নিয়ে আসে। কয়েকটি ভেরিয়েবলের পরিচিতি দ্রুত একটি অস্বচ্ছ পদ্ধতিটি পাঠযোগ্য একটিতে পরিণত করতে পারে।

— জারেড গোগুয়েন

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

— ডক ব্রাউন

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

— হাইড

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

— বার্গি

"ভেরিয়েবল সম্ভাব্যতম ক্ষুদ্রতম স্কোপে বাস করা উচিত" এর মতো কোড শৈলীর নিয়মের बिल्कुल শূন্যতা চিন্তাভাবনা ছাড়াই সর্বজনীনভাবে প্রযোজ্য। এই হিসাবে, আপনি কখনই এই প্রশ্নে ফর্মের যুক্তির ভিত্তিতে কোনও কোড শৈলীর সিদ্ধান্তের ভিত্তি রাখতে চান না, যেখানে আপনি একটি সাধারণ নির্দেশিকা গ্রহণ করেন এবং এটিকে কম-স্পষ্টভাবে আচ্ছাদিত অঞ্চলে প্রসারিত করেন ("যদি সম্ভব হয় তবে ভেরিয়েবলগুলির ছোট স্কোপ থাকতে হবে" -> "সম্ভব হলে ভেরিয়েবলের অস্তিত্ব থাকা উচিত নয়")। হয় বিশেষত আপনার উপসংহার সমর্থন করার ভাল কারণ আছে, বা আপনার উপসংহার একটি অনুচিত এক্সটেনশন; যে কোনও উপায়ে আপনার মূল নির্দেশিকাটির দরকার নেই।

— বেন

Answer 1

না। এর বেশ কয়েকটি কারণ রয়েছে:

1. অর্থপূর্ণ নাম সহ ভেরিয়েবলগুলি কোড বোঝা সহজ করে তুলতে পারে।
2. জটিল সূত্রগুলি ছোট ছোট পদক্ষেপে ভাঙ্গার ফলে কোডটি পড়া সহজ হয়ে যায়।
3. ক্যাশে।
4. অবজেক্টের রেফারেন্স ধরে রাখা যাতে সেগুলি একাধিকবার ব্যবহার করা যায়।

ইত্যাদি।

Comments

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

— পারে_ফ্যাক্টর

@ মায়াবে_ ফ্যাক্টর নির্দেশিকাটি কার্য সম্পাদনের কারণে আসলে নেই; কোড বজায় রাখা কতটা সহজ তা সম্পর্কে। তবে এর অর্থ এখনও পর্যন্ত অর্থপূর্ণ স্থানীয়রা এক বিশাল অভিব্যক্তির চেয়ে ভাল, যদি না আপনি সুনির্দিষ্টভাবে নামযুক্ত এবং নকশাযুক্ত ফাংশনগুলি রচনা করেন (যেমন: করার কোনও কারণ নেই var taxIndex = getTaxIndex();)।

— লুয়ান

সমস্ত গুরুত্বপূর্ণ বিষয়। আমি যেভাবে দেখি: ব্রেভিটি একটি লক্ষ্য; স্পষ্টতা অন্যটি; দৃust়তা আরেকটি; পারফরম্যান্স আরেকটি; ইত্যাদি। এগুলির কোনওটিই নিখুঁত লক্ষ্য নয় এবং কখনও কখনও এগুলির মধ্যে দ্বন্দ্ব হয়। সুতরাং আমাদের কাজ হ'ল কীভাবে সর্বোত্তম লক্ষ্যগুলিতে ভারসাম্য বজায় রাখা উচিত ।

— জিড

— সংকলকটি

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

— জিমি জেমস

Answer 2

সম্মত হন, ভেরিয়েবলগুলি যা প্রয়োজনীয় নয় এবং কোডের পাঠযোগ্যতার উন্নতি করে না তা এড়ানো উচিত। কোডের একটি নির্দিষ্ট বিন্দুতে যত বেশি ভেরিয়েবলের সুযোগ রয়েছে, কোডটি তত জটিল complex

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

এটি কার্যক্রমে যত দীর্ঘস্থায়ী হয় তত তত বেশি ভেরিয়েবলের সুযোগ হয় an

যেমন আপনি যদি

    a=getA();
    b=getB();
    m = ABFactory.mix(a,b);

বৃহত্তর ফাংশনের শীর্ষে, আপনি একের পরিবর্তে তিনটি ভেরিয়েবল প্রবর্তন করে বাকী কোডটি বোঝার মানসিক বোঝা বাড়িয়ে তোলেন। আপনি দেখতে হলে কোডের বাকি মাধ্যমে পড়তে আছে aবা bআবার ব্যবহার করা হয়। স্থানীয় যেগুলি স্কোপে দীর্ঘতর প্রয়োজন তাদের সামগ্রিক পাঠযোগ্যতার জন্য খারাপ।

কেস যেখানে একটি পরিবর্তনশীল প্রয়োজনীয় মধ্যে অবশ্যই (যেমন একটি অস্থায়ী ফলাফলের সঞ্চয় করতে) অথবা যেখানে একটি পরিবর্তনশীল করে কোড পাঠযোগ্যতা উন্নতি, তাহলে এটি রাখতে হবে।

Comments

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

— লুয়ান

"বহিরাগত" ভেরিয়েবলগুলির সুবিধাগুলির বিষয়ে var result = getResult(...); return result;আপনি হ'ল আপনি ব্রেক ব্রেকপয়েন্ট স্থাপন করতে পারেন returnএবং ঠিক resultকী তা শিখতে পারেন ।

— জোকার_ভিডি

@ জোকার_ভিডি: এর নামের যোগ্য কোনও ডিবাগার আপনাকে যে কোনও উপায়ে এটি করতে সক্ষম হতে হবে (কোনও ফাংশন কলের ফলাফল স্থানীয় ভেরিয়েবেলে সংরক্ষণ না করে + ফাংশন থেকে বেরিয়ে যাওয়ার ব্রেক ব্রেকপয়েন্ট সেট করে)।

— খ্রিস্টান হ্যাকেল

@ ক্রিশ্চিয়ানহ্যাকল খুব কম ডিবাগ্সার আপনাকে সম্ভবত এমন জটিল ঘড়িগুলি স্থাপন না করে যা যোগ করতে সময় লাগে (এবং যদি ফাংশনগুলির পার্শ্ব প্রতিক্রিয়া থাকে তবে সবকিছু ভেঙে যেতে পারে)। আমি সপ্তাহের যে কোনও দিন ডিবাগ করার জন্য ভেরিয়েবল সংস্করণটি নিয়ে যাব।

— গাবে সেকান

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

— গ্রেট হাঁস

Answer 3

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

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

আসুন আপনার প্রাথমিক getResultপদ্ধতিটি একবার দেখুন:

public ABResult getResult() {
    getA();
    getB();
    return ABFactory.mix(this.a, this.b);
}

এখন, নামগুলি getAএবং তারা প্রস্তাবিতgetB হতে পারে যে তারা এগুলি অর্পণ করবে this.aএবং this.b, কেবলমাত্র তাকানো থেকে আমরা নিশ্চিতভাবে জানতে পারি না getResult। সুতরাং, এটি সম্ভব যে পদ্ধতিতে যে মানগুলি this.aএবং this.bমানগুলি mixপরিবর্তিত হয়েছিল তার পরিবর্তে thisঅবজেক্টের অবস্থা থেকে আগত আগে getResultথেকেই অনুরোধ করা হয়েছিল, যা ক্লায়েন্টরা কখন এবং কীভাবে পদ্ধতিগুলি বলা হয় তা নিয়ন্ত্রণ করার কারণে এটি ভবিষ্যদ্বাণী করা অসম্ভব।

স্থানীয় aএবং bভেরিয়েবলগুলির সাথে সংশোধিত কোডে এটি স্পষ্ট যে এর ব্যবহারের প্রতিটি ভেরিয়েবলের অ্যাসাইনমেন্ট থেকে ঠিক একটি (ব্যতিক্রম-মুক্ত) নিয়ন্ত্রণ-প্রবাহ রয়েছে, কারণ ভেরিয়েবলগুলি ব্যবহারের আগেই ডিক্লেয়ার করা হয়।

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

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

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

Answer 4

এটি কিছুটা ভাষা-নির্ভর, তবে আমি বলব যে কার্যকরী প্রোগ্রামিংয়ের স্বল্প সুস্পষ্ট সুবিধাগুলির মধ্যে একটি হ'ল এটি প্রোগ্রামার এবং কোডের পাঠককে এগুলির প্রয়োজন না হওয়ার জন্য উত্সাহ দেয়। বিবেচনা:

(reduce (fn [map string] (assoc map string (inc (map string 0))) 

বা কিছু লিনকিউ:

var query2 = mydb.MyEntity.Select(x => x.SomeProp).AsEnumerable().Where(x => x == "Prop");

অথবা নোড.জেএস:

 return visionFetchLabels(storageUri)
    .then(any(isCat))
    .then(notifySlack(secrets.slackWebhook, `A cat was posted: ${storageUri}`))
    .then(logSuccess, logError)
    .then(callback)

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

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

এফ # এর পাইপ অপারেটর |>আংশিকভাবে কার্যকর কারণ এটি আপনাকে বাম থেকে ডান জিনিস লিখতে দেয় যা অন্যথায় ডান থেকে বাম হতে হয়।

Comments

আমি সাধারণ লিনকিউ এক্সপ্রেশন বা ল্যাম্বডাসে আমার পরিবর্তনশীল নাম হিসাবে আন্ডারস্কোর ব্যবহার করেছি। myCollection.Select(_ => _.SomeProp).Where(_ => _.Size > 4);

— গ্রাহাম

নিশ্চিত নয় যে এটি ওপির প্রশ্নের সামান্যতম উত্তর দিয়েছে ...

— এসি

ডাউনভোটস কেন? আমার কাছে ভাল উত্তর বলে মনে হচ্ছে, এমনকি যদি এটি সরাসরি প্রশ্নের উত্তর না দেয় তবে এটি এখনও কার্যকর তথ্য

— রেগেগুইটার

Answer 5

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

Comments

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

— সুপারক্যাট

Answer 6

ফাংশন ( পদ্ধতি ) বিবেচনা করুন । সেখানে এটি কোডটিকে ছোট ছোট সাবটাস্কে বিভক্ত করছে না, কোডের বৃহত্তম সিঙ্গলটনও নয়।

এটি ব্যবহারযোগ্য টুকরোগুলিতে সীমানা যুক্তিযুক্ত কাজগুলি সহ একটি স্থানান্তর সীমা।

একই ভেরিয়েবল জন্য । যৌক্তিক ডেটা স্ট্রাকচারকে বোঝা যায় এমন অংশগুলিতে নির্দেশ করা। অথবা কেবলমাত্র পরামিতিগুলির নামকরণ (স্ট্যাটিং) করুন:

boolean automatic = true;
importFile(file, automatic);

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

Answer 7

কোনও কারণের কারণ হিসাবে কিছুটা নিখোঁজ হ'ল ডিবাগিং / রিডাবিলিটি is কোডটির জন্য অনুকূলিত হওয়া উচিত, এবং পরিষ্কার এবং সংক্ষিপ্ত নামগুলি অনেকগুলি সহায়তা করে eg

if (frobnicate(x) && (get_age(x) > 2000 || calculate_duration(x) < 100 )

এই লাইনটি সংক্ষিপ্ত, তবে ইতিমধ্যে পড়া শক্ত। আরও কয়েকটি পরামিতি যুক্ত করুন এবং এটি যদি একাধিক লাইনের বিস্তার করে।

can_be_frobnicated = frobnicate(x)
is_short_lived_or_ancient = get_age(x) > 2000 || calculate_duration(x) < 100
if (can_be_frobnicated || is_short_lived_or_ancient )

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

আর একটি উদাহরণ আর এর মতো ভাষা হবে যেখানে শেষ লাইনটি স্বয়ংক্রিয়ভাবে ফেরতের মান হবে:

some_func <- function(x) {
    compute(x)
}

এটি বিপজ্জনক, রিটার্ন কি এক্সপ্লোসড বা প্রয়োজনীয়? এটি পরিষ্কার:

some_func <- function(x) {
   rv <- compute(x)
   return(rv)
}

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

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

Answer 8

কেবল আপনার শিরোনামের উল্লেখ: একেবারে, কোনও ভেরিয়েবল অপ্রয়োজনীয় হলে মুছে ফেলা উচিত।

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

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

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

কোড পঠনযোগ্যতা সঠিকভাবে কাজ করা বাদ দিয়ে সবকিছুকে ট্রাম্প করে (সঠিকভাবে গ্রহণযোগ্য পারফরম্যান্সের মানদণ্ড অন্তর্ভুক্ত করে, যা খুব কমই "যত দ্রুত সম্ভব")।