কোড ব্লক তৈরি করা কি খারাপ অভ্যাস?


12

সি ++ তে কি খারাপ অভ্যাসটি কিছু ফাংশনের ভিতরে কোডের ব্লক তৈরি করে যেমন:

    bool f()
    {
       {
           double test = 0;

           test = // some other variable outside this function, for example.

           if (test == // some value)
             return true;
       }

       {
           double test = 0;

           test = // some variable outside this function, different from the last one.

           if (test == // some value)
             return true;
       }

       return false;

    }

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

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


19
যদি আমি এই কোডটি প্রকাশ করছিলাম তবে আমি আপনাকে বলব যে এই পরীক্ষাগুলির প্রত্যেককে পৃথক পদ্ধতিতে আলাদা করতে হবে ... ফলস্বরূপ আপনার কোড ব্লকগুলি আলাদাভাবে ফাঁক করে দেওয়ার প্রয়োজন হবে না।
পারে_ফ্যাক্টর

1
@ মায়াবে_ফ্যাক্টর - আমি সম্মত পৃথক পদ্ধতির সুবিধা হ'ল আপনি আরও বেশি পঠনযোগ্য কোড সরবরাহ করে প্রতিটি ব্লকের নাম রাখতে পারেন।
mouviciel

@ মউভিচিয়েল কেবল বেশি পঠনযোগ্য কোড নয়, আরও পাঠযোগ্য পাঠ্য পরীক্ষার রিপোর্ট!
পারে_ফ্যাক্টর

@ মায়াবে_ফ্যাক্টর আমি একমত নই জিনিসগুলিকে পৃথক ফাংশনে স্থানান্তরিত করার ফলে এগুলি কার্যকারিতার সামান্য পুনরায় ব্যবহারযোগ্য বিটের মতো মনে হওয়ার নেতিবাচক প্রভাব ফেলে। ফাংশনের জন্য সমস্ত যুক্তি এক জায়গায় রাখা ভাল is
মাইলস রাউট

1
@ মাইলসআরট এটি একটি যৌক্তিক ফাংশন নয়, এটি একটি ফাংশনের জন্য একাধিক ইউনিট পরীক্ষা যা সমস্ত একক পরীক্ষার ক্রিয়াকলাপে সংযুক্ত। সাধারণ কোডগুলিতে কোড ব্লক বনাম ফাংশন সম্পূর্ণরূপে আরেকটি আলোচনা।
পারে_ ফ্যাক্টর

উত্তর:


22

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

তবে আপনি যদি যা করছেন তার কোনও নাম বাদ দেওয়া হয়, তবে আমি বলব যে এগুলি খারাপ অভ্যাস। সাধারণভাবে বলতে গেলে অবশ্যই; বিশেষ পরিস্থিতিতে প্রয়োগ করতে পারেন।

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

যদি কোনও মানুষের কোড লেখা থাকে যেখানে তাদের একই ফাংশনের মধ্যে নামগুলি পুনরায় ব্যবহার করতে হবে, আমি বলব যে blocks ব্লকগুলি সম্ভবত পৃথক ফাংশন হওয়া দরকার। বিশেষত যদি সেই সমস্ত ব্লকগুলির মধ্যে এই নামগুলি বিভিন্ন ধরণের এবং / বা অর্থ সহ ব্যবহার করা হয়।


10

এটির মতো ব্লক তৈরি করা খারাপ অভ্যাস নয়। এটি স্কোপগুলি কীভাবে কাজ করে।

সাধারণত এটি RAII (রিসোর্স অ্যাকুইজিশন ইনিশিয়ালাইজেশন) ব্যবহার করার সময় করা হয় এবং ধ্বংসকারীদের ডেকে এলে আপনি নিয়ন্ত্রণ করতে চান।

যদি এটি দীর্ঘ হয়ে যায়, আমি সেই কোডটিকে তার নিজের ফাংশনে সরিয়ে নেওয়ার বিষয়টি বিবেচনা করব।

আমার মতে এটি পরিবর্তনশীল নামের পুনর্ব্যবহার করার জন্য এটি ব্যবহার করা ভাল ধারণা নয়। তবে আমি দেখতে পাচ্ছি এটি কম স্মৃতিশক্তির ক্ষেত্রে কার্যকর ছিল


স্থানীয় ভেরিয়েবল নামের পুনরায় ব্যবহারের স্মৃতি ব্যবহারে কোনও প্রভাব নেই।
কেভিন cline

1
আপনি কি মনে করেন না যে কোনও স্মার্ট অপ্টিমাইজার 2 ভেরিয়েবলের জন্য 1 মেমরি অবস্থান ব্যবহার করতে পারে?
রবার্ট আন্দ্রেজেজুক

3
হ্যাঁ. তবে তারা এটি করতে পারে যদি তারা একই স্কোপে থাকে তবে তাদের যদি ডেস্ট্রাক্টর না থাকে।
সেবাস্তিয়ান রেডল
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.