ক্লাস, enums এবং অন্যান্য সত্ত্বা পৃথক ফাইল স্থাপন করা উচিত?


12

আমার সংস্থার টিম লিড-আর্কিটেক্ট যুক্তি দেখিয়েছেন যে "যুক্তি দ্বারা সংযুক্ত সংস্থাগুলি" একটি .সিএস ফাইলে স্থাপন করা হয়েছে কি না তবে একটি বৃহত আকারের প্রকল্পটি বোঝা সহজ।

আমি উদ্ধৃতি:

  • "যুক্তি এবং ইন্টারফেসের পুরো কাঠামো এবং শ্রেণিটি এক জায়গায় দেখা যায়, এটি একটি যুক্তি যা খণ্ডন করা যায় না the একই জিনিসটি দেখতে কিন্তু ফাইলগুলির একটি গুচ্ছ দিয়ে আপনাকে সরঞ্জামগুলি, শ্রেণি ব্যবহার করতে হবে ডায়াগ্রাম, নেভিগেশনের জন্য আর #

  • "দুর্বল তত্ত্বটি অনুসরণ করে আমি চিৎকার করতে পারি যে পৃথক করা ফাইলগুলির একটি সেনাবাহিনী দুর্দান্ত, তবে যখন বিদ্যমান কোডটিতে পরিবর্তন আনার কথা আসে, বিশেষত আপনি যদি এই কোডটির লেখক না হন, তবে প্রচুর পরিমাণে বিক্ষিপ্ত ফাইলগুলি বোঝা খুব কঠিন difficult সুতরাং ফোরামে, আপনি যে "একটি এনাম-এক ফাইল" লিখতে পারেন, তবে বাস্তবে এই পদ্ধতির ব্যবহার কখনও করা উচিত নয় "

  • "... বিকাশকারীদের মধ্যে কোড বেসকে পৃথক করার জন্য, আজকাল একই ফাইল একই সময়ে সম্পাদনা করা কোনও সমস্যা নয় The মার্জটি কোনও সমস্যা নয়" "

আমি অনেকবার শুনেছি এবং পড়েছি যে আমাদের এনাম, ক্লাস এবং আরও এক .cs ফাইল তৈরি করতে হবে এবং এটি সেরা অনুশীলন।

তবে আমি তাকে বোঝাতে পারি না। তিনি বলেছেন যে তিনি জোন স্কীটের মতো কোনও নামী প্রোগ্রামারদের উপর বিশ্বাস রাখেন না। উপায় দ্বারা এখানে স্কিটির এই বিষয়ে মতামত: এনামের ধরণগুলি সনাক্ত করার জন্য সেরা স্থানটি কোথায়?

আপনি কি মনে করেন? বাস্তব সমস্যা আছে কি? বা এটি স্বাদের বিষয় এবং সংস্থার কোডিং মান দ্বারা নিয়ন্ত্রিত করা উচিত?


আপনি স্কিটি কার্ড খেললেও আপনি সব কিছুতে পারবেন না।
জেফো

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

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

2
আপনি চিহ্নিত করতে পারেন যে স্টাইলকপটি ভিজ্যুয়াল স্টুডিও প্লাগইন হিসাবে সতর্কতা রয়েছে যদি প্রতি ফাইলটিতে> 1 শ্রেণি থাকে
কেভিন

উত্তর:


20

আপনার টিম লিডের যুক্তিতে কয়েকটি ত্রুটি রয়েছে:

  1. সু-নকশাকৃত ক্লাস এবং এনামগুলি আপনার প্রকল্পের যে কোনও জায়গায় ব্যবহার করার উদ্দেশ্যে করা হয়েছে , কেবল যেখানে তারা যুক্তিযুক্তভাবে বোধগম্য হতে পারে not

  2. এক্সএমএল মন্তব্যে যথাযথভাবে নথিভুক্ত করা ক্লাস এবং এনামগুলি কেবলমাত্র এটি উল্লেখ করে আইটেমটিকে ঘুরিয়ে রেখে খুব স্ব-বর্ণনামূলক।

  3. আপনি সর্বদা ক্লাসে পৌঁছতে পারেন বা রেফারেন্সটিতে ডান ক্লিক করে এবং "সংজ্ঞাতে যান" নির্বাচন করে এনাম সংজ্ঞাতে যেতে পারেন, তাই আপনি এটি কোথায় রেখেছেন তা আসলেই বিবেচ্য নয় ।

  4. "যৌক্তিক" ফ্যাশনে অবজেক্টগুলি একসাথে রাখা স্বেচ্ছাসেবী (যেমন আপনাকে "লজিকাল" অর্থ কী তা নিয়ে ভাবতে হবে I'd আমি বরং প্রকৃত প্রোগ্রামিংয়ের সময়গুলি ঘড়িচক্রটি ব্যয় করব)।

প্রতিটি ফাইলের নিজস্ব ফাইলে সংজ্ঞা স্থাপনের ফলে সংগঠন এবং কাঠামোর একটি অভিন্ন, শৃঙ্খলাবদ্ধ প্রত্যাশা তৈরি হয় এবং "এটি এখানে কেন?" এর মতো প্রশ্ন উত্থাপন করে না? এটি একটি খুব সুন্দর জিনিস।

যদি দুটি বা ততোধিক অবজেক্ট যুক্তিযুক্তভাবে সম্পর্কিত হয়, কেবল তাদের প্রজেক্ট এক্সপ্লোরারে তাদের নিজস্ব ফোল্ডারে রাখুন


5
অন্য নোটে, কোড স্তন্যপান। অবশ্যই, আপনি এগুলি করতে পারেন, তবে কেন, যদি আপনার না হয়?
রবার্ট হার্ভে

4

ডান ক্লিক এবং "সংজ্ঞাতে যান" বাছাই করা কোনও বিকল্প ছিল না এমন সময় সম্ভবত পূর্বের যুগে দলের লিড তার দাঁত কাটত। আমি জানি যখন আমি ভারী স্পাইক বিকাশ মোডে থাকি তখন পর্যন্ত আমি বেশ বড় বড় ক্লাস ফাইলগুলি বাড়িয়ে আনব যতক্ষণ না আমি পুনরায় ভাগ করার বিষয়টি আমার জন্য এটি ঠিক করতে দিই।

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

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