কোনও ভাষায় সংবেদনশীল কীওয়ার্ডগুলি [বন্ধ]


31

আমরা একটি কাস্টম স্ক্রিপ্টিং ভাষা লেখার চেষ্টা করছি। সংবেদনশীল কীওয়ার্ড সরবরাহ করে ভাষাটিকে ক্ষমা করার জন্য একটি পরামর্শ দেওয়া হয়েছে ।

আমি ব্যক্তিগতভাবে এই ধারণাটি পছন্দ করি না, তবে আমার দলে খুব কম লোকই এটির দিকে ঝুঁকছে, বলেছে এটি শেষ ব্যবহারকারীকে খুশি করবে! ফরট্রান, বেসিক, এসকিউএল এর মতো ভাষার উদাহরণগুলি দেওয়া হয়েছে যে এগুলি কেস সংবেদনশীল।

এই একটি ভাল ধারণা?


4
ঠিক আছে, ভিজ্যুয়াল বেসিক সাধারণত সংবেদনশীল হয় না, এটি কি আপনার প্রশ্নের উত্তর দেয়? ; পি
ইন্নিস


3
মনে রাখবেন যে সনাক্তকারীদের ক্ষেত্রে সংবেদনশীল হওয়া অসম্ভব সংবেদনশীল, যদি না আপনি ASCII অক্ষর সেটটিতে ব্যবহারকারীদের সীমাবদ্ধ করেন।
সাইমন রিখটার

2
@ মাইনমা: সি ++ কমপক্ষে সরাসরি হয় না। এটা তোলে সনাক্তকারীতে বাস্তবায়ন-সংজ্ঞায়িত অক্ষর পারবেন, কিন্তু কি নিশ্চিত করা হয় শুধুমাত্র a-zA-Z, 0-9(শুরুতে ব্যতীত) এবং _
Xeo

2
ভিবি 6 আসলে এক ধরণের হাইব্রিড পদ্ধতির ব্যবহার করে: আপনি যে কোনওভাবে কীওয়ার্ড এবং আইডেন্টিফায়ার লিখতে পারেন এবং IDE তত্ক্ষণাত এগুলিকে সঞ্চিত উপায়ে রূপান্তর করে। (আপনি এমনকি "এন্ডিফ" লিখতে পারেন এবং এটি "শেষ যদি" ​​তে রূপান্তরিত হয়))
ফেলিক্স ডমব্যাক

উত্তর:


42

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

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

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


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

4
যেহেতু এটি একটি স্ক্রিপ্টিং ভাষা, এটি কোনও মস্তিষ্কের নয় - ক্ষেত্রে সংবেদনশীলতা হ'ল উপায়। মামলা-সংবেদনশীল কেন? যদি উত্তরটি "সি এবং জাভা এর মতো হতে হয়", তবে এটি কি সত্য কারণ?
বেন

15
@ বেন পাইথন, রুবি, বাশ, লুয়া এবং পার্ল অত্যন্ত জনপ্রিয় স্ক্রিপ্টিং ভাষার উদাহরণ যা সংবেদনশীল। সংবেদনশীল ভাষাগুলির মধ্যে ডেল্ফি এবং এসকিউএল (এবং কোবল আইআরসি, যদি আপনি এটি গণনা করেন) এর মতো উদ্যোগী ভাষা অন্তর্ভুক্ত করে। এটি কেন স্ক্রিপ্টিং ভাষার জন্য নন-ব্রেইনার এবং কেন বিশ্বের বৃহত্তম স্ক্রিপ্টিং ভাষার ডিজাইনাররা তাতে একমত নন?

2
স্ক্রিপ্টিং ভাষা হওয়ার কারণে এটি কোনও নন-ব্রেইনার হতে পারে না - প্রাসঙ্গিক প্রশ্নটি: স্ক্রিপ্টিংটি কে করছেন এবং তাদের জন্য সেরা পছন্দটি কী? (আমি এটিও বলব যে আপনার সম্ভবত সামঞ্জস্যপূর্ণ হওয়া উচিত: যদি আপনার কীওয়ার্ডগুলি সংবেদনশীল না হয় তবে দয়া করে শনাক্তকারীদের কেস-সংবেদনশীল করবেন না ...)
আগত

@ ডেলানান আমি মনে করি যে এটি একটি যৌক্তিক পছন্দ যে ওএসকে লক্ষ্য করে ভাষা স্ক্রিপ্টিং যেখানে কেস-সংবেদনশীলতা অন্তর্নির্মিত হয় তাও কেস-সংবেদনশীল হওয়া উচিত।
আর্টেমিক্স

16

আপনি যে ব্যবহারকারীকে উপস্থাপন করতে চান তার উপর ভিত্তি করে আপনার সিদ্ধান্ত নেওয়া উচিত, এটি কার্যকর করা কতটা সহজ বা কঠিন নয় not

যদি এটি আপনার ব্যবহারকারীদের ক্ষেত্রে সংবেদনশীলতা বজায় রাখা সহজ করে তোলে তবে আপনার এটাই বাস্তবায়ন করা উচিত।

বিন্দু হিসাবে এসকিউএল কেস সংবেদনশীল হয়। এটি ইন্টারেক্টিভ সেটিংসে এটি ব্যবহার করা খুব সহজ করে তোলে।

এটি দেখার আরেকটি উপায় হ'ল কি কখনও আপনার ভাষার মধ্যে keywordএবং Keywordআপনার ভাষার মধ্যে পার্থক্য থাকতে পারে এবং এই পার্থক্যটি কি ব্যবহারকারীর কাছে অর্থবহ হবে? স্ক্রিপ্টিং ভাষার জন্য আমি উত্তরটি "না" বলব।


3
"এই পার্থক্য কি ব্যবহারকারীর কাছে অর্থপূর্ণ হবে" এর জন্য +1। ব্যবহারকারী সবচেয়ে গুরুত্বপূর্ণ।
বেন

সংবেদনশীলতার কারণে এসকিউএল কেন ইন্টারেক্টিভ সেটিংসে ব্যবহার করা সহজ? আপনি দুর্ঘটনাক্রমে ক্যাপস লকটি চালু করতে পারেন এবং লক্ষ্য না রাখার কারণ এটি?
কাজ

@ কাজ - অনেক অনেক।
ক্রিসএফ

11

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

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

কিছুক্ষণের জন্য, টার্মিনালগুলিতে এমনকি কেস ভাঁজ করাও সাধারণ ছিল। যদি কোনও টার্মিনাল কেবল উচ্চতর কেস প্রদর্শন করতে পারে তবে আপনাকে উচ্চতর এবং লোয়ার কেস সমর্থন করে এমন একটি কম্পিউটিং সিস্টেমে লগইন করতে হয়েছিল, টার্মিনালটি লোয়ার কেসটি আপার ক্ষেত্রে বিভক্ত করবে। ভাবুন তো এতদিন আগে ছিল? "অ্যাপল II-এর মতো, অ্যাপল II প্লাসের কোনও ছোট হাতের কার্যকারিতা ছিল না।" (http://en.wikedia.org/wiki/apple_II_Plus) প্রাথমিক অ্যাপল কম্পিউটার ব্যবহারকারীরা যখন বিবিএসে ডায়াল করে মিশ্র-কেস বিষয়বস্তু ছিল, টার্মিনাল এমুলেটর (বা হোস্ট) এগুলি সবগুলি আপার কেস করতে হবে। সমস্ত ক্যাপগুলিতে লিখিত বার্তাগুলি সেই দিনগুলিতে বুলেটিন বোর্ডগুলিতে প্রচলিত ছিল। এই কার্যকারিতাটি এখনও ইউনিক্সের মতো লিনাক্স কার্নেলের মতো অপারেটিং সিস্টেমে পাওয়া যায়। উদাহরণস্বরূপ, stty olcucআপনার শেল প্রম্পটে টাইপ করুন ।ইউনিক্স টিটি লাইনের শৃঙ্খলা আউটপুট-এর উপরের থেকে নিম্নের ক্ষেত্রে মানচিত্র তৈরি করতে পারে এবং এটি ইনপুট-এর উপরের ক্ষেত্রে উপরের কেসকে মানচিত্র করতে পারে। এটি আপনাকে এমন একটি টার্মিনালে লোয়ার কেস প্রোগ্রামিং ল্যাঙ্গুয়েজে কাজ করতে দেয় যা কোনও ছোট ক্ষেত্রে নেই।

কেস সংবেদনশীলতা একটি বিগত কম্পিউটার যুগের একটি পুরানো ধারণা যা আন্তর্জাতিকীকৃত কম্পিউটিংয়ের আধুনিক বিশ্বে খুব ভাল কাজ করে না। আপনি কি অন্যান্য ভাষায় এটি প্রসারিত করেন? ফরাসী সম্পর্কে কীভাবে: আপনি È এবং è কে সমতুল্য মনে করেন? নাকি জাপানী? আপনি কি হীরাগানা এবং কাতকানাকে কেবল মামলা হিসাবে বিবেচনা করেন, যাতে フ ァ イ ル এবং ふ ぁ い the একই পরিচয়দাতা হয়? এই জাতীয় মূর্খতার জন্য সমর্থন আপনার লেজিকাল বিশ্লেষককে ব্যাপকভাবে জটিল করে তুলবে, যার পুরো ইউনিকোড জায়গার ক্ষেত্রে কেস সমতুল্য মানচিত্র থাকতে হবে।

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

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

বেসিকালি, 1985 সাল থেকে তৈরি হওয়া কোনও নতুন প্রোগ্রামিং ল্যাঙ্গুয়েজ হ'ল সংবেদনশীল is যারা ই-মেল এবং পোস্টিংয়ের বাইরে দ্বিতীয় বারের মত প্রকাশ করবেন তাদের জন্য।

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

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

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


1
"ফরাসিদের সম্পর্কে কীভাবে: আপনি È এবং equivalent কে সমতুল্য মনে করেন? বা জাপানি? আপনি কি হীরাগানা এবং কাতাকানাকে কেবল মামলা হিসাবে বিবেচনা করেন, যাতে フ ァ イ ル এবং ふ ぁ い る একই পরিচয়দাতা?" উত্তরটি হ্যাঁ "হ্যাঁ", এবং যদি আপনি অন্য ব্যক্তির সংস্কৃতি বোকামি মনে করেন তবে এটি কেবল বোকামি।
বেন

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

@ আপনি কি বর্ণিত সংস্কৃতিগুলি জানেন? আপনি যদি জানতেন যে কাজ আপনি কী বিষয়ে কথা বলছেন তা তাকে বোকা বলে না।
ডেভিড কাউডেন

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

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

6

আসল নির্ধারণকারী ফ্যাক্টরটি হ'ল আপনি একই নামের সাথে একাধিক জিনিস রাখতে চান। কেস সংবেদনশীলতা এসকিউএল-তে কাজ করে কারণ এটি প্রায়শই আপনি নামক একটি কলাম চান না SELECT। এটি জাভাতে বিরক্তিকর হবে কারণ প্রতিটি অন্যান্য লাইনের মতো দেখতে Object object = new Object(), যেখানে আপনি একই নামটি কোনও শ্রেণি, উদাহরণ এবং নির্মাতাকে উল্লেখ করতে চান।

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

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

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


আমি মনে করি না নামের জন্য কীওয়ার্ডগুলি পুনরায় ব্যবহার করা ইস্যুটি। এসকিউএল, ভিসুয়াল বেসিক, এবং C # (সাবেক দুই কেস-অবশ এবং পরেরটির কেস সংবেদনশীল) শনাক্তকারী উদ্ধৃত করা একটি উপায় অনুমতি দিয়ে উভয় সমাধানে এই: "double quotes"(অথবা [brackets]মাইক্রোসফট SQL এর যে) SQL এর যে, [brackets]VB.net, এবং @atsignসি #।
র্যান্ডম 832

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

আপনি কেন কোনও অবজেক্টের নাম রাখবেন? এটাই কেবল ঝামেলা চাইছে।
বেন

@ বেন, ধরুন আপনি একটি ধারক বস্তু বাস্তবায়ন করছেন, আপনি নিজের অ্যাড পদ্ধতিতে প্যারামিটারটিকে আর কী বলছেন?
উইনস্টন ইওয়ার্ট

@ উইনস্টনওয়ার্ট, আমি এটি কল করব o। এটি কেবলমাত্র প্যারামিটারের নাম হওয়ায় আপনি যা বলছেন তা আসলেই কিছু যায় আসে না। যতক্ষণ না এটি আপত্তিজনক বা অবৈধ নয়, বা বিভ্রান্তির কারণ হিসাবে দায়বদ্ধ
বেন

5

ধরে নেওয়া হয়েছে আপনার স্ক্রিপ্টের ভাষা কেস সংবেদনশীল হবে - আপনি কি এমন একটি সংকলক বা সিনট্যাক্স পরীক্ষক তৈরি করতে যাচ্ছেন যা ব্যবহারকারীকে ভেরিয়েবলের নাম বা কীওয়ার্ডে ভুল কেস ব্যবহার করে টাইপো তৈরি করে যদি তা তাকে বলবে? যদি তা না হয় তবে ভাষা কেসকে সংবেদনশীল করার পক্ষে এটি খুব শক্ত যুক্তি হতে পারে।


ভাল বক্তব্য, কিন্তু একটি উত্তর না।

@ ডেলানন: আভেনার শাহর-কাশতানের (যাকে আমি +1 দিয়েছি) এর মত উত্তর সম্ভবত না, তবে সম্ভবত ওপি'র পক্ষে সহায়ক।
ডক ব্রাউন

3
হ্যাঁ, মন্তব্য হিসাবে সহায়ক;)

সুতরাং যদি এইটিকে যদি বলা হয় যে এটি কেবলমাত্র একটি ভাল ধারণা আপনি যদি কেস সংবেদনশীলতা সম্পর্কে ব্যবহারকারীকে সতর্ক করেন তবে এটি একটি উত্তর হবে? আমার কাছে, এটা ধরে নেওয়া হয়েছিল।
জেফো

নাহ, তবে এটি একটি ছোটখাটো পয়েন্ট হতে হবে যা প্রশ্নের উত্তরটিকে কঠোরভাবে উত্তর দেওয়া উচিত নয়। এই প্রোগ্রামটিতে।

4

আপনি কি ফ্লাইটে ভেরিয়েবলগুলি ঘোষণা করতে পারেন? যদি তাই হয় তবে আমি সংবেদনশীল কেসের বিরুদ্ধে তর্ক করব কারণ এটির কারণে একটি বাগ সন্ধান করা হচ্ছে

ATypo = 42; 

উল্টোদিকে

Atypo = 42; 

অপ্রয়োজনীয়ভাবে ডিবাগিংয়ের সময় জিজ্ঞাসা করা হয়, যখন দুটি বিবৃতি সমান হয় জীবন সহজ করে তোলে।


2
আইএমএইচও এটি পড়া সহজ করে তোলে। সর্বোপরি আপনি যখন কোনও বাক্য শুরু করেন, আপনি প্রথম শব্দের মূলধন করেন, তবে আপনি এর অর্থ পরিবর্তন করতে পারেন না। কোডের জন্য একই হওয়া উচিত!
NWS

2
@ ডেলান - আপনি পঠনযোগ্যতা চেয়েছিলেন, এটি একই বর্ণমালা ব্যবহার করে, আপনি যখন কেস পরিবর্তন করবেন তখন অর্থটি কেন পরিবর্তন করবেন?
NWS

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

2
@ বেন আমাকে একটি উপমা দিন। গাণিতিক স্বরলিপি হ'ল প্রোগ্রামিং ভাষার থেকে পৃথক, কেবলমাত্র মানুষের জন্য। প্রাচীন কম্পিউটারগুলির historicalতিহাসিক নিদর্শন হওয়ার ক্ষেত্রে সংবেদনশীলতার ক্ষেত্রে সাধারণ যুক্তি এখানে প্রযোজ্য না। তবুও আমি সন্দেহ করি যে কোনও গণিতবিদ তর্ক করবেন aএবং Aবিনিময়যোগ্য হওয়া উচিত। তারা কোনও ব্যতিক্রম ছাড়াই ধারাবাহিকভাবে মামলা করে। উদাহরণস্বরূপ, কিছু প্রসঙ্গে উচ্চতর অক্ষরগুলি সেটগুলির জন্য ব্যবহৃত হয় যখন লোয়ার কেস অক্ষরগুলি সেট সদস্য হয়। বৈদ্যুতিক ইঞ্জিনিয়ারিংয়ে আরও একটি উদাহরণ দেখা যায়, লোয়ার-কেস সময়-নির্ভরতা এবং উচ্চতর ক্ষেত্রে সময়-স্বতন্ত্র হওয়া ...

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

2

ফরট্রান, বেসিক, এসকিউএল এর মতো ভাষার উদাহরণগুলি দেওয়া হয়েছে যে এগুলি কেস সংবেদনশীল।

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

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


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

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

সংবেদনশীল ভাষার ক্ষেত্রে উচ্চতর ক্ষেত্রে যে কোনও ব্যবহার সংবেদনশীলতার অপব্যবহারকে স্থির করে।
কাজ

@ কাজ - এরম ... মিলিয়ন মিলিয়ন এসকিউএল প্রোগ্রামারকে এটি বলার চেষ্টা করুন।
স্টিফেন সি

1

কেস সংবেদনশীলতা ক্ষতিকারক হিসাবে বিবেচিত।

জীবন কেস সংবেদনশীল নয় এবং ব্যবহারকারী বা প্রোগ্রামারও নয়।

সংবেদনশীল ভাষা হ'ল একটি aতিহাসিক দুর্ঘটনা, বাধা ব্যবস্থার যা কেস-সংবেদনশীল তুলনাকে কঠিন বলে মনে করে। এই প্রতিবন্ধকতা আর বিদ্যমান নেই, তাই আর কখনও কেস-সংবেদনশীল কম্পিউটার সিস্টেম করার কোনও কারণ নেই।

আমি যে এতদূর যেতে হবে কেস সংবেদনশীলতাটি খারাপ , কারণ এটি ব্যবহারকারীর তুলনায় কম্পিউটারের সুবিধাকে দেয়।

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


কেস সংবেদনশীলতা ব্যবহারকারীর তুলনায় কম্পিউটারের সুবিধাকে দেয় না। আমি কেস সেনসিটিভ এবং কেস সংবেদনশীল ভাষাগুলি প্রয়োগ করেছি এবং কেবলমাত্র পার্থক্য হ'ল কয়েকটি জায়গায় অতিরিক্ত ফাংশন কল। এছাড়াও, অন্যান্য উত্তর বলে যে ক্ষেত্রে মধ্যে -sensitivity সীমিত অক্ষর সেট কারণে একটি ঐতিহাসিক হস্তনির্মিত বস্তু - আপনার তত্ত্ব contradicts, না?

ইউনিকোড এটি সম্পূর্ণ অন্য রাজ্যে রাখে।
ডেড এমএমজি

3
কেবলমাত্র পাইথন বা পিএইচপি-তে সিতে খারাপ কেন, এটির জন্য ব্লগটি কোনও যৌক্তিকতা দেয় না এবং ওপি কেস সংবেদনশীল শনাক্তকারীদের নিয়ে কথা বলছে না, কেবল কীওয়ার্ড । সেই লিঙ্কটিতে সেই বিষয় সম্পর্কে বলার মতো কিছুই নেই।
ডেড এমএমজি

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

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

1

আমার ব্যক্তিগত অভিজ্ঞতা থেকে আমি কেস সংবেদনশীল এবং সংবেদনশীল ভাষার মধ্যে বড় পার্থক্য দেখতে পাচ্ছি না।

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

চেকআউট এবং চেকআউট এবং চেকআউট এবং সিএইচকিওউটি এবং চেকআউট একই অর্থ ব্যবহার করা উচিত নয়। এটি পাঠ্যতা ক্ষতিগ্রস্থ করবে এবং সেই ধরণের কোডকে আরও বেদনাদায়ক বোঝে (তবে কোডের পাঠ্যতা নষ্ট করার জন্য আরও খারাপ জিনিস রয়েছে)।

আপনি যদি কিছু ধরণের নিয়ম ব্যবহার করেন তবে নজরে দেখবেন উদাহরণস্বরূপ:

CheckOut.getInstance () - এটি চেকআউটক্যালকুলেট () নামে পরিচিত শ্রেণীর স্থিতিশীল পদ্ধতি - এটি ভেরিয়েবল বা পাবলিক ফিল্ডে _checkOut.calculate () নামক একটি অবজেক্টের পদ্ধতি - এটি CHECKOUT নামক ব্যক্তিগত ক্ষেত্রে রাখা কোনও অবজেক্টের একটি পদ্ধতি - এটি একটি চূড়ান্ত স্থির বা ধ্রুবক ক্ষেত্র / পরিবর্তনশীল vari

অন্য কোনও ফাইল বা কোনও ফাইলের অংশগুলি পরীক্ষা না করে। এটি পড়ার কোডটি দ্রুত করে তোলে।

আমি প্রায় অনেকগুলি বিকাশকারী একই ধরণের নিয়ম ব্যবহার করতে দেখি - যে ভাষাগুলিতে আমি প্রায়শই ব্যবহার করি: জাভা, পিএইচপি, অ্যাকশন স্ক্রিপ্ট, জাভাস্ক্রিপ্ট, সি ++।

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

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


1

প্রোগ্রামিং ভাষার ক্ষেত্রে সংবেদনশীল হওয়া উচিত।

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

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

ভাষার ক্ষেত্রে সংবেদনশীল হওয়া নিশ্চিতভাবে সহজ; সংবেদনশীল ফ্যাশনে সবকিছু মিলে যায় তা নিশ্চিত করার অতিরিক্ত কাজ করার জন্য আপনার লেসার, পার্সার এবং সিম্বল টেবিলের দরকার নেই। তবে এটি দু'টি কারণে খারাপ ধারণাও রয়েছে:

  • প্রথমত, বিশেষত আপনি যদি স্ক্রিপ্টিং ভাষা তৈরি করছেন, এমন একটি সাধারণ টাইপ যেখানে আপনি এক জায়গায় কিছু "মাইবজেক্ট" এবং অন্য জায়গায় "মাইবজেক্ট" বলছেন, যেখানে আপনি সম্ভবত একই অবজেক্টের কথা উল্লেখ করছেন তবে মূলধনের সাথে কিছুটা অসঙ্গতি পেয়েছেন , রানটাইম ত্রুটিতে পরিণত হয় না। (এটি পাইথনের মতো স্ক্রিপ্টিং ভাষাগুলিতে একটি বড় বেদনা-বিষয় হিসাবে কুখ্যাত হয় যা এই ভুল হয় get)
  • দ্বিতীয়ত, কেস সংবেদনশীলতা না থাকার অর্থ কেস সংবেদনশীলতা একই শব্দ হ'ল অপব্যবহার করা যাবে না কেবলমাত্র মূলধন পরিবর্তন করে একই সুযোগে দুটি ভিন্ন জিনিস বোঝায়। আপনার যদি কখনও সি পরিবেশে উইন্ডোজ কোডের সাথে কাজ করতে হয় এবং কুরুচিপূর্ণ ঘোষণার মধ্যে চলে আসে তবে HWND hwnd;আপনি কী জানেন আমি ঠিক কী সম্পর্কে বলছি। এই জাতীয় লেখার মতো লোকদের বের করে এনে গুলি করাতে হবে এবং ভাষা কেসকে সংবেদনশীল করে তোলা কোডের সংবেদনশীলতাটিকে আপনার কোডে প্রবেশ করা থেকে বিরত করে।

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


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

আমি কিছু মনে করি না HWND hwnd;। এটি উদাহরণস্বরূপ যেখানে কেস সংবেদনশীলতা ভালভাবে কাজ করে। সমস্ত জাতীয় ক্যাপ ধরণের "ইন্ডিয়ান হিল" কনভেনশনটি নির্বিকার। hwnd_t hwndঅনেক ভাল। আমি সন্দেহ করি যে এটি সমস্ত কারণেই FILE। একটা সময় সংস্করণ 6 ইউনিক্স তার ইনপুট / আউটপুট লাইব্রেরি হেডার ফাইলটি এই ছিল উপর একবার: #define FILE struct _iobuf। এটি সমস্ত ক্যাপগুলিতে ছিল কারণ এটি ম্যাক্রো ছিল। এটি এএনএসআই সি-তে টাইপেইডে পরিণত হয়ে গেলে সমস্ত ক্যাপস বানানটি ধরে রাখা হয়েছিল। এবং আমি মনে করি এই অনুকরণে দ্বারা যে ALL_CAPS_TYPE সম্মেলন আবিষ্কৃত হয়, এবং বেল ল্যাব "ভারতীয় পার্বত্য স্টাইল গাইডে বিধিবদ্ধ (মূল এক!)।
Kaz

আপনি যদি এখন "ইন্ডিয়ান হিল স্টাইল গাইড" এর জন্য গুগল করেন তবে আপনি বেশিরভাগ 1990 এর বেল ল্যাবসের নথির উল্লেখ খুঁজে পান যা সমস্ত ক্যাপ টাইপইডফের নামগুলি সম্পূর্ণরূপে অনুতপ্ত করে: এরকম কোনও সুপারিশের চিহ্ন নেই। তবে মূল সংস্করণটি পছন্দ মতো জিনিসগুলির প্রস্তাব দেয় typedef struct node *NODE। আমি নিশ্চিত যে মাইক্রোসফ্ট অবশ্যই এটি গ্রহণ করেছে। সুতরাং, বেল ল্যাবগুলির জন্য দোষ দিন HWND
কাজ

1

আমি বিশ্বাস করতে পারি না যে কেউ বলেছিলেন "কেস সংবেদনশীলতা কোড পড়া সহজ করে তোলে"।

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

সঠিক বিবৃতি হওয়া উচিত "মিশ্র কেস কোড পড়া সহজ করে তোলে"। এটি অনেক বেশি স্পষ্ট সত্য - যেমন ভেরিয়েবলগুলি নাম এবং কোম্পানির নাম পরিবর্তে কোম্পানির নাম ঠিকানা called তবে আমি জানি না এমন কোনও ভাষা আপনাকে কেবল ছোট ছোট অক্ষরের নাম ব্যবহার করে।

আমার জানা সবচেয়ে উন্মত্ত সম্মেলনটি হ'ল "বড় হাতের পাবলিক, লোয়ারকেস প্রাইভেট" একটি one শুধু কষ্ট চাইছে!

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

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

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

এটি একটি আপত্তি লোকের সাথে তুলনা করে হাঙ্গেরিয়ান স্বরলিপি, যেখানে একটি উপসর্গযুক্ত বেসরকারী ভেরিয়েবল pCompany ইন্টেলিজেনিসে ভাল জায়গায় উপস্থিত হবে না।

এই কনভেনশনটিতে ভয়ঙ্কর আপার / লোয়ার কেস কনভেনশনের সমস্ত সুবিধা রয়েছে এবং এর কোনও ত্রুটি নেই।

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

আপনার সাথে কাজ করা জিনিসগুলি একে অপরের সাথে স্পষ্ট এবং স্পষ্টতই আলাদা করুন, সেগুলি সম্পর্কিত হলেও !!


1
ঠিক আছে, তাই companyName == companyname। এটি যুক্তিসঙ্গত বলে মনে হচ্ছে, তবে আপনি কীভাবে লোকেলগুলি পরিচালনা করবেন? আপনার প্রোগ্রামটি বিশ্বের বিভিন্ন অংশে সংকলন কী পিএইচপি-তে যেমন বিভিন্ন শব্দার্থবিজ্ঞানের কারণ ঘটায়? আপনি কি পুরো অ্যাংলো-কেন্দ্রিক হবেন এবং শনাক্তকারীগুলিতে কেবল ASCII মুদ্রণযোগ্য সেটকে সমর্থন করবেন? কেস সংবেদনশীলতা খুব সামান্য অতিরিক্ত লাভের জন্য অতিরিক্ত জটিলতা।
ফোশি

0

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

এই যুগে প্রোগ্রামাররা কেস সংবেদনশীলতা আশা করে।


1
কেসের তুলনা এতটা শক্ত নয়। কেবল আপনার শনাক্তকারীদের পচন করুন। E = ই '= ই' = e। মনে রাখবেন, আপনি যদি এখনও নির্বাচন করতে পারবেন যা কেস অনুসরণ করতে আদেশ করে এবং ইংরেজি একটি যুক্তিসঙ্গত পছন্দ। (অবশ্যই যদি আপনার কীওয়ার্ডগুলিও ইংরেজী হয়)
MSalters

2
হ্যাঁ তারা ইউনিকোডের পুরো জায়গা জুড়ে "সেই শক্ত"।
কাজ

1
"এই যুগে প্রোগ্রামাররা কেস সংবেদনশীলতা আশা করে"? কেবলমাত্র তাদের কাছে সি পরিবারের সাথে দীর্ঘকাল ধরে কাজ করা থেকে স্টকহোম সিনড্রোম রয়েছে।
ম্যাসন হুইলার

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

0

কেস সংবেদনশীলতা কোড আরও পঠনযোগ্য এবং প্রোগ্রামিং সহজ করে তোলে।

  • লোকেরা মিশ্রিত মামলার যথাযথ ব্যবহার পড়তে সহজ মনে করে

  • এটি ক্যামেলকেসকে এমনভাবে উত্সাহ দেয় / উত্সাহ দেয় যে বিভিন্ন ক্ষেত্রে একই শব্দটি সম্পর্কিত বিষয়গুলিকে উল্লেখ করতে পারে: Car car; এইভাবে নামের পরিবর্তনশীলটি carটাইপ তৈরি করা হয় Car

  • ALL_CAPS_WITH_UNDERSCORES বহু ভাষায় কনভেনশন দ্বারা স্থিরদের নির্দেশ করে

  • all_lower_with_underscores সদস্য ভেরিয়েবল বা অন্য কিছুর জন্য ব্যবহার করা যেতে পারে।

  • সমস্ত আধুনিক প্রোগ্রামিং সরঞ্জাম (উত্স নিয়ন্ত্রণ, সম্পাদক, ডিফ, গ্রেপ, ইত্যাদি) কেস সংবেদনশীলতার জন্য ডিজাইন করা হয়েছে। আপনি যদি কোনও ক্ষেত্রে সংবেদনশীল ভাষা না তৈরি করেন তবে সরঞ্জাম প্রোগ্রামারগুলিতে আপনার চিরতরে সমস্যা হবে।

  • যদি ভাষাটি ব্যাখ্যা করা হয়, কোডের সংবেদনশীল পার্সিংয়ের ক্ষেত্রে পারফরম্যান্স জরিমানা হতে পারে।

  • অ-ইংরাজী চরিত্রগুলি সম্পর্কে কী? আপনি কি এখন সিদ্ধান্ত নিচ্ছেন কপটিক, চাইনিজ এবং হিন্দি কখনও সমর্থন করবেন না? আমি আপনাকে দৃ language়ভাবে পরামর্শ দিচ্ছি যে আপনি আপনার ভাষাটিকে ইউটিএফ -8 এ সমস্ত কিছু ডিফল্ট করুন এবং এটি এমন কয়েকটি ভাষার পক্ষে সমর্থন করে যা অক্ষরগুলি উচ্চ বা নিম্ন-আকারের সমতুল্য না করে supports আপনি আপনার কীওয়ার্ডগুলিতে এই অক্ষরগুলি ব্যবহার করবেন না তবে আপনি যখন বিভিন্ন সরঞ্জামগুলিতে কেস সংবেদনশীলতা বন্ধ করতে শুরু করেন (উদাহরণস্বরূপ ফাইলগুলিতে জিনিসগুলি সন্ধান করতে), আপনি কিছু পরাবাস্তব এবং সম্ভবত অপ্রীতিকর অভিজ্ঞতায় চলে যাবেন।

লাভ কী? আপনার উল্লিখিত 3 টি ভাষা হ'ল 1970 এর দশকের বা তার আগের। কোনও আধুনিক ভাষা এটি করে না।

অন্যদিকে, শেষ-ব্যবহারকারীকে প্রকৃতপক্ষে খুশী করে এমন কোনও কিছু বিশ্বে কিছুটা আলোকপাত করে। এটি যদি সত্যই ব্যবহারকারীর সুখকে প্রভাবিত করে, তবে আপনাকে এটি করতে হবে।

যদি আপনি এটিকে শেষ ব্যবহারকারীদের জন্য সত্যিই সহজ করতে চান তবে আপনি কেস সংবেদনশীলতা / সংবেদনশীলতা থেকে ভাল করতে পারেন - স্ক্র্যাচটি দেখুন ! কয়েকটি কম কার্টুন বিড়াল এবং আরও ব্যবসায় বান্ধব রঙ এবং আপনি যে বন্ধুবান্ধব আমি দেখেছি তার সম্পর্কে আপনার কাছে রয়েছে - এবং আপনাকে কিছু লিখতে হবে না! শুধু একটি ভাবনা.


1
আমি মনে করি আপনি "কেস-সংবেদনশীলতা একটি দুঃস্বপ্ন" বলতে চেয়েছিলেন। জাপানিদের ক্ষেত্রে রয়েছে: হিরাগানা এবং কাতাকানা এক ধরণের, বিভিন্ন ধরণের different ঠিক যেমন A এবং a নির্দিষ্ট উপায়ে "একই", তেমনি あ এবং ア ア রোজ বর্ণমালা ব্যবহার করে এমন ভাষাগুলিতে একইভাবে উপরের ক্ষেত্রে কাতাকানা ব্যবহৃত হয়। বলা বাহুল্য, হিরাগানা এবং কাতাকানাকে প্রোগ্রামিং ভাষা শনাক্তকারীদের ক্ষেত্রে একই হিসাবে গণ্য করা বুদ্ধিমানের কাজ হবে।
কাজ

ধন্যবাদ - এটি সমৃদ্ধ করছে! আমি আমার পোস্টটি কিছুটা পরিষ্কার করেছি।
গ্লেনপিটারসন

1
Car car;কেস সংবেদনশীলতার বিরুদ্ধে সেরা যুক্তিগুলির মধ্যে একটি : এটি কুৎসিত এবং আপনার ভাষা যদি কেস সংবেদনশীল হয় তবে আপনি মামলার সংবেদনশীলতাটিকে সেভাবে ব্যবহার করতে পারবেন না।
ম্যাসন হুইলার

1
কি Car myCar;তাই অনেক ভালো?
গ্লেনপিটারসন

@ ম্যাসন হুইলারের: আমরা যদি আমাদের ভাষা নির্মানগুলি তাদের ব্যবহারের মধ্যে সীমাবদ্ধ রাখি যা আমরা অপব্যবহার করতে পারি না, আমরা বেশি কিছু করতে সক্ষম হব না, আমরা কি? কেস সংবেদনশীলতা আপত্তিজনক কারও প্রতি আমার পরামর্শ হ'ল "না"।
ডেভিড থর্নলি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.