সি # - ক্ষেত্রগুলিতে উপসর্গগুলি কেন নিরুৎসাহিত করা হচ্ছে?


19

পুরানো দিনগুলিতে, আমরা হাঙ্গেরিয়ান স্বরলিপিটি করেছি। এটি এখন পাসé হিসাবে বিবেচিত এবং বেশিরভাগ অংশের জন্য আমি এটিকে আর ব্যবহার করি না, তবে m_সদস্য ক্ষেত্রগুলি নির্দেশ করার জন্য আমি উপসর্গটির জন্য এখনও ব্যবহার খুঁজে পাই ।

আমার জন্য, যদি আমি অন্য কারও কোড দিয়ে পড়ছি এবং আমি এটি দেখতে পেলাম:

count = 3;

আমি ধরে নিই যে countসেই ফাংশনের স্থানীয় একটি পরিবর্তনশীল এবং আমি এমন কিছু করছি যা ফাংশনের অন্য কোথাও ব্যবহার করা হবে; যদি আমি এটি দেখতে পাই:

m_count = 3;

আমি তত্ক্ষণাত বুঝতে পারি যে আমি বস্তুর স্থিতি আপডেট করছি।

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

হ্যাঁ, আমরা আমাদের নিজস্ব কোডিং শৈলীর সংজ্ঞা দিতে পারি, তবে তারপরে আমাকে বিভিন্ন স্থিতিশীল কোড বিশ্লেষণ সরঞ্জামগুলির সাথে কুস্তি করতে হয়েছিল, তাদের বোঝাতে যে আমাদের কাজ করার পদ্ধতিটি ঠিক।

আমি মাইক্রোসফ্ট স্টাইলে পরিবর্তিত হতে পেরে খুশি, তবে জিনিসগুলি কেন সেভাবে হয় তা আমি জানতে চাই ।

একটি ভেরিয়েবল স্থানীয় বা সদস্য হিসাবে কাজ করে কিনা তা বলতে সক্ষম হওয়া এখন কেন খারাপ বিবেচিত হবে?

পিএস এটির সাথে খুব সামঞ্জস্যপূর্ণ ক্ষেত্রের সামনে "এই" কীওয়ার্ড এবং সি # তে পদ্ধতিগুলির বিষয়ে বিবেচিত বর্তমান সেরা অনুশীলনগুলি কী? , কিন্তু আমি সম্পর্কে জিজ্ঞেস করছি m_নাthis.

পিপিএস এছাড়াও দেখুন মাইক্রোসফ্ট কেন প্যারামিটার তৈরি করেছে, স্থানীয় ভেরিয়েবল এবং ব্যক্তিগত ক্ষেত্রে একই নামকরণের কনভেনশন রয়েছে?


9
সি # এর thisকীওয়ার্ড নেই? আপনি thisযেমন ব্যবহার করে সদস্যদের উল্লেখ করতে পারেন না this.count?
হতাশ

3
M_ উপসর্গ একটি সি ++ - ইসম যেখানে এটি ক্ষেত্র এবং পদ্ধতির মধ্যে নাম সংঘর্ষ এড়ায়। সি # তে এটি কোনও সমস্যা নয় কারণ পদ্ধতির নামগুলি বড় হাতের অক্ষরের সাথে ছোট ক্ষেত্রগুলির সাথে শুরু করা উচিত।
আমন

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


উত্তর:


19

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

অন্যদিকে, সি # এর শুরু থেকেই খুব শক্ত আইডিই রয়েছে।

সুতরাং তারা পাবলিক স্ট্যাটিক বা সুরক্ষিত ক্ষেত্রগুলির জন্য সি # এর জন্য মাইক্রোসফ্টের নামকরণের নির্দেশিকায় সুপারিশ করেছিলেন :

 DO use PascalCasing in field names.
 DO name fields using a noun, noun phrase, or adjective.
X DO NOT use a prefix for field names.

এখন আপনি এটি আপনার মাউস দিয়ে ঘোরাতে পারেন, বা CTRL + K + W টিপুন এবং সদস্য সম্পর্কে সমস্ত তথ্য পেতে পারেন, মাইক্রোসফ্ট দৃ the় সিদ্ধান্তে এসেছিল যে উপসর্গগুলি খারাপ ফর্ম; তারা ইতিমধ্যে সমাধান করা সমস্যার ম্যানুয়াল সমাধান।

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

আপনার সরঞ্জামগুলি ব্যবহার করুন, ম্যানুয়ালি এটি করবেন না।


2
অ্যান্ডির একই উত্তর ... হ্যাঁ তবে ... অনেকগুলি পরিস্থিতি রয়েছে যেখানে আমি আইডিইর বাইরে কোড দেখছি। উদাহরণ - (1) মার্জ করার সরঞ্জামগুলি। (2) কোড পর্যালোচনা সরঞ্জাম। (3) (হাঁপা) প্রিন্টআউটগুলি।
বেটি ক্রোকার 21

অ্যান্ডি আক্ষরিকভাবে একই তাত্ক্ষণিকভাবে পোস্ট করেছিলেন। আমি "উত্তর যোগ করুন" ক্লিক করার সাথে সাথে "1 টি নতুন মন্তব্য" পপ আপ দেখেছি। যতক্ষণ না সেই সরঞ্জামগুলি, তাদের মধ্যে দুটি ইতিমধ্যে আইডিইতে রয়েছে। প্রিন্টআউটস ... আপনি এটি করছেন কেন?
কেভিন ফি

1
আমার প্রাথমিক প্রশ্নটি উত্তরহীন রয়ে গেছে ... হ্যাঁ, মাইক্রোসফ্ট বলেছিল যে m_ এবং সরঞ্জাম নির্মাতারা তা অনুসরণ করবেন না, তবে এটি m_ ব্যবহার করার প্রযুক্তিগত কারণ নয়, এটিকে প্রায়শই "কর্তৃপক্ষের কাছে আবেদন" বলা হয়। আমি_ প্রযুক্তিগত কারণটিই দেখেছি যে আমি_আর ব্যবহার না করতে পেরে এসেছি টিমোথি ট্রকল এসেছিল এবং আমি তা বুঝতে পারি না ...
বেটি ক্রোককার

8
@ বেট্টি ক্রোকার কারণ এম_ একেবারে কোনও মূল্য যুক্ত করে না। আইডিই আপনাকে সদস্যকে বলে বা না জানায় তাই মি_ অপ্রয়োজনীয়। কেন আপনি এম_কে স্থির করছেন? কেন l_ (স্থানীয়দের জন্য) নয়? কেন আফসডফজডসকফজস_? আমি প্রশ্নটি নীচে নামাতে যাচ্ছি, কারণ এটি যাইহোক একটি মূর্খ ধর্মীয় যুক্তি। যা ইচ্ছা কর. নির্দেশিকা আপনার কাছে ঠক্ঠক্ শব্দ করছি বলে "ক্ষেত্র নামকরণ করার নির্দেশিকা প্রযোজ্য স্ট্যাটিক সরকারি ও সংরক্ষিত ক্ষেত্রঅভ্যন্তরীণ ও বেসরকারি ক্ষেত্র _not_ নির্দেশিকা দ্বারা আচ্ছাদিত , এবং পাবলিক বা সংরক্ষিত দৃষ্টান্ত ক্ষেত্র সদস্য নকশা নির্দেশিকা দ্বারা উল্লিখিত অনুমতি দেওয়া হয় না।"
অ্যান্ডি

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

17

সি # এর কোনও গ্লোবাল ভেরিয়েবল নেই, যাতে কেবল স্থানীয় ভেরিয়েবল এবং শ্রেণি-ক্ষেত্র ছেড়ে যায়।

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

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

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


একবার আপনি এতে ডট হয়ে গেলে এটি কোনও শ্রেণি বা নেমস্পেসও হতে পারে।
কোডসইনচওস

3
আমি মনে করি না এটি সত্যই প্রশ্নের উত্তর দেয়।
ভ্লাদিমির স্টোকিক

5
@ ফ্র্যাঙ্কহিল্যান আসলে, তা এটি ব্যাখ্যা করে যে কেন কোনও নামকে কুণ্ডিত করার কোনও ভাল কারণ নেই।
প্রতিলিপি

2
"uglifying"? যদি এটি হয় তবে এটি একটি মতামত-প্রশ্ন। কদর্যতা সম্পর্কে প্রত্যেকেরই আলাদা মতামত থাকতে পারে। একটি কনভেনশনকে অন্যের চেয়ে বেশি প্রাধান্য দেওয়ার কারণ রয়েছে তবে এই ক্ষেত্রে কোনও স্ট্যান্ডার্ড কনভেনশন নেই।
ফ্রাঙ্ক হিলিমান

1
@ ডেডুপ্লিকেটর সৌন্দর্যটি দর্শকের চোখে পড়ে। সম্মেলনগুলিকে আমি একবার কুৎসিত মনে করেছিলাম, এখন আমি দরকারী হিসাবে প্রশংসিত।
ফ্র্যাঙ্ক হিলিমান

11

বিকাশকারীরা কেন ব্যবহার করে নেমস্পেসের নির্দেশিকা সহ নেমস্পেসগুলি প্রিপেন্ডিং এড়াবেন?

System.DateTime()এর চেয়ে অনেক বেশি স্পষ্ট DateTime()। এটি আমাকে জানায় যে আমি ঠিক কীভাবে কাজ করছি। এটা কি কেবল কারণ আমরা আলস্য টাইপিস্ট?

না, আমরা অলস টাইপিস্ট, তবে সে কারণ নয়।

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

এটি একই কারণে আপনি আপনার দলে জো নামে দুটি লোক চান না want তাদের শেষ নাম থাকার বিষয়টি তাদের উপসর্গ বা প্রত্যয় দেওয়ার কারণ নয়। আমি আপনাকে শুধু স্কিটি কল করতে যাচ্ছি। আর কিছু হ'ল ফ্ল্যাট আউট ব্যথা।


2
এটি প্রশ্নের উত্তর বলে মনে হচ্ছে না। । নেট এ ব্যক্তিগত ক্ষেত্রগুলির জন্য সাধারণ পছন্দ বা কনভেনশন নেই।
ফ্রাঙ্ক হিলেমান

12
@ ফ্র্যাঙ্কহিল্যান সাধারণভাবে, আমরা ভাল নাম পছন্দ করি। সম্মেলনগুলি ভাল নাম তৈরি করে না। কনভেনশনগুলি ম্যাকওহপ্লেজ ভন স্টপআইটএলডিডারস্টাইনের মতো নাম তৈরি করে।
candied_orange

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

7

আসুন কিছুটা প্রসারিত করা যাক।

এখানে 3 টি সাধারণ উপসর্গ শৈলী রয়েছে, সেগুলি সবসময় মাঝে মাঝে সি # কোডে দেখা হয়:

  • m_
  • : _
  • এই.

এই জাতীয় উপসর্গগুলি সাধারণত কোনও শ্রেণীর ব্যক্তিগত প্রয়োগে ব্যবহৃত হয় । মাইক্রোসফ্টের সুপারিশটি মূলত কোনও শ্রেণীর উন্মুক্ত অংশগুলি সম্পর্কে।

ব্যবহারের সুবিধা m_ধরে _সেই প্রেফিক্স আপনার সমগ্র কোডবেস একই হতে পারে আপনি ভাল হিসাবে হিসাবে C # ব্যবহার ভাষায় যেখানে ব্যবহার _যেমন একটি উপসর্গ মঞ্জুরিপ্রাপ্ত নয় । * সুবিধা m_ধরে this.এটি খাটো হয় এবং যে আপনি দূর্ঘটনাক্রমে না করবে না উপসর্গ সম্পর্কে ভুলবেন

_ওভারের সুবিধাটি m_হ'ল এটি সংক্ষিপ্ত এবং উপসর্গ দিয়ে শুরু হওয়া যে কোনও কিছুই শীর্ষে বাছাই করা হয় কোনও সরঞ্জাম দ্বারা বর্ণমালা অনুসারে বাছাই করা হয়। _ওভারের সুবিধা this.হ'ল এটি খাটো এবং আপনি দুর্ঘটনাক্রমে উপসর্গটি ভুলে যাবেন না।

this.ওভারের সুবিধা m_এবং _এটি হ'ল আপনি এটি কোনও কোডবেসে ব্যবহার করতে পারেন যেখানে কোনও গ্রহণযোগ্য এবং সর্বজনীন কনভেনশন নেই _or m_এর অর্থ এটিও হ'ল যে কাউকে কনভেনশন _বা m_কনভেনশন সম্পর্কে জানার দরকার নেই , যা জিনিসগুলি সহজ করে তোলা হিসাবে দেখা যায়। একটি খারাপ দিক হিসাবে, কারণ সংকলকটি এই উপসর্গটির বিষয়ে চিন্তা করে না, this.উপসর্গটি মাঝে মাঝে অনুপস্থিত হবে এবং এটি সূচকের মতো নির্ভরযোগ্য হতে পারে না।


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


এটি সম্পর্কিত স্ট্যাকওভারফ্লো নিয়ে একটি পুরানো প্রশ্ন রয়েছে


1
ভাল তুলনা। তবে, আমি দেখতে পেয়েছি যে কোনও উপসর্গ ব্যবহার না করা অনুশীলনে ভাল কাজ করে।
ফিল 1970

6

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

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

আপনি আপনার ব্যক্তিগত বা স্থানীয় ভেরিয়েবলগুলিতে আপনার পছন্দ মতো স্টাইল ব্যবহার করতে পারবেন।

ভেরিয়েবলের উপসর্গগুলি বেশ কয়েকটি কারণে সাধারণভাবে নিরুত্সাহিত হয়ে গেছে বলে

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

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

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

4
আপনি যদি কোনও কিছুতে "এগুলি ভুল হতে পারে, এবং সেইজন্য বিভ্রান্তিকর" প্রয়োগ করেন তবে আপনি দ্রুত আবিষ্কার করেছেন যে আপনার ভেরিয়েবল বা ফাংশনগুলির নাম দেওয়া উচিত নয় - এগুলি সর্বোপরি ভুল হতে পারে! এবং আমি অনুমান করছি যে আপনার দ্বিতীয় বুলেট পয়েন্টটি "আপনি তৈরি করেননি এমন ক্লাস" বলার কথা? অন্যথায় আমি এটি বুঝতে পারি না ... যে কোনও ক্ষেত্রে, এটি অ-সরকারী ক্ষেত্রগুলির জন্য একক আন্ডারস্কোর উপসর্গ থাকা যেমন একটি আনুষ্ঠানিক মান, এটি সম্ভবত আমরা যাব যে দিকটি সম্ভবত এটি শুরু হবে sound
বেটি ক্রোকার

কিছু বিষয় সংকলক দ্বারা চেক করা হয়, তাই m_count সদস্যের পরিবর্তনশীল নাও হতে পারে, তবে এই কোডটি সর্বদা থাকবে
ইওয়ান

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

4

আমার জন্য, যদি আমি অন্য কারও কোড দিয়ে পড়ছি এবং আমি এটি দেখতে পেলাম:

count = 3;

আমি ধরে নিই যে 'কাউন্ট' এই ফাংশনের স্থানীয় একটি পরিবর্তনশীল এবং আমি এমন কিছু করছি যা ফাংশনের অন্য কোথাও ব্যবহার করা হবে

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

this.count = 3;

ক্ষেত্রের জন্য একটি মান নির্ধারণ করে।

count = 3;

স্থানীয় ভেরিয়েবলের মান নির্ধারণ করে।

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

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

public class Hello
{
    private string greetings;

    public Hello(string greetings)
    {
        greetings = greetings; // Wait, what is that?!
    }
}

সি # এর কিওয়ার্ডটি নেই? আপনি কি এই ব্যবহারকারী সদস্যদের উল্লেখ করতে পারেন না?

হ্যাঁ, তবে (1) এটি আরও বেশি টাইপ করছে এবং (2) এটি ভুলে যাওয়া সহজ। যদি ক্ষেত্রটির নাম মি_কাউন্ট হয় তবে আমার এটি.এম_কাউন্ট টাইপ করতে হবে না

এখানে তবে আপনি ভুল করছেন।

আপনি নোটপ্যাডে আপনার কোডটি লেখার সময় এটি আরও টাইপ করা হয়। স্বয়ং-সম্পূর্ণতে সঙ্গে একটি আইডিই বা, ভাল, IntelliSense মধ্যে তুলনা দিয়ে this.countএবং m_countসুস্পষ্ট যেমন নয়। আন্ডারস্কোর টাইপ করতে প্রয়োজনীয় Shift+ নোট করুন -

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


6
আমি দেখতে পেয়েছি যে thisযখন আপনার প্রয়োজন হবে কেবল তখনই এটির ব্যবহারটি সত্যিই বেমানান বোধ করে এবং খুব ঘন ঘন আমাকে বিভ্রান্ত করে। আপনি যদি thisউপসর্গের পরিবর্তে ব্যবহার করতে চলেছেন তবে আমি বিশ্বাস করি আপনার সর্বদা এটি ব্যবহার করা উচিত । কোন ক্ষেত্রে এটি একটি উপসর্গ হয়ে যায় এবং আপনি পাশাপাশি ব্যবহার করতে পারেন _
রাবারডাক

1
রাবারডাক ঠিক আছে। "এই." এটি একটি উপসর্গ, যদিও এর সংকলক অর্থ রয়েছে।
ফ্রাঙ্ক হিলেমান

4

"সদস্য" উপসর্গ একটি বাস্তবায়ন বিশদ। এটি সমস্যার ডোমেন থেকে প্রযুক্তিগত সমাধান ডোমেনের দিকে আপনার মনোযোগকে বিভ্রান্ত করে যা সম্ভব রিফ্যাক্টরিংগুলির কথা চিন্তা করার সময় আপনার মনের দিকে নজর রাখে। - আমাকে

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

আমার বক্তব্য @CandiedOrange এবং @ ইভানের উত্তরগুলি প্রসারিত করছে।

উপসর্গগুলি আরও শক্ত করে তোলে make

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

ধরা যাক আপনি একটি ট্যাক্স ক্যালকুলেটর তৈরি করেন। ভেরিয়েবলের জন্য লিজের দৃশ্যমানতার সুযোগের নীতি অনুসারে আপনি প্যারামিটার হিসাবে করের হার এবং বেস মান উভয়ই গ্রহণ করে এমন একটি পদ্ধতি দিয়ে শুরু করেন :
(উদাহরণস্বরূপ জাভা-ইশ লাগতে পারে ...)

class TaxCalculator{
   double Calculate(double p_TaxRateInpercent, double p_BaseValue){
     return (100+p_TaxRateInpercent)/100 * p_BaseValue;
   }
} 

এরপরে আপনাকে বিপরীত অপারেশন বাস্তবায়ন করতে হবে এবং টিডিডি অনুসারে আপনি এটি সর্বনিম্ন প্রচেষ্টা দিয়ে করুন:

class TaxCalculator{
   double Calculate(double p_TaxRateInpercent, double p_BaseValue){
     return (100+p_TaxRateInpercent)/100 * p_BaseValue;
   }
   double CalculateBase(double p_TaxRateInpercent, double p_TaxedValue){
     return p_TaxedValue/((100+p_TaxRateInpercent)/100);
   }
} 

পরবর্তী টিডিডি চায় যে আপনি কোডটি পরিষ্কার করে তুলুন যাতে উভয় পদ্ধতির প্যারামিটারের তালিকা হ্রাস করা যায়।
(হ্যাঁ, আপনি প্রথমে দ্বিগুণ গণনাটি বের করে আনবেন, তবে আমার বক্তব্যটি আমাকে জানাবেন ...)
সুস্পষ্ট সমাধান হ'ল করের হারকে কনস্ট্রাক্টর প্যারামিটার হিসাবে পাস করে সদস্য ভেরিয়েবলে পরিবর্তন করা।

class TaxCalculator{
   double m_TaxRateInpercent;
   TaxCalculator(double p_TaxRateInpercent){
     m_TaxRateInpercent = p_TaxRateInpercent;
   }
   double Calculate(double p_BaseValue){
     return (100+m_TaxRateInpercent)/100 * p_BaseValue;
   }
   double CalculateBase(double p_TaxedValue){
     return p_TaxedValue/((100+m_TaxRateInpercent)/100);
   }
} 

আপনি দেখতে পারেন যে আমাদের আমাদের বিদ্যমান পদ্ধতির সমস্ত লাইন পরিবর্তন করতে হয়েছিল (যে কোনও লাইন আমরা p_TaxRateInpercentনির্ভুল ব্যবহার করতাম) ।

সমস্যাটি হ'ল, ক্লাস জুড়ে নতুন নামকরণের জন্য আপনার আইডিইর কোনও সমর্থন নেইঅনুসন্ধান বা প্রতিস্থাপনের ক্ষেত্রে কেবল এটির সাহায্যই কনস্ট্রাক্টর বা দুর্ঘটনাক্রমে স্ট্রিং সহ যে কোনও অংশে পরিবর্তন আনবে p_TaxRateInpercent
আপনি আইডিই বদলে দিতে পারেন ... অপরিজ্ঞাত পরিবর্তনশীল নামগুলির জন্য রিফ্যাক্টরিং তবে এটি পদ্ধতির সুযোগে সীমাবদ্ধ থাকতে পারে may

উপসর্গ ব্যতীত কেবল পদ্ধতি স্বাক্ষরগুলি পরিবর্তিত হত। কোনও নামকরণের প্রয়োজন হয় না।


উপসর্গগুলি ক্লিটর এসসিএম ইতিহাস পরিবর্তন করা হলে changed

এছাড়াও এসসিএম যুক্তির পরিবর্তন হিসাবে উপসর্গের পরিবর্তনটি রেকর্ড করে যদিও যুক্তিটি পরিবর্তন হয়নি! এসসিএমের ইতিহাস এই প্রযুক্তিগত পরিবর্তনটি কী গুরুত্বপূর্ণ তা গোপন করে এবং অন্যের (আসল যুক্তি) পরিবর্তনের সাথে দ্বন্দ্বের ঝুঁকি বাড়িয়ে তোলে ut


1

আমি সমস্ত সদস্য ভেরিয়েবলের জন্য _ উপসর্গ ব্যবহার করি। আমি 'এই' উপসর্গটিকে ঘৃণা করি কারণ কেউ কেউ দাবি করেন যে এটি জিনিস করার সঠিক উপায় it এটি আপনার কোডবেজে প্রচুর শব্দ / বিশৃঙ্খলা যুক্ত করে। মাইক্রোসফ্টের নমুনাগুলিতে একটি আন্ডারস্কোরও একটি সাধারণ অভ্যাস।

সুতরাং আপনার উদাহরণে আমি থাকতাম:

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