আমার কারও কোডে বানান / ব্যাকরণ সম্পর্কিত ভুলগুলি উল্লেখ করা উচিত? [বন্ধ]


106

সহকর্মীর কোড পর্যালোচনা করার সময়, আমি ফাংশন নামগুলিতে কিছু বানান ভুল এবং ফাংশন এবং ভেরিয়েবলের নামগুলিতে 'doUserHavePermission ()' এর পরিবর্তে 'doUserHasPermission ()' এর মতো ব্যাকরণগত ত্রুটিগুলি পেয়েছি।

আমি কি তার কাছে এইগুলি নির্দেশ করব বা আমি এগুলি লক্ষ্য করে খুব প্যাডেন্টিক হচ্ছি?


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

31
হ্যাঁ. আপনার ভুল বানান সহ কোনও এপিআই থাকলে এটি হতাশাব্যঞ্জক। এটি দাবানলের মতো ছড়িয়ে পড়ে। যত তাড়াতাড়ি সম্ভব এটি সংশোধন করা ভাল।

9
@ রেই: ইংরেজি তাদের মাতৃভাষা হোক বা না হোক পেশাদার পরিবেশে অপ্রাসঙ্গিক হওয়া উচিত; যদি এটি তাদের পক্ষে খুব খারাপ না হয় তবে এটি কোনও অজুহাত না, সেগুলি একই মানদণ্ডে ধারণ করা উচিত।
থমাস বনিনি

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

11
HTTP-Refererআমাকে প্রায়শই বিরক্ত করে। en.wikedia.org/wiki/HTTP_referrer#Origin_of_t_term_referr
অর্থের এক বেতনভুক্ত

উত্তর:


205

বানান এবং ব্যাকরণ ত্রুটি সহ কোডটি অভাবনীয়

  • লোকেরা খারাপ ব্যাকরণ মনে রাখে না, সুতরাং তারা ফাংশনটি যেমন লেখা উচিত ছিল তেমনভাবে কল করার চেষ্টা করবে এবং কীভাবে বাগগুলি ঘটে।

  • কোডটি কীভাবে বানান তা আপনি যদি জানেন না তবে আপনি কোডের কোনও কিছুর জন্য গ্রেপ করতে পারবেন না।

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

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


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

15
+1 - একবার বানান এবং ব্যাকরণগত ত্রুটিগুলি একটি এপিআই এ চলে যাওয়ার পরে এগুলি আবার বের হওয়া অসম্ভব। আমি "ক্রিয়াকলাপ" এর পরিবর্তে "অ্যাভিটিভিটি" লেখার জন্য তিন বছরের ভাল অংশটি ব্যয় করেছি এবং এটি করতে সর্বদা শারীরিকভাবে আঘাত লাগে।
জন বোদে

7
আরও ভাল বা খারাপের জন্য, ভাল প্রোগ্রামিং অনুশীলনটি প্রায়শই প্যাডেন্ট্রির মতো কিছুতে আসে। এছাড়াও, আমি সেই ব্যক্তির সন্ধান করতে চাই যাঁরা Referrerমূল এইচটিটিপি অনুপস্থিতিতে ভুল বানান করেছিলেন এবং তাকে পায়ের গোড়ালিতে লাথি দেন। অবশ্যই এটি বার্নারস-লি ছিল এবং তাই আমি পরে অপরাধী বোধ করব ...
মালভোলিও

2
@ স্টেফান ফুরলানি: এটাই আমি তৈরি করার চেষ্টা করছিলাম; এটি এমন একটি API এর অংশ ছিল যা আমাদের নিজস্ব ছিল না। আমরা আমাদের শেষের দিকে এটি ঠিক করতে পারিনি, এবং এটি স্থির করার প্রক্রিয়াটি ছিল কুরুচিপূর্ণ এবং দীর্ঘতর যে এটির সাথে কেউ গোলযোগ করতে চায়নি।
জন বোদে

2
@ জন বোড, আমি মনে করি আপনার একটি মোড়ক ফাংশন তৈরি করা উচিত ছিল :) সি # এর জন্য একটি ঝরঝরে কৌশল আছে (যদিও আমি এর নামটি ভুলে গেছি)।
কাজ

38

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


29

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

যদি এই কোডটি কোনও গ্রাহক দেখতে চলেছেন তবে এটি অবশ্যই সংশোধন করা উচিত। এটি পছন্দ করুন বা না করুন এটি আপনার সংস্থার খ্যাতি প্রতিফলিত করে।

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


12
এটি অন্যের উপলব্ধি সম্পর্কে বলা এটিকে গুরুত্বহীন বলে মনে হয়। সত্য বলুন - তারা কোড বজায় রাখা এবং আরও শক্তিশালী করে তুলছেন।
হেজমেজ

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

12
@John আমি অবশ্যই দেখতে পারেন একটি খারাপ কাজের পরিস্থিতি যে ভালো eggshells হাঁটিতে আছে কেউ জোর করতে পারেন - কিন্তু এটা হয় একটি খারাপ অবস্থা যে যদি প্রথম স্থানে একটি সমস্যা রয়েছে। এত নাজুক কোনও ব্যক্তি (এবং একটি কর্মক্ষেত্রের সংস্কৃতি যা তাদের শেননিগানদের মঞ্জুরি দেয়) ব্যবসা শুরু করার পক্ষে ভাল নয়।
হেজেজেজ

6
বেশিরভাগ পরিপক্ক প্রোগ্রামাররা সমালোচনা ভালভাবে গ্রহণ করেন। সর্বোপরি, পিয়ার রিভিউগুলি কী তা বোঝায় (এবং আমরা সকলেই কোড রিভিউ করি, তাই না?) মন্তব্য, ফাংশন নাম ইত্যাদির বানান এবং ব্যাকরণের সমালোচনা করা ঠিক আছে তবে এটি সমস্ত লেখককেই প্রতিফলিত করে না তবে তাদের পুরো সংস্থা।
দ্রুত_আজ

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

10

এটি নিজেই পরিবর্তন করুন।

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


5
এবং তারপরে আপনি দেখতে পাচ্ছেন যে আপনি কেবলমাত্র তৃতীয় লোকের কোডটি ভঙ্গ করেছেন। প্রথম ধরণের লোকটি সমস্ত কিছু পরীক্ষা করে দেখার পরে আপনি কেবল এটিকে ঠিক করতে পারবেন না
ডেভিড থর্নলি

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

@ কর্নেলম্যাসন: সত্যই নয়। এটি একটি এপিআই ডিজাইনের মূল অঙ্গ।
অরবিট

6

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

সুতরাং আমি অবশ্যই অন্য কারও কোডে ব্যাকরণ বা বানান ভুলগুলি উল্লেখ করব, তবে কেবল যদি আমি নিশ্চিত হন তবে আমি যা বলছি তা সঠিক কিনা।


6

আমি এখানে এটি উল্লেখ করার মতো অনুমান করি যে এইচটিটিপি প্রোটোকলে এইচটিটিপি রেফারার শিরোনামটি "রেফারার" হিসাবে ভুলভাবে লেখা হয়েছিল (এবং আমাদের এটির সাথে থাকতে হবে / আমরা এটির সাথে থাকতে শিখেছি।) :)


10
এবং আমরা আর কখনও এই ধরণের জিনিস দেখতে চাই না।
ডেভিড থর্নলি

4

আমি অন্যান্য উত্তরের সাথে একমত হয়েছি যে ব্যাকরণের ভুলের সাথে কোডটি অভাবনীয়।

আমি কয়েকটি জিনিস যুক্ত করতে চাই:

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

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

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

কোনও বানান ত্রুটি একটি সাধারণ গুগল অনুসন্ধান দ্বারা চেক করা যায়
জোয়েলফ্যান

2

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


0

আমি যদি এটা করি তবেই

  • এটি প্রোগ্রামটির ব্যবহারকে প্রভাবিত করে
  • এটি প্রোগ্রামের যথার্থতাকে প্রভাবিত করে
  • আমি স্পষ্টভাবে জানি লেখক সংশোধন করতে চান।

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

if userHasPermission() ...

1
ব্যাকরণ ভুলের জন্য এখনও একই সম্ভাবনা রয়েছে, যদিও এই ক্ষেত্রেটি userHavePermission()ভুল হবে।
ডিন হার্ডিং

তবে ঠিক এটাই কথা !! userHasPermission()ইঙ্গিত দেয় যে এটি ব্যাকরণের কারণে একটি বিল ফিরিয়ে দেয় ~ বা ~ এর অর্থ এটি ব্যবহারকারীর অনুমতি নির্ধারণ করে । (অফিসারের ব্রিজ রয়েছে: ব্যবহারকারীর অনুমতি রয়েছে)। এটা এখনও অস্পষ্ট।
স্টিফেন ফুরলানি

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

0

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

ব্যক্তিগতভাবে, যখন এটি প্রায়শই ঘটে এবং অনেক দলের সদস্যরা যে প্রকল্পে যোগদানের আগেই কোডটি লিখতে পারতেন তখন আমি এটিকে উপেক্ষা করার প্রবণতা রাখি কারণ এটি কোনও ব্যাপারই না।

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


0

গোল্ডেন রুল প্রযোজ্য

অন্যের প্রতি যেমন ব্যবহার করা হয় তেমনই করুন।

আমি চাই অন্যেরাও এ জাতীয় বিষয়ে আমার পিছনে থাকে, তাই আমি অন্যকে সাহায্য করি। করুণাময় এবং সহায়ক হওয়া আপনার পক্ষে অনেক দীর্ঘ যেতে পারে।


2
অস্পষ্টতার জন্য -1 - আপনি প্রশ্নকর্তাকে কী করতে পরামর্শ দিচ্ছেন তা আমার কোনও ধারণা নেই।
হেজমেজ

@HedgeMage, আমি আবেদন করতে ওপি পরামর্শ করছি en.wikipedia.org/wiki/The_Golden_Rule
kevpie

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

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

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

0

অন্যান্য অনেক ভাল প্রোগ্রামিং অনুশীলনের মতো, প্রোগ্রামগুলিতে বানান সম্পর্কে নীতি বাস্তবায়নের একমাত্র উদ্দেশ্যমূলক, অরাজনৈতিক এবং কার্যকর উপায় হ'ল প্রাক-কমিট প্রক্রিয়াটির অংশ হিসাবে এটি স্বয়ংক্রিয় to স্বতঃস্ফূর্ততা আপনাকে প্রচুর পরিমাণে অভিযোগ থেকে বাঁচাবে এমনকি যদি নিজের উদ্দেশ্যে নিজের সরঞ্জামটি লিখতে হয় তবে।


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

এই ধরণের অটোমেশন এই সমস্যাগুলি সমাধান করে না, এটি লোকেদের কিছু ভুল ধরা দেয়।
বোঝা

স্বতঃ-সংশোধন ??? ইন্টারনেটে স্বতঃসিদ্ধ "ব্যর্থ" হওয়ার প্রচুর উদাহরণ রয়েছে। এটা অবশ্যই ভাল না।
ফ্লোরিয়ান এফ

0

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

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

যতক্ষণ না আপনি এটির মতো বড় সমস্যা হিসাবে এটি ব্যবহার করেন না সেই সহকর্মীকে এমন অবস্থানে রাখা সহজ হওয়া উচিত যেখানে তারা অহংকে লাইনে না রেখে উন্নতি করতে পারে।


-1

ব্যবহারকারীর অনুমতি () সম্ভবত? -

সর্বশেষ যেটি আমি আমার কাছে এসেছি তা হল অনুসন্ধানের ফলাফলগুলি হাইলাইট করা না হওয়ার একটি বিশ্বব্যাপী সমস্যা কারণ শ্রেণিকামটি হাইটলাইট বানান ছিল। স্পষ্ট করার জন্য খুব অস্পষ্ট বাগ।


মন্তব্য না করে ডাউনভোটিং একটি জঘন্য কাজ।
এমপ্লুংজন

-1

অবশ্যই এটি উল্লেখ করুন, তবে বানানের ভুলগুলির জন্য আপনার সময় নষ্ট করবেন না। আপনার সিআই-এ এটি স্বয়ংক্রিয় করার জন্য একটি সরঞ্জাম ব্যবহার করুন। .NET fxCop এ এটি করতে পারেন ...


-2

এটি মূলত ভুলগুলি কী, কীভাবে সাধারণ এবং কতটা খারাপ তা নির্ভর করে এবং এটি আসলে একটি জঘন্য ভুল বা আপনি কীভাবে এটি শব্দটি বর্ণনা করবেন তা নয় depends

আমি ব্যক্তিগতভাবে এটি দাঁড়াতে পারি না যখন কিছু বোকা 5 মিনিটের কোড পর্যালোচনাটি আধা ঘন্টা পর্যন্ত টেনে নিয়ে যায় কারণ তিনি চান যে তিনি সবকিছু কীভাবে করবেন তার নামকরণ করা চাই এবং সমস্ত মন্তব্য কেবলমাত্র তার অনাবৃতকে আটকে রাখতে পছন্দ করে কারণ একটি লগিং লাইন যা বলে যে "ডেটা অবজেক্টগুলি লোড হচ্ছে" " " ডেটা অবজেক্ট লোডার উপাদান এখন ডেটা অবজেক্ট স্টোরেজ উপাদান থেকে প্রাসঙ্গিক ডেটা অবজেক্ট লোড করবে "এ পরিবর্তনের দরকার নেই "।

/ অভিজাত :)


2
আমার পথে জিনিসগুলিকে জোর দেওয়া এক জিনিস। জিনিসগুলি যথাযথ বানান এবং ব্যাকরণ ব্যবহার করে তা জোর দিয়ে বলা সম্পূর্ণরূপে অন্য জিনিস।
ডেভিড থর্নলি

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