কেন সি # তে অব্যবহৃত নির্দেশাবলী অপসারণ করবেন?

Question

আমি ভাবছি যে কোনও কারণ রয়েছে (উত্স কোডটি পরিষ্কার করার ব্যতীত) কেন বিকাশকারীরা Usingsভিজুয়াল স্টুডিও ২০০৮-এ " অব্যবহৃত অপসারণ " বৈশিষ্ট্যটি ব্যবহার করবেন ?

Comments

আমি বিশ্বাস করি যে এটি ভিজ্যুয়াল স্টুডিওর নয়, ভিজ্যুয়াল স্টুডিওর জন্য পাওয়ার কম্যান্ডগুলির একটি বৈশিষ্ট্য।

— হোসাম অলি

ভিএস ২০০৮-এ এটি অবশ্যই ভিএসের নিজস্ব বৈশিষ্ট্য (ব্যবহারের বিবৃতিগুলি বাছাই করার ক্ষমতা সহ)।

— রিচার্ড

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

— কনফিগার

বিটিডাব্লু, আপনি যদি এই ধরণের ক্লিনআপের উপর আরও সুনির্দিষ্ট নিয়ন্ত্রণ চান তবে পুনরায় ভাগ করুন check

— জন Feminella

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

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

Answer 1

কয়েকটি কারণ রয়েছে যা আপনি এগুলি নিতে চান।

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

অন্যদিকে, এগুলি ছেড়ে দেওয়ার অনেক কারণ নেই I আমি মনে করি আপনি সেগুলি মুছে ফেলার চেষ্টাটি আপনি নিজেকে বাঁচান। তবে আপনি যদি অলস হন তবে আপনার আরও বড় সমস্যা হয়েছে!

Comments

একজন ভাল প্রোগ্রামার অলস, তিনি কাজটি না করে সর্বাধিক করে তোলেন। : ডি

— নিকোলাস ডরিয়ার

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

— অ্যালান

ঠিক আছে, এটি একটি দুর্দান্ত লিঙ্ক। আমার ধারণা আমার বক্তব্যটি কেবল এটি ছিল যে আমরা "খারাপ অলস" না হয়ে "ভাল অলস" চাই; পরবর্তীকালে যেখানে প্রোগ্রামাররা ভাল কোড লেখার জন্য বিরক্ত হতে পারে না।

— অ্যালান

স্ট্যান্ডার্ড নেমস্পেসগুলি পাশাপাশি রেখে যাওয়ার যোগ্যতাও রয়েছে। বৃহত প্রকল্প এবং দলগুলিতে, এগুলি ফলাফলগুলিতে কম সম্ভাব্য সংযুক্তির দ্বন্দ্ব এবং কোড পর্যালোচনার জন্য কম ফাইলগুলিতে ফেলে। অতিরিক্তভাবে বিকাশকারীরা প্রচুর বিভ্রান্তিকর এবং জিনিসগুলিতে এক্সটেনশান পদ্ধতিগুলি খুঁজে পাওয়া শক্ত করে এবং কখনও কখনও এই এক্সটেনশান পদ্ধতির জন্য প্রয়োজনীয় নেমস্পেসগুলি সন্ধান করা একটি ঝামেলা হয়। নতুন বিকাশকারীরা তাদের কোড ফাইলগুলিতে System.Linq অন্তর্ভুক্ত থাকার অভ্যস্ত হতে পারে এবং সাহায্যের জন্য জিজ্ঞাসার আগে কেন কিছু পদ্ধতি উপলব্ধ না তা নির্ধারণ করার জন্য প্রচুর সময় নষ্ট করে।

— র‌্যাম্প 51

ভবিষ্যতের কোডিংয়ে ইন্টেলিসেন্সকে নরক হিসাবে বোবা হতে রোধ করতে আপনি তাদের কিছু রাখতে চান।

— yazanpro

Answer 2

আমি একেবারে বিপরীতভাবে বলব - এটি বিনা পাকা, অপ্রয়োজনীয় বিবৃতি ব্যবহার করে অপসারণ করতে অত্যন্ত সহায়ক।

কল্পনা করুন যে আপনাকে 3, 6, 9 মাসে আপনার কোডে ফিরে যেতে হবে - বা অন্য কাউকে আপনার কোডটি হাতে নিতে হবে এবং এটি বজায় রাখতে হবে।

আপনার যদি বিবৃতি ব্যবহারের একটি বিশাল দীর্ঘ লন্ড্রি তালিকা থাকে যা সত্যই প্রয়োজন হয় না, কোডটি দেখানো বেশ বিভ্রান্তিকর হতে পারে। কেন সেখানে ব্যবহার হচ্ছে, যদি সেই নামস্থান থেকে কিছু ব্যবহার করা হয় না ??

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

আঙ্গুরের ছিরড়া

Answer 3

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

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

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

আমরা একটি স্বয়ংক্রিয় বিল্ড প্রক্রিয়া ব্যবহার করি এবং সুতরাং আমাদের এসভিএন সংগ্রহস্থলটিতে যে কোনও পরিবর্তন ঘটে যা আমরা প্রকল্প / বাগ / ইস্যুগুলির সাথে লিঙ্ক করতে পারি না এমন পরিবর্তনগুলি উত্পন্ন করে এবং স্বয়ংক্রিয় বিল্ড এবং রিলিজগুলি ট্রিগার করে যা পূর্ববর্তী সংস্করণগুলিতে কোনও কার্যকরী পরিবর্তন দেয় না।

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

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

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

Comments

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

— ডেভিড রেইস

Answer 4

ইতিমধ্যে প্রদত্ত কারণগুলি ছাড়াও এটি অপ্রয়োজনীয় নামকরণ বিরোধকে বাধা দেয়। এই ফাইলটি বিবেচনা করুন:

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

এই কোডটি সংকলন করে না কারণ নেমস্পেসিগুলি উভয়ই System.IO এবং System.Windows.Saps প্রত্যেককেই পথ নামে একটি বর্গ থাকে। আমরা পূর্ণ শ্রেণীর পথ ব্যবহার করে এটি ঠিক করতে পারতাম,

        private static string temporaryPath = System.IO.Path.GetTempFileName();

অথবা আমরা কেবল লাইনটি সরাতে পারি using System.Windows.Shapes;।

Answer 5

ইন্টেলিসেন্স পপআপে কম বিকল্প (বিশেষত যদি নেমস্পেসে প্রচুর পরিমাণে এক্সটেনশন পদ্ধতি থাকে)।

তাত্ত্বিকভাবে ইনটেলিসেন্সও দ্রুত হওয়া উচিত।

Comments

ইন্টেলিজেন্সের জন্য +1। এটি শুরুতে আসলে ধীর হয় (আমি নিয়মিত "বিল্ডিং ক্যাশে দেখি, পরে আবার চেষ্টা করুন"), এটি সম্ভবত তাৎপর্যপূর্ণ হতে পারে। যে সময়টির বিষয়ে সবাই প্রত্যেকে কথা বলবে তা সঙ্কলন করুন ... আমি এখনও সংখ্যা দেখতে পাইনি।

— লুক

Answer 6

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

Answer 7

এটি মিথ্যা বিজ্ঞপ্তি নির্ভরতা রোধ করতেও সহায়তা করে, ধরে নিই আপনি অব্যবহৃত ব্যবহারগুলি অপসারণের পরে আপনার প্রকল্প থেকে কিছু dll / প্রকল্পের রেফারেন্সগুলি সরাতে সক্ষম হবেন।

Answer 8

কোডটি দ্রুত সংকলন করে।

Comments

এই ব্যাক আপ কোন প্রমাণ আছে?

— সিজেকে 13

ওহ সি কে - আপনি আমাকে আবার ধরে ফেললেন। আমি মিথ্যে বলেছি. অপ্রয়োজনীয় পাঠ্য অপসারণ আসলে কোড সংকলনটিকে আরও ধীর করে তোলে। এটি সম্পর্কে চিন্তা করুন :)

— ডেড অ্যাকাউন্ট

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

— কনফিগার

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

— গ্রেগ

এটা মিথ্যা বা না মিথ্যা সম্পর্কে নয়। যে কোনও বুদ্ধিমান লোক অনুমান করবে যে কম বিশৃঙ্খলা মানেই বেশি দক্ষতা। এটির ব্যাক আপ করার "প্রমাণ" হ'ল আপনার প্রতিক্রিয়াটির মূল্য প্রদান করা এবং এই যুক্তিটি সমর্থন করা যে "দ্রুত" বলতে কেবল কয়েকটি এমএস বোঝায় না, তবে আপনার প্রকল্পটি দ্রুত সংকলনের জন্য একটি উন্নত অভিজ্ঞতা।

— ম্যাথিউস ফিলিপ

Answer 9

অব্যবহৃত আমদানি মোছা কেন বেশ সহায়ক এবং গুরুত্বপূর্ণ তা সম্প্রতি আমি অন্য একটি কারণ পেয়েছি।

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

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

অবশেষে আমাদের এক্সপামলে আমাদের বি এবং এ একসাথে শিপিং করতে হয়েছিল, যদিও বি এ-তে কোথাও ব্যবহৃত হয় না তবে- usingসেশনে ব্যবহৃত হয়। এটি সমাবেশটি লোড করার সময় রানটাইম- পারফরম্যান্সকে ব্যাপকভাবে প্রভাবিত করবে ।A

Answer 10

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

এখন বিবেচনা করুন, যদি আপনাকে 1000 usingনির্দেশাবলী সহ একটি .cs ফাইল দেওয়া হয় যা কেবলমাত্র 10 ব্যবহার করা হয়েছিল। যখনই আপনি বাইরের বিশ্বের তথ্যসূত্রটি কোডটিতে নতুনভাবে প্রবর্তিত একটি প্রতীকটি দেখেন, এটি কী তা নির্ধারণ করার জন্য আপনাকে সেই 1000 লাইনের মধ্য দিয়ে যেতে হবে। এটি অবশ্যই উপরের পদ্ধতিটি ধীর করে দেয়। সুতরাং আপনি যদি তাদের 10 এ কমাতে পারেন তবে এটি সাহায্য করবে!

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