ভেরিয়েবলগুলি যেখানে ব্যবহৃত হয় তার নিকটে কেন ঘোষণা করবেন?

Question

আমি লোকদের বলতে শুনেছি যে ভেরিয়েবলগুলি যতটা সম্ভব তার ব্যবহারের কাছাকাছি হিসাবে ঘোষণা করা উচিত। আমি এটা বুঝতে পারি না।

উদাহরণস্বরূপ, এই নীতিটি সুপারিশ করবে আমার এটি করা উচিত:

foreach (var item in veryLongList) {
  int whereShouldIBeDeclared = item.Id;
  //...
}

তবে অবশ্যই এর অর্থ এটি একটি নতুন তৈরির ওভারহেডগুলি intপ্রতিটি পুনরাবৃত্তির জন্য ব্যয় করা হয়। এটি ব্যবহার করা ভাল না:

int whereShouldIBeDeclared;
foreach (var item in veryLongList) {
  whereShouldIBeDeclared = item.Id;
  //...
}

কেউ দয়া করে ব্যাখ্যা করতে পারেন?

Comments

এটি একটি খুব জঘন্য দরিদ্র ভাষা হবে যে এই দুটি ক্ষেত্রে আলাদা আচরণ করেছিল।

— পল টমলিন

আপনি একটি মিথ্যা ভিত্তি থেকে শুরু। : দয়া করে এই প্রশ্নের আমার উত্তর দেখুন stackoverflow.com/questions/6919655/...

— CesarGon

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

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

— ডেভিড শোয়ার্জ

স্কেলের বিপরীত প্রান্তটি বিবেচনা করুন - সবকিছুই বৈশ্বিক পরিবর্তনশীল। অবশ্যই 'ঘোষিত কাছাকাছি ব্যবহার' এই বর্ণালীটির আরও ভাল সমাপ্তি?

— জেবিআরওয়িলকিনসন

Answer 1

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

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

if (flag) limit += factor;

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

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

Comments

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

— জেমস

কোন int তৈরির ওভারহেড ক্ষুদ্র। আপনি যদি জটিল কিছু নির্মাণ করছিলেন তবে ওভারহেডটি আরও বড় বিষয় হবে।

— কেট গ্রেগরি

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

— মাইক শেরিল 'ক্যাট রিক্যাল'

এই ক্ষেত্রে, প্রতিটি লুপ একটি নতুন উদাহরণ তৈরি করা হয় না । প্রতিটি পুনরাবৃত্তির জন্য একটি একক শীর্ষ-স্তরের ভেরিয়েবল তৈরি করা হয় এবং ব্যবহৃত হয় (আইএল দেখুন)। তবে এটি বাস্তবায়নের বিশদ।

— কোকুপ

"ভিজ্যুয়াল স্টুডিওতে, আপনি কোনও কিছুর উপর মাউস নিতে পারেন এবং দেখতে পারেন" ইত্যাদি etc. সংজ্ঞাতে নেভিগেটও রয়েছে, এর শর্টকাট রয়েছে F12যা অপরিহার্য।

— স্টুপারউসার

Answer 2

লুপের ভিতরে চলকটি সংজ্ঞায়িত করা কেবলমাত্র সেই লুপের কাছে দৃশ্যমানতাটিকে স্থানীয় করে তোলে। এতে পাঠকের পক্ষে কমপক্ষে 3 টি সুবিধা রয়েছে:

1. পরিবর্তনশীল সংজ্ঞা এবং যে কোনও সম্পর্কিত মন্তব্যগুলি খুঁজে পাওয়া সহজ
2. পাঠক জানেন যে এই পরিবর্তনশীলটি আর কখনও ব্যবহৃত হয় না যেখানে (আশা করার মতো নির্ভরতা নেই)
3. কোডটি যখন লিখিত বা সম্পাদিত হয় তখন লুপের বাইরে আপনি একই পরিবর্তনশীল নামটি ব্যবহার করতে পারেন এমন কোনও সম্ভাবনা নেই অন্যথায় আপনি ভেরিয়েবলটি উল্লেখ করতে পারেন, আপনি ভুল হতে পারেন।

দক্ষতা বিট হিসাবে, সংকলক উত্পন্ন অনুকূলিতকরণ কোড লুপ বাইরে সংজ্ঞা উত্পন্ন করতে স্মার্ট। পরিবর্তনশীল প্রতিটি লুপ পুনরাবৃত্তি তৈরি করা হবে না।

Answer 3

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

Answer 4

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

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

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

Answer 5

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

আপনার কেবল নিজের উপায়টি বেছে নিতে এবং এটি অনুসরণ করতে হবে।

Comments

এটা শুধু মতামত নয়, তাই না? সফটওয়্যার ইঞ্জিনিয়ারিং গবেষণা অন্তত 1980 এর দশক থেকে লাইভ সময় এবং বাগের সংখ্যার মধ্যে সম্পর্কের নথিভুক্ত করেনি?

— মাইক শেরিল 'ক্যাট রিক্যাল'

Answer 6

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